在某些环境下,运行11.2版本的RAC数据库的服务器上,连接了多个public网络,那么就会有如下的需求:

  1. 给其他的,或者说是新的public网络增加新的VIP地址。
  2. 在新的public网络上增加SCAN VIP.
  3. 在新的VIP地址上配置监听
  4. 在新的SCAN VIP地址上配置监听

实际上从11.2版本开始,grid infrastructure(以下可能会简写为GI)就是一个完整的clusterware,不仅仅是用于数据库,也可以用作应用软件的高可用性。上述的4个需求中,第1个是毫无疑问需要的;第2个需求对运行在grid infrastructure上的应用是必要的;第3个需求在运行在grid infrastructure上的数据库来说是必要的;第4个需求,是针对数据库的,这个需求有点难度,因为在一套grid infrastructure中只能允许有一个SCAN LISTENER的存在,由于可以不通过SCAN IP而是直接通过VIP地址连接数据库,所以这个新的SCAN监听可以不需要,但是为了完整,我们可以用变通的方法来实现。

下面我们用一个实例来演示如何实现上述的所有需求。

先简单介绍一下用于演示的环境:11.2.0.1 grid infrastructure for linux 32bit,共2个节点,节点名是xty3和xty4,没有使用DNS(实际上在有DNS的环境下,也不太可能会有第2个public network),所以下面的演示是以没有DNS来配置的。Grid Infrastructure用的是oracle用户安装的(实际生产建议用单独的grid用户),而RDBMS软件也是用oracle安装的。目前的private network是192.168.153.0,对应的网卡设备名是en1,public network是192.168.0.0,对应的网卡设备名是en0,打算新增加的public network是192.168.76.0,对应的网卡设备名是en2。

先看看/etc/hosts文件的内容:

127.0.0.1    localhost.localdomain localhost
::1             localhost6.localdomain6 localhost6
192.168.0.134   xty3
192.168.0.144   xty4
192.168.153.134 xty3-priv
192.168.153.144 xty4-priv
192.168.0.135   xty3-vip
192.168.0.145   xty4-vip
192.168.0.155   xty-cluster-svip1

第1步,配置好新的public network的IP地址和网络路由。注意新的public network IP地址配好后,注意配置好网络路由。

第2步,在所有的节点上编辑/etc/hosts文件,增加如下内容:

192.168.76.134   xty3-pub2
192.168.76.144   xty4-pub2
192.168.76.135   xty3-vip2
192.168.76.145   xty4-vip2
192.168.76.155   xty-cluster-svip2

192.168.76.134和192.168.76.144是两个节点上新的public network的public ip,192.168.76.135和192.168.76.145是相对应的VIP地址,而192.168.76.155则是准备要在新的public network上增加的SCAN IP。而xty-cluster-svip2则是新增的SCAN名字。

第3步,增加新的public network上的vip地址,这一步比较简单,用root用户执行下面的命令:

srvctl add vip -n xty3 -k 2 -A xty3-vip2/255.255.255.0/eth2
srvctl add vip -n xty4 -k 2 -A xty4-vip2/255.255.255.0/eth2

在上述命令中,-n参数后面跟的是节点名(hostname); -k后面的参数表示第几个网络,这里是2,表示第2个public network。-A后面就是VIP地址的属性了,格式为"VIP地址名/子网/网卡设备名"。

然后用crsctl来检查,vip资源已经存在:

[root@xty3 ~]# crsctl stat res -t | egrep "vip|network"
ora.net1.network
ora.net2.network
ora.scan1.vip
ora.xty3-vip2.vip
ora.xty3.vip
ora.xty4-vip2.vip
ora.xty4.vip

[root@xty3 ~]# srvctl config vip -n xty3
VIP exists.:xty3
VIP exists.: /xty3-vip2/192.168.76.135/255.255.255.0/eth2
VIP exists.:xty3
VIP exists.: /xty3-vip/192.168.0.135/255.255.255.0/eth0

[root@xty3 ~]# srvctl config vip -n xty4
VIP exists.:xty4
VIP exists.: /xty4-vip2/192.168.76.145/255.255.255.0/eth2
VIP exists.:xty4
VIP exists.: /xty4-vip/192.168.0.145/255.255.255.0/eth0

ora.net2.network,ora.xty3-vip2.vip,ora.xty4-vip2.vip都是新增的资源。然后使用下面的命令启动新增的VIP:

Read the rest of this entry

,

客户一套运行在Oracle 10.2.0.5 RAC上的系统,间歇性地出现性能问题。其性能现象为前台反映性能缓慢,从系统上看CPU利用率大幅增加,load增加。这种性能问题通常在出现几分钟后自动恢复正常。

从AWR中的TOP 5等待来看:

Top 5 Timed Events                                         Avg %Total
~~~~~~~~~~~~~~~~~~                                        wait   Call
Event                                 Waits    Time (s)   (ms)   Time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
latch: cache buffers lru chain      774,812     140,185    181   29.7      Other
gc buffer busy                    1,356,786      61,708     45   13.1    Cluster
latch: object queue header ope      903,456      55,089     61   11.7      Other
latch: cache buffers chains         360,522      49,016    136   10.4 Concurrenc
gc current grant busy               112,970      19,893    176    4.2    Cluster
          -------------------------------------------------------------

可以看到,TOP 5中,有3个是latch相关的等待,而另外2个则是跟RAC相关的等待。
如果再查看更细的等待数据,可以发现其他问题:


                                                                  Avg
                                            %Time  Total Wait    wait     Waits
Event                                 Waits -outs    Time (s)    (ms)      /txn
---------------------------- -------------- ----- ----------- ------- ---------
latch: cache buffers lru cha        774,812   N/A     140,185     181       1.9
gc buffer busy                    1,356,786     6      61,708      45       3.3
latch: object queue header o        903,456   N/A      55,089      61       2.2
latch: cache buffers chains         360,522   N/A      49,016     136       0.9
gc current grant busy               112,970    25      19,893     176       0.3
gcs drm freeze in enter serv         38,442    97      18,537     482       0.1
gc cr block 2-way                 1,626,280     0      15,742      10       3.9
gc remaster                           6,741    89      12,397    1839       0.0
row cache lock                       52,143     6       9,834     189       0.1

从上面的数据还可以看到,除了TOP 5等待,还有"gcs drm freeze in enter server mode“以及"gc remaster"这2种比较少见的等待事件,从其名称来看,明显与DRM有关。那么这2种等待事件与TOP 5的事件有没有什么关联?。MOS文档"Bug 6960699 - "latch: cache buffers chains" contention/ORA-481/kjfcdrmrfg: SYNC TIMEOUT/ OERI[kjbldrmrpst:!master] [ID 6960699.8]”提及,DRM的确可能会引起大量的"latch: cache buffers chains"、"latch: object queue header operation"等待,虽然文档没有提及,但不排除会引起”latch: cache buffers lru chain“这样的等待。

为了进一步证实性能问题与DRM相关,使用tail -f命令监控LMD后台进程的trace文件。在trace文件中显示开始进行DRM时,查询v$session视图,发现大量的 "latch: cache buffers chains" 、"latch: object queue header operation"等待事件,同时有"gcs drm freeze in enter server mode“和"gc remaster"等待事件,同时系统负载升高,前台反映性能下降。而在DRM完成之后,这些等待消失,系统性能恢复到正常。

看起来,只需要关闭DRM就能避免这个问题。怎么样来关闭/禁止DRM呢?很多MOS文档提到的方法是设置2个隐含参数:

_gc_affinity_time=0
_gc_undo_affinity=FALSE

不幸的是,这2个参数是静态参数,也就是说必须要重启实例才能生效。
实际上可以设置另外2个动态的隐含参数,来达到这个目的。按下面的值设置这2个参数之后,不能完全算是禁止/关闭了DRM,而是从”事实上“关闭了DRM。

_gc_affinity_limit=250
_gc_affinity_minimum=10485760

甚至可以将以上2个参数值设置得更大。这2个参数是立即生效的,在所有的节点上设置这2个参数之后,系统不再进行DRM,经常一段时间的观察,本文描述的性能问题也不再出现。

下面是关闭DRM之后的等待事件数据:

Top 5 Timed Events                                         Avg %Total
~~~~~~~~~~~~~~~~~~                                        wait   Call
Event                                 Waits    Time (s)   (ms)   Time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
CPU time                                         15,684          67.5
db file sequential read           1,138,905       5,212      5   22.4   User I/O
gc cr block 2-way                   780,224         285      0    1.2    Cluster
log file sync                       246,580         246      1    1.1     Commit
SQL*Net more data from client       296,657         236      1    1.0    Network
          -------------------------------------------------------------
          
                                                                  Avg
                                            %Time  Total Wait    wait     Waits
Event                                 Waits -outs    Time (s)    (ms)      /txn
---------------------------- -------------- ----- ----------- ------- ---------
db file sequential read           1,138,905   N/A       5,212       5       3.8
gc cr block 2-way                   780,224   N/A         285       0       2.6
log file sync                       246,580     0         246       1       0.8
SQL*Net more data from clien        296,657   N/A         236       1       1.0
SQL*Net message from dblink          98,833   N/A         218       2       0.3
gc current block 2-way              593,133   N/A         218       0       2.0
gc cr grant 2-way                   530,507   N/A         154       0       1.8
db file scattered read               54,446   N/A         151       3       0.2
kst: async disk IO                    6,502   N/A         107      16       0.0
gc cr multi block request           601,927   N/A         105       0       2.0
SQL*Net more data to client       1,336,225   N/A          91       0       4.5
log file parallel write             306,331   N/A          83       0       1.0
gc current block busy                 6,298   N/A          72      11       0.0
Backup: sbtwrite2                     4,076   N/A          63      16       0.0
gc buffer busy                       17,677     1          54       3       0.1
gc current grant busy                75,075   N/A          54       1       0.3
direct path read                     49,246   N/A          38       1       0.2

那么,这里不得不提的是,什么是DRM?DRM对系统来说有什么好处?本文不再详述,因为下面的2篇文档已经描述得比较清楚,有兴趣的朋友可以参考:

关于本文所使用的2个隐含参数,在上述第二篇文档中也有详细描述。
--END---

某个刚安装好的RAC库,由于需要更换存储,所以需要重建。由于主机系统并没有重新安装,因此只需要重建CRS和库就行了。

环境:AIX 5306+HACMP 5.2+ORACLE 10.2.0.1+祼设备,文中对节点名、网络配置等信息处了更改处理。

以下是详细操作步骤:

1、在两个节点上修改主机配置:由于网络变更的原因,需要更换VIP,因此修改/etc/hosts文件,将VIP地址对应的地址更改为新的IP地址

2、在两个节点上修改/etc/oracle/ocr.loc文件,将文件中的ocrconfig_loc=后的地址改为新的存储ocr的祼设备名(如果用的是集群文件系统,则为文件名)

3、在两个节点上删除文件/etc/oracle/scls_scr/<节点名>/oracle/cssfatal

4、在两个节点上,进入$ORA_CRS_HOME/install目录,修改paramfile.crs文件,修改变动的配置数据。这里主要包括CRS_OCR_LOCATIONS、CRS_VOTING_DISKS、CRS_NODEVIPS

5、对存储OCR CONFIG的祼设备,用dd命令进行清除。(如果是集群文件系统,只需要删除OCR CONFIG的文件即可)。这里祼设备名为rocr,dd if=/dev/zero f=/dev/rocr bs=4096 count=10000 (如果是OCR本来是存在,只是需要重建,则必须要执行这一步。就算是完全新建在祼设备上,在后面的步骤中有时也会遇到莫名其妙的问题,则也需要对祼设备用dd进行清除,dd清除的大小不能过小,bs=4096的情况下,count为10之类的数值就显得过小,后面也会出现问题)

6、在两个节点上修改文件$ORA_CRS_HOME/install/rootconfig,修改在文件前面的变量。这里也主要是CRS_OCR_LOCATIONS、CRS_VOTING_DISKS、CRS_NODEVIPS

7、如果是通过远程telnet、ssh在主机上操作,则要设置DISPLAY变量。export DISPLAY=x.x.x.x:0.0。这里x.x.x.x为操作的终端的IP地址。在操作终端上运行如xmanager这样的软件。

7、在节点一上以root用户运行$ORA_CRS_HOME/install/rootconfig,注意不要运行rootinstall

8、待节点一完全运行完后,在节点二上运行$ORA_CRS_HOME/install/rootconfig。正常情况下会弹出vip设置窗口。如果VIP设置窗口没有弹出来,则看一下是否只是vipca启动出现问题。

9、在两个节点上运行crs_stat -t,如果出现CRS没有资源或有VIP相关的资源启动(在VIP已经设置的情况下),说明CRS已经建立成功。

10、如果前面没有配置VIP,则以root用户运行vipca,配置VIP。注意在弹出的窗口中,提示选择网络接口时,选择public接口。(如果显示接口异常,在shell用oifcfg命令检查一下网络接口,如有必要,用该命令对网络接口进行重新配置)

11、至此crs已经配置完毕,用crs_stat检查crs是否正常运行。如果没有正常运行,检查crs日志。此时应该有VIP、ONS、GSD等资源运行。在两个节点上运行ifconfig -a检查VIP是否已经绑定到PUBLIC网卡上(注意要确保是在PUBLIC网卡上,有的时候粗略一下VIP已经起了,但实际上绑在了PRIVATE网卡上)

12、清除原来的监听设置,确认监听是处于关闭状态,运行netca,配置监听,配置完成后将会自动把监听加入到crs中。

12、由于存在原来的建库脚本,打开原来的脚本,修改对应的数据文件名为新的文件名(祼设备名)

13、在节点一上运行建库脚本(shell脚本)

14、一番耐心等候之后,在节点一上的数据库创建完成

15、在节点二上运行建库脚本(shell脚本),这个过程很快

16、在两个节点上修改tnsnames.ora,内容如下(根据实际情况进行修改):

LISTENERS_DMDB =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = dm1-vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = dm2-vip)(PORT = 1521))
)

DMDB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = dm1-vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = dm2-vip)(PORT = 1521))
(LOAD_BALANCE = yes)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = dmdb)
)
)

RAC2 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = dm2-vip)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = dmdb)
(INSTANCE_NAME = rac2)
)
)

RAC1 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = dm1-vip)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = dmdb)
(INSTANCE_NAME = rac1)
)
)

EXTPROC_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1))
)
(CONNECT_DATA =
(SID = PLSExtProc)
(PRESENTATION = RO)
)
)

17、修改两个节点的初始化参数REMOTE_LISTENERS为 'LISTENERS_DMDB',节点一的LOCAL_LISTENER='(ADDRESS = (PROTOCOL = TCP)(HOST = IP1 )(PORT = 1521))',节点二的
LOCAL_LISTENER='(ADDRESS = (PROTOCOL = TCP)(HOST = IP2)(PORT = 1521))',注意这里的IP1和IP2分别是节点一和节点二的VIP地址(注意一定是IP地址,而不能是主机名)。设置LOCAL_LISTENER的目的是避免在使用负载均衡时出现ORA-12545错误。

18、在其中一个结点上创建spfile,这里spfile为祼设务rspfile:create spfile='/dev/rspfile' from pfile='xxxx'

19、关闭两个节点的实例。将数据库和实例增加到crs中,以便能够能用crs命令进行监控和用srvctl命令启停数据库实例:

srvctl add database -d dbname -o $ORACLE_HOME -y manual
srvctl add instance -d dbname -n 节点名1 -i 实例名1
srvctl add instance -d dbname -n 节点名2 -i 实例名2

这里实例名1和实例名2应分别与两个节点的ORACLE_SID一致

注意:10.2.0.1版本,实例依赖于VIP,因此如果某结点如网卡DOWN掉、VIP BUG等,将导致实例也DOWN掉。为避免出现这样的情况,可省略此步骤,不要将实例加入到CRS资源中。

至此所有工作已经全部完成

,