1.5 口令文件修改案例一则
某客户的ORACLE两节点集群数据库，为保证在RAC环境备份归档日志的方便性，归档日志除分别在两节点进行本地归档外，在进行本地归档的同时，通过配置 log_archive_dest_2向另一节点传送归档日志，在通过 orapwd 工具在节点一更改 SYS 密码后，造成归档 log_archive_dest_2向另一节点无法传送归档日志。
从数据库中查询到相关错误信息如下：
Error 1017 received logging on to the standby
------------------------------------------------------------
Check that the primary and standby are using a password file
and remote_login_passwordfile is set to SHARED or EXCLUSIVE,
and that the SYS password is same in the password files.
returning error ORA-16191
------------------------------------------------------------
Errors in file /oracle/app/diag/rdbms/orac/orac1/trace/orac1_arc1_1208404.trc:
ORA-16191: 主日志传送客户机没有登录到备用数据库
PING[ARC1]: Heartbeat failed to connect to standby 'orac2'. Error is 16191.
DEST_NAME ERROR STATUS
---------------------- --------------------------------------- -----------
LOG_ARCHIVE_DEST_1 VALID
LOG_ARCHIVE_DEST_2 ORA-16191: Primary log shipping
client not logged on standby ERROR
LOG_ARCHIVE_DEST_3 INACTIVE
LOG_ARCHIVE_DEST_4 INACTIVE
LOG_ARCHIVE_DEST_5 INACTIVE
LOG_ARCHIVE_DEST_6 INACTIVE
LOG_ARCHIVE_DEST_7 INACTIVE
LOG_ARCHIVE_DEST_8 INACTIVE
LOG_ARCHIVE_DEST_9 INACTIVE
LOG_ARCHIVE_DEST_10 INACTIVE
在Oracle RAC或DG环境中，出现ORA-16191错误，通常是由于两节点密码文件不一致或 remote_login_passwordfile 参数设置不当导致。而本次故障原因并非以上原因所致，客户经过口令文件的重建仍然无法解决问题，在经过分析后确认问题的原因为Oracle 11g的口令安全增强。
Oracle 11g中对于密码安全验证的增强（即Strong Authentification Framework），该增强由初始化参数SEC_CASE_SENSITIVE_LOGON决定，当该参数设置为true时，启用Strong Authentification Framework，false则关闭该增强验证。
当启用强口令认证时，Oracle区分密码大小写，在创建口令文件时，即便口令相同也会在两节点产生不同的HASH值，需要指定ignorecase参数强制忽略大小写才能够保证DG的正常认证（或者在数据库级取消大小写强口令验证）。
在Oracle数据库两节点分别执行如下命令。
节点一：
orapwd file=orapworac1 password=oracle1 ignorecase=y force=y
节点二：
orapwd file=orapworac2 password=oracle1 ignorecase=y force=y
分别查看两节点归档路径信息，log_archive_dest_2状态即恢复正常。
DEST_NAME STATUS ERROR
-------------------------------- ----------------- ------
LOG_ARCHIVE_DEST_1 VALID
LOG_ARCHIVE_DEST_2 VALID
LOG_ARCHIVE_DEST_3 INACTIVE
LOG_ARCHIVE_DEST_4 INACTIVE
LOG_ARCHIVE_DEST_5 INACTIVE
LOG_ARCHIVE_DEST_6 INACTIVE
LOG_ARCHIVE_DEST_7 INACTIVE
LOG_ARCHIVE_DEST_8 INACTIVE
LOG_ARCHIVE_DEST_9 INACTIVE
LOG_ARCHIVE_DEST_10 INACTIVE
在两节点通过多次手动触发日志切换，查看日志归档状态恢复正常，告警日志未再出现由于远程日志传送导致的相关错误信息。
Fri Feb 01 18:15:47 2013
RFS[7]: Archived Log: '/archivelog/rac2/2_83_802962309.dbf'
Fri Feb 01 18:16:17 2013
RFS[7]: Archived Log: '/archivelog/rac2/2_84_802962309.dbf'
Fri Feb 01 18:16:46 2013
RFS[7]: Archived Log: '/archivelog/rac2/2_85_802962309.dbf'
Fri Feb 01 18:16:48 2013
Thread 1 advanced to log sequence 98
Current log# 2 seq# 98 mem# 0: /dev/rlv_redo12
Fri Feb 01 18:17:03 2013
RFS[7]: Archived Log: '/archivelog/rac2/2_86_802962309.dbf'
RFS[7]: Archived Log: '/archivelog/rac2/2_87_802962309.dbf'
Fri Feb 01 18:17:14 2013
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[8]: Assigned to RFS process 1438620
RFS[8]: Identified database type as 'primary cross instance archival'
Fri Feb 01 18:17:14 2013
RFS[7]: Archived Log: '/archivelog/rac2/2_88_802962309.dbf'
RFS[8]: Archived Log: '/archivelog/rac2/2_88_802962309.dbf'
Fri Feb 01 18:17:15 2013
Thread 1 advanced to log sequence 99
Current log# 5 seq# 99 mem# 0: /dev/rlv_redo13
Fri Feb 01 18:17:27 2013
RFS[7]: Archived Log: '/archivelog/rac2/2_89_802962309.dbf'
这个案例给我们的经验是：即便是一个简单的口令文件修改操作，也要考虑到备库等集联因素，避免因为考虑不周导致的数据库故障。