RAC知识更新之-RAC下管理归档日志+修改VIP（摘自文平书）

无论数据库是单节点方式还是集群方式，其承载事物的方式是严格按照时间戳顺序执行的。这就决定了
在数据库进行恢复时，要严格按照时间顺序读取日志记录，以恢复数据库文件。因此，在集群数据库恢复时，
要有完整的日志序列。
当数据库运行在归档模式下时，日志在实例上是“局部”管理的，因此其归档操作也是“局部”的。
由于恢复时需要“全局”的日志文件，因此，在数据库归档操作中，如何把归档日志集合在共同路径下是
管理员的一个工作目标。
如前所述，AIX可以设定共享磁盘上存储文件的四种可能：GPFS(HACMP)、NFS、ASM或HACMP RAW设备。
HACMP RAW设备不能作为归档目的地，因此归档需要文件系统。所以，要放置在共享的区域，可以有如下三种
选择:
GPFS:将归档文件放置到GPFS方式。
ASM：将归档文件放置到ASM磁盘组的方式。
NFS:将归档文件放置到NFS的方式。

使用GPFS进行归档处理，好处是归档无需设置过程，简单的制定归档路径为GPFS即可，通过在各节点
指定相同的LOG_ARCHIVE_DESTn参数即可。由于集群中的实例都会将归档日志写入这一目录，因此实现了归档
文件的汇总。当然，如果还能为节点上的数据库再指定另一个归档目标，例如指向本地存储，则归档发生错误的可能性会得以降低。
使用ASM磁盘组作为归档存储（如使用一个ASM磁盘组作为闪回恢复区）也是Oracle 的建议方法，通过集群各实例将归档日志写到其DB_RECOVERY_FILE_DEST参数指向的ASM磁盘组，则这个磁盘组就存储了共有的归档日志数据。
如果使用NFS方式，则集群各节点挂载同样一个NFS即可。同样的，为提高安全性，可以设置多个归档目标，例如第一个归档目标是本地目录，第二个归档目标位NFS。
这是很多用户目前选择的归档存储结构。如果归档按照这个方式构造，则需要注意指向NFS归档目标的归档应该设置为非强调归档方式。因为当NFS上的归档操作具有强制性时，如果发生网络故障，则NFS安装点不再可用，
归档操作失败，这会导致数据库系统的挂起。

||||||||||||||||||||||||||||

在一般情况下集群中的节点应用不会发生什么改变，无需后续的配置和更改。但srvctl 工具还是提供了节点应用的删除、添加、更改等功能。这里以虚拟地址更改为例，描述节点应用的常见管理。
虚拟地址服务（VIP服务）是节点应用中的一部分，该地址在系统上线运行后仍然是可以修改的。下面我们将
节点node_a虚拟地址从‘192.168.2.93’为'192.168.2.95'.

STEP1:以root用户登录系统，然后在各节点修改/etc/hosts文件，将其中关于虚拟地址的绑定进行如下修改
192.168.2.93 node_a-vip ==> 192.168.2.95 node_a-vip

STEP2:将节点应用停止。进入到CRS安装目录下的bin目录，执行命令如下:
#./srvctl stop nodeapps -n node_a

STEP3:执行下面的命令将节点应用删除:
#./srvctl remove nodeapps -n node_a

STEP4:为节点node_a添加新的节点应用，下面的命令指明了ORACLE_HOME的位置、VIP地址及其掩码：
#./srvctl add nodeapps -n node_a -o /db/oracle/product/10.2.0/db_1 -A 192.168.2.95/255.255.255.0

STEP5:当节点应用添加完成后，重新启动节点应用:
#./srvctl start nodeapps -n node_a

STEP6:检查节点应用的运行状态，在安装完成或新节点添加操作后一般应确认系统配置是否正确、节点应用是否正常:
#./srvctl status nodeapps -n node_a

$ srvctl status nodeapps -n cctt1
VIP is running on node: cctt1
GSD is running on node: cctt1
Listener is running on node: cctt1
ONS daemon is running on node: cctt1