RAC环境参数文件诊断案例

在RAC环境下，如果两个实例参数不一致，则可能导致某个数据库节点无法启动，以下是一个实际诊断案例。

数据库资源异常

在一次数据库维护中，当关闭数据库之后，重新启动，结果发现一个节点出现异常，在crs_stat的输出中发现节点2的一个服务状态为OFFLINE：

[oracle@smsdbrac2 client]$ crs_stat -t
Name           Type           Target    State     Host        
------------------------------------------------------------
ora.smsdb.db   application    ONLINE    ONLINE    smsdbrac2   
ora....b1.inst application    ONLINE    ONLINE    smsdbrac1   
ora....b2.inst application    ONLINE    ONLINE    smsdbrac2   
ora....srac.cs application    ONLINE    ONLINE    smsdbrac1   
ora....db1.srv application    ONLINE    ONLINE    smsdbrac1   
ora....db2.srv application    OFFLINE   OFFLINE               
ora....SM1.asm application    ONLINE    ONLINE    smsdbrac1   
ora....C1.lsnr application    ONLINE    ONLINE    smsdbrac1   
ora....ac1.gsd application    ONLINE    ONLINE    smsdbrac1   
ora....ac1.ons application    ONLINE    ONLINE    smsdbrac1   
ora....ac1.vip application    ONLINE    ONLINE    smsdbrac1   
ora....SM2.asm application    ONLINE    ONLINE    smsdbrac2   
ora....C2.lsnr application    ONLINE    ONLINE    smsdbrac2   
ora....ac2.gsd application    ONLINE    ONLINE    smsdbrac2   
ora....ac2.ons application    ONLINE    ONLINE    smsdbrac2   
ora....ac2.vip application    ONLINE    ONLINE    smsdbrac2

该资源具体信息为：

NAME=ora.smsdb.smsrac.smsdb2.srv
TYPE=application
TARGET=OFFLINE
STATE=OFFLINE

问题的发现

发现这一问题后，尝试在命令行手工启动数据库，此时发现出现错误告警：

SQL> startup mount;
ORACLE instance started.
 
Total System Global Area 1241513984 bytes
Fixed Size                  1267212 bytes
Variable Size             318769652 bytes
Database Buffers          905969664 bytes
Redo Buffers               15507456 bytes
ORA-01105: mount is incompatible with mounts by other instances
ORA-19808: recovery destination parameter mismatch

这里的ORA-19808错误提示参数设置不一致，在Oracle的文档中，关于这一错误的具体信息是：

ORA-19808: recovery destination parameter mismatch
Cause: The value of parameters DB_RECOVERY_FILE_DEST
and DB_RECOVERY_FILE_DEST_SIZE must be same in all instances.All databases must have same recovery destination parameters.
Action: Check DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE values in all instances.

了解到这个原因后，接下来检查数据库的参数文件：

[oracle@smsdbrac2 ~]$ cd $ORACLE_HOME/dbs
[oracle@smsdbrac2 dbs]$ ls -al *smsdb2*
-rw-rw----  1 oracle dba     1544 May  5 16:05 hc_smsdb2.dat
-rw-r--r--  1 oracle dba     1521 Sep  9 11:03 initsmsdb2.ora
-rw-r-----  1 oracle dba     1536 Jul 23 10:06 orapwsmsdb2
-rw-r-----  1 oracle dba 15876096 Apr 15 16:56 snapcf_smsdb2.f

这时发现了init参数文件存在问题，正常情况下，这个参数应该包含一个指向SPFILE的链接，而现在这个参数文件却是一个本地的参数文件：

[oracle@smsdbrac2 dbs]$ tail -20 initsmsdb2.ora
*.db_recovery_file_dest_size=8589934592
*.dispatchers='(PROTOCOL=TCP) (SERVICE=smsdbXDB)'
smsdb1.instance_number=1
smsdb2.instance_number=2
*.job_queue_processes=10
smsdb1.local_listener='(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.200.13)(PORT = 1521))'
smsdb2.local_listener='(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.200.14)(PORT = 1521))'
*.open_cursors=300
*.pga_aggregate_target=413138944
*.processes=1000
*.remote_listener='LISTENERS_SMSDB'
*.remote_login_passwordfile='exclusive'
*.sessions=555
*.sga_target=1241513984
smsdb2.thread=2
smsdb1.thread=1
*.undo_management='AUTO'
smsdb1.undo_tablespace='UNDOTBS1'
smsdb2.undo_tablespace='UNDOTBS2'
*.user_dump_dest='/opt/oracle/admin/smsdb/udump'

参数文件问题的解决

找到这个问题之后，可以根据参考实例1对这个参数文件进行修改：

[oracle@smsdbrac1 dbs]$ strings initsmsdb1.ora
SPFILE='+FLHDG/smsdb/spfilesmsdb.ora'

修改之后数据库实例可以启动。

这个问题的原因可能是因为在实例2上有人执行了类似create pfile from spfile的命令，这个命令创建的参数文件覆盖了原本正确的文件，导致了参数文件异常。

本地的参数文件可能会导致两个数据库实例的某些参数不一致，使得数据库的启动失败。

这个案例给我们的经验是：在RAC环境中，每一个维护操作都要相当谨慎！