dataguard环境中的密码维护

这篇文章的动力来自于一个朋友的提问，他问我备库的密码文件直接重建可以吗，我说最好还是复制，如果重建可能会有一些潜在的问题，当然这个所谓潜在问题也是自己给自己打的马虎眼，到底哪里有问题，脑海里搜索了一番似乎没有找到什么有效的信息，但是隐隐之中感觉搭建dataguard好像还从来没有直接重建密码文件的时候，似乎是一种非常规的方式，但是转眼一想一旦发生这种情况的时候，或者密码文件出现了一些潜在问题的时候，怎么有效防范，这个问题就又上升了一个高度，所以我对这个问题做了一些初步的分析，然后在网上竟然看到还真有一些技术大拿对这类看起来细节问题做了深入的解析，我想我就不用再重新写了，直接把他的成果拿过来分享给大家。

文章来自于下面的链接，感兴趣可以看一下。

https://prutser.wordpress.com/2011/06/13/password-file-maintenance-in-a-data-guard-environment/

自己简单翻译了一下。

这篇文章会提到另外一个问题：在dataguard环境中，对于密码文件的维护管理有什么特别注意的地方吗？

答案是肯定的，在Data Guard环境中更新密码文件并没有想象的那样简单。在会基于这个问题得

我们首先看看我的当前dataguard配置情况，然后再来深入密码文件的一些细节过程。

DGMGRL> show configuration;

Configuration - PeppiEnKokki

  Protection Mode: MaxPerformance

  Databases:

    peppi - Primary database

    kokki - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:

SUCCESS

这个输出可以看到当前存在一个主库peppi,一个物理备库kokki，dataguard环境整体的状态是success.

特别需要说明的是peppi在host pruster，kokki运行在el5上

提出问题

第一个问题是：如果在主库的密码文件做了变更，是否会传播到备库去？我们可以在主库peppi中进行简单的验证，即在主库更新密码文件，然后在备库kokki中查看密码文件的情况。

SQL> connect sys/oracle@peppi as sysdba

Connected.

SQL> select * from v$pwfile_users;

USERNAME                       SYSDB SYSOP SYSAS

------------------------------ ----- ----- -----

SYS                            TRUE  TRUE  FALSE

当前主库peppi所在的密码文件只存在一条记录，如果赋予sysdba给system用户会触发密码文件的更新

SQL> grant sysdba to system;

Grant succeeded.

SYSTEM                         TRUE  FALSE FALSE

这样，主库的密码文件中就会存在两条记录了，那么在备库中存在几条记录呢？

SQL> connect sys/oracle@kokki as sysdba

这个输出很清晰地看出主库的密码文件变更并没有传输到备库

然后我们收回system的sysdba权限，因为我们还是不希望system的权限过于宽泛？

SQL> revoke sysdba from system;

Revoke succeeded.

这样对dataguard会有影响吗?

接下来的问题是: 这样对dataguard是否有影响?主库到备库的redo传输需要通过密码文件中的sys用户密码来进行认证，如果在主库配置了其它的sysdba用户也可以，但问题是主库的redo传输是通过密码文件像sys一样的用户来作为认证基础的，一旦主库加密后的密码和备库不一致，那么redo传输就会有麻烦。

?如果需要验证这个问题，可以通过修改peppi中的sys密码，然后看看是如何影响kokki的。

SQL> alter user sys identified by prutser;

User altered.

SQL> connect sys/prutser@peppi as sysdba

SQL> connect sys/prutser@kokki as sysdba

ERROR:

ORA-01017: invalid username/password; logon denied

Warning: You are no longer connected to ORACLE.

上面的输出很明显再次看到主库中的密码文件变更不会自动传播到备库。

但是事实上，我们在备库kokki上依旧可以使用原来的密码文件，如下：

然后第二个问题是：如果密码文件已经不一致的情况下，redo是否能够正常传输？对这个问题，我们在主库切换一次日志来验证一下。

SQL> alter system switch logfile;

System altered.

通过上面的输出我们可以看到，竟然结果都是正常的，很明显密码文件的变化不会直接影响到redo的传输，这是因为主库和备库已经建立了连接，对于redo的部分，备库就不需要再次获得主库的重新认证了。但是一旦重置redo的传输，就会很清楚的看到会存在问题。

DGMGRL> edit database kokki set property LogShipping=off;

Property "logshipping" updated

DGMGRL> edit database kokki set property LogShipping=on;

      Error: ORA-16778: redo transport error for one or more databases

ERROR

通过这可以很清晰的看到redo的传输中断了然后提示了ORA-16778的错误，如果主库的密码文件一旦发生改变，那么不会马上暴露出问题，但是可能在后来的某一个时间点爆发。

那么ORA-16778 错误代表什么含义？

$ oerr ora 16778

16778, 00000, "redo transport error for one or more databases"

// *Cause:  The redo transport service was unable to send redo data to one

//          or more standby databases.

// *Action: Check the Data Guard broker log and Oracle alert log for

//          more details. Query the LogXptStatus property to see the

//          errors.

我们刚刚已经在主库修改了sys的密码，这个时候的问题是怎么修复？

探索答案：

可能我们可以简单的通过在kokki上面重建密码文件得以解决，让我们试一试。

el5$ rm $ORACLE_HOME/dbs/orapwv1120

el5$ orapwd file=$ORACLE_HOME/dbs/orapwv1120 password=prutser

看起来似乎是可以的，但是问题是dataguard是否如此乐观的认为问题已经解决了呢？

这个时候发现情况没有看上去那么好了，是不是我们需要重置一下redo的传输，我们来简单验证一下。

这个时候还是不奏效，在备库重建密码文件看来不是解决方法了，因为密码文件是加密的，尽管密码是相当的，但是加密之后的效果不同。

那么如果从主库拷贝密码问价到备库的话怎么样呢？

我们尝试拷贝密码文件到备库kokki，然后看看效果：

$ scp $ORACLE_HOME/dbs/orapwv1120 el5:$ORACLE_HOME/dbs/orapwv1120

orapwv1120                                    100% 1536     1.5KB/s   00:00    

这个时候我们可以在kokki使用sys接入实例了，那么dataguard这边确实ok了吗？

再一次证明dataguard还是不够满意，但是看起来一切已经和原来一样了，如果我们稍作等待然后再次开启归档日志的传输，就会连带redo的传输，当然这个过程可以通过禁用启用redo传输来完成。

最终dataguard的状态终于正常了，因为主库的redo传输到备库已经正常了。

总结：

如果需要保证dataguard的可持续性，如果主库存在任何密码文件的变更，我们必须从主库拷贝密码文件到备库.最后是一句 Happy Data Guarding ;-)