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'

这个案例给我们的经验是：即便是一个简单的口令文件修改操作，也要考虑到备库等集联因素，避免因为考虑不周导致的数据库故障。