作者: Maclean Liu, post on December 6th, 2011 LMHB是11gR2中新引入的后台进程，官方文档的介绍是Global Cache/Enqueue Service Heartbeat Monitor，Monitor the heartbeat of LMON, LMD, and LMSn processes，LMHB monitors LMON, LMD, and LMSn processes to ensure they are running normally without blocking or spinning。 Database and ASM instances, Oracle RAC
该进程负责监控LMON、LMD、LMSn等RAC关键的后台进程，保证这些background process不被阻塞或spin。 LMHB可能是Lock Manager Heartbeat的缩写。
我们来看一下该进程的trace跟踪文件以便了解其功能：
按照 100s -> 80s -> 100s -> 80s的间隔监控并输出一次LMSn、LCKn、LMON、LMD等进程的状态及wait chain，由kjfmGCR_HBCheckAll函数控制
*** 2012-02-03 00:03:10.066 . . . → Read More: 11gR2新特性:LMHB Lock Manager Heart Beat后台进程
作者: Maclean Liu, post on December 4th, 2011 
之前有同学想要给11gR2的RAC添加LISTENER监听器，查看了listener.ora并发现问题:
[oracle@vrh2 ~]$ lsnrctl status LSNRCTL for Linux: Version 11.2.0.3.0 – Production on 04-DEC-2011 02:51:40 Copyright (c) 1991, 2011, Oracle. All rights reserved. Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)) STATUS of the LISTENER ———————— Alias LISTENER Version TNSLSNR for Linux: Version 11.2.0.3.0 – Production Start Date 02-DEC-2011 05:40:09 Uptime 1 days 21 hr. 11 min. 31 sec . . . → Read More: 给11gR2 RAC添加LISTENER监听器并静态注册
作者: Maclean Liu, post on November 6th, 2011 以下脚本可以用于收集 11gR2中 RAC DRM 动态资源管理 特性的诊断信息:
REM for 11.2 only REM written by Maclean.Liu set linesize 140 pagesize 1400 select DRMS, AVG_DRM_TIME, QUIESCE_T,FRZ_T,CLEANUP_T,REPLAY_T,FIXWRITE_T,SYNC_T from X$KJDRMAFNSTATS / select * from GV$DYNAMIC_REMASTER_STATS / select object, node, sopens, xopens, xfers from x$object_policy_statistics — where object=&object_id / select data_object_id, current_master, previous_master, remaster_cnt from gv$gcspfmaster_info / select * from gv$policy_history . . . → Read More: Script: 收集RAC DRM 诊断信息
作者: Maclean Liu, post on November 2nd, 2011 这2天在面试DBA Candidate的时候，我问到Oracle RAC中Brain Split脑裂决议的一些概念， 几乎所有的Candidate都告诉我当”只有2个节点的时候，投票算法就失效了，会让2个节点去抢占Quorum Disk，最先获得的节点将活下来” 。 我们姑且把这套理论叫做” 抢占论”。
“抢占论”的具体观点可能与下面这一段文字大同小异:
“在集群中，节点间通过某种机制(心跳)了解彼此的健康状态，以确保各节点协调工作。 假设只有”心跳”出现问题， 各个节点还在正常运行， 这时，每个节点都认为其他的节点宕机了， 自己是整个集群环境中的”唯一建在者”，自己应该获得整个集群的”控制权”。 在集群环境中，存储设备都是共享的， 这就意味着数据灾难， 这种情况就是”脑裂” 解决这个问题的通常办法是使用投票算法(Quorum Algorithm). 它的算法机理如下：
观点1：
集群中各个节点需要心跳机制来通报彼此的”健康状态”，假设每收到一个节点的”通报”代表一票。对于三个节点的集群，正常运行时，每个节点都会有3票。 当结点A心跳出现故障但节点A还在运行，这时整个集群就会分裂成2个小的partition。 节点A是一个，剩下的2个是一个。 这是必须剔除一个partition才能保障集群的健康运行。 对于有3个节点的集群， A 心跳出现问题后， B 和 C 是一个partion，有2票， A只有1票。 按照投票算法， B 和C 组成的集群获得控制权， A 被剔除。
观点2：
如果只有2个节点，投票算法就失效了。 因为每个节点上都只有1票。 这时就需要引入第三个设备：Quorum Device. Quorum Device 通常采用饿是共享磁盘，这个磁盘也叫作Quorum disk。 这个Quorum Disk 也代表一票。 . . . → Read More: 再议RAC Brain Split脑裂
作者: Maclean Liu, post on November 1st, 2011 几个礼拜前， 有一套10.2.0.2 的 二节点RAC 数据库因为增大db_cache_size ， 引发其中一个实例发生著名的ORA-04031 错误，日志如下:
Errors in file /oracle/oracle/admin/maclean/udump/u1_ora_13757.trc: ORA-00603: ORACLE server session terminated by fatal error ORA-00604: error occurred at recursive SQL level 1 ORA-04031: unable to allocate 1048 bytes of shared memory (“shared pool”,”select name,online$,contents…”,”Typecheck”,”kgghteInit”) ORA-00604: error occurred at recursive SQL level 1 ORA-04031: unable to allocate 1048 bytes . . . → Read More: RAC中增大db_cache_size引发的ORA-04031错误
作者: Maclean Liu, post on October 30th, 2011 在11.2中ocr和votedisk 可以存放在ASM中了，该版本中Oracle Cluster Registry(OCR)可选的存储设备包括:
2011-10-29 00:13:18.828: [ OCROSD][1087046128]utstoragetypecommon: Oracle Cluster Registry does not support the storage type configured. OCR can be configured on: ASM, OCFS, OCFS2, NFS, Block Device, Character Device, VxFS 2011-10-29 00:13:18.829: [ OCROSD][1087046128]utopen:6m”: OCR location # [0] [/g01/ocrlocal] configured is not a valid storage type. Return code [37]. 2011-10-29 00:13:18.829: [ . . . → Read More: 11.2 中Oracle Cluster Registry(OCR)可选的存储设备
作者: Maclean Liu, post on September 14th, 2011 了解Oracle rac brain split resolution View more documents from Maclean Liu
作者: Maclean Liu, post on September 11th, 2011 Upgrade grid 11.1.0.7 to 11.2.0.2. Rootupgrade.sh Hanging
We installed 11gR2 GI software and applied PSU2 patches upon getting runupgrade.sh prompt.runupgrade.sh hang on the first node.
[root@vrh8 client]# uname -a Linux vrh8 2.6.18-238.5.1.el5 #1 SMP Mon Feb 21 05:52:39 EST 2011 x86_64
x86_64 x86_64 GNU/Linux cluvfy passed with 2 ignorable errors:
[root@vrh8 vrh8]# cd /tmp [root@vrh8 . . . → Read More: Upgrade GI/CRS 11.1.0.7 to 11.2.0.2. Rootupgrade.sh Hanging
|
|
最新评论