老熊的三分地-Oracle及数据恢复

在某些环境下，运行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

clusterware, rac

客户一套运行在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篇文档已经描述得比较清楚，有兴趣的朋友可以参考：

• MOS文档：DRM - Dynamic Resource management [ID 390483.1]
• Object Remastering In RAC

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

rac

某个刚安装好的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资源中。

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

crs, rac