备库密码文件问题一波三折的插曲(r6笔记第83天)

昨天下午开始给一个新环境搭备库，本来想一两个小时全速搞定，没想到因为密码文件的问题耽搁了，整个过程也是一波三折，希望大家能够吸取过程之中的经验和教训。

首先这个环境没有安装oracle软件，只安装了操作系统，所以搭建备库先需要安装数据库软件，然后开始从主库使用duplicate的方式同步数据文件，然后用dg broker来配置即可。

没有安装数据库软件，又没有图形界面，也好办，采用克隆方式安装

首先在主库中发现$ORALE_HOME下有一个压缩包，看来已经提前准备好了。

/U01/app/oracle/product]$ ll

total 2288996

drwxrwxr-x 3 oracle oinstall 4096 Mar 20 2012 11.2.3

-rw-r--r-- 1 root root 2341630235 Aug 4 18:11 11.2.3.tgz

从文件内容来看压缩包实在近期压缩的，所以还是一个比较新的包，直接拷贝到备库就能用了。

$ file 11.2.3.tgz

11.2.3.tgz: gzip compressed data, from Unix, last modified: Fri Jul 31 11:48:23 2015

拷贝过去之后，创建用户，用户组，然后在备库的$ORACLE_HOME/clone/bin下直接运行下面的脚本就会开始克隆安装。大概一两分钟数据库软件就安装好了。

perl clone.pl ORACLE_BASE=/U01/app/oracle ORACLE_HOME=/U01/app/oracle/product/11.2.3/db_1 ORACLE_HOME_NAME=OraDb11g_home1

然后配置网络服务，准备就开始使用duplicate的方式同步备库了。

但是在开始同步前发现就卡在了密码文件上。

因为使用tns连接的时候报了ORA错误。

/U01/app/oracle/product/11.2.3/db_1/dbs]$ sqlplus sys@s2test as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Thu Oct 8 19:19:13 2015

Copyright (c) 1982, 2011, Oracle. All rights reserved.

Enter password:

ERROR:

ORA-01017: invalid username/password; logon denied

通过这个错误可以得知应该是密码错误，但是密码文件没有做任何的改动也是从主库拷贝过来的。

在备库通过tns连接主库就没有问题。

/U01/app/oracle/product/11.2.3/db_1/network/admin]$ sqlplus sys@test as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Fri Oct 9 00:00:20 2015

Copyright (c) 1982, 2011, Oracle. All rights reserved.

Enter password:

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL>

这个时候因为一直坚信密码文件没有做任何变动，所以注意力就集中在了其它的方面，首先是主机名上，发现主机名和主库的uniq_name有些冲突，感觉是主机名导致的，就开始尝试改主机名，改了之后发现错误果真变了。

$ sqlplus sys@s2test as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Thu Oct 8 19:21:18 2015

Copyright (c) 1982, 2011, Oracle. All rights reserved.

Enter password:

ERROR:

ORA-21561: OID generation failed

这个错误比较熟悉，和/etc/hosts的配置相关，所以修复之后还是依旧提示备库密码错误。

这个时候进一步排查，如果密码文件没有成功启用，是不是和系统级的权限有关，结果查看到用户的id,用户组时，发现了一点问题。

备库中的id为

$ id oracle

uid=500(oracle) gid=500(oinstall) groups=500(oinstall),501(dba)

主库中的id为

$ id oracle

uid=501(oracle) gid=501(oinstall) groups=501(oinstall),502(dba)

可以看到用户组的id还是有一些差别，所以有种强烈的感觉就是问题应该出在这个地方，对于rac中这个差别还是很严重的，没想到在dataguard中也有这样的影响。

于是开始修改用户组。

# usermod -u 501 oracle

# id oracle

uid=501(oracle) gid=500(oinstall) groups=500(oinstall),501(dba)

发现用户组没有生效。但是/etc/group中已经生效了

# cat /etc/group|grep oinstall

oinstall:x:501:

继续改动，这样就可以了。

# usermod -g oinstall -G dba oracle

# id oracle

uid=501(oracle) gid=501(oinstall) groups=501(oinstall),502(dba)

不过用户组修改完成，用户下的文件的属主还是有问题，组名显示成了500

/U01/app/oracle/product/11.2.3/db_1/dbs]$ ll

total 12

-rw-r--r-- 1 500 500 953 Oct 8 17:25 inittest.ora

-rw-r----- 1 500 500 1536 Jun 17 2013 orapwtest

-rw-r----- 1 500 500 2560 Oct 8 19:44 spfiletest.ora

所以最后还是重新安装数据库软件了事，安装完之后，带着期待继续尝试，发现问题还是没有解决。

$ sqlplus sys@s2test as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Fri Oct 9 00:00:13 2015

Copyright (c) 1982, 2011, Oracle. All rights reserved.

Enter password:

ERROR:

ORA-01017: invalid username/password; logon denied

通过tns连接主库还是正常。

然后反复测试还发现一个更加奇怪的现象。初步感觉是权限哪里出了问题，于是尝试先把密码文件改成777的权限。

$ chmod 777 orapwtest

$ ll orapwtest

-rwxrwxrwx 1 oracle oinstall 1536 Jun 17 2013 orapwtest

然后继续尝试登录。

$ sqlplus sys@s2test as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Fri Oct 9 19:45:43 2015

Copyright (c) 1982, 2011, Oracle. All rights reserved.

Enter password:

ERROR:

ORA-01017: invalid username/password; logon denied

抛完错误之后再次查看密码文件，发现原有的密码文件的权限又恢复成了最开始状态。

$ ll orapwtl*

-rw-r----- 1 oracle oinstall 1536 Jun 17 2013 orapwtest

反复尝试都是如此，自己甚至怀疑是不是oracle的网络服务相关的软件包出了问题，或者是什么bug导致的。

最后看着密码文件，觉得还是要验证一下，首先密码文件中的内容是无法读到的，单纯看朱备库的文件大小都是1536字节，时间点也比较早，想必一直也没有改动过。

最后甚至动用了strace来做诊断，结果竟然还是没有发现任何的差别，可见系统级还是没有什么差别的。

那么密码文件怎么来解析看看主备库是否一致呢。直接解析不成，我们使用strings来做。

主库中的密码文件trace如下：

$ strings orapwtest

]\[Z

ORACLE Remote Password file

INTERNAL

9B811A3069EE43B6

3C0E90D8664116E3

bF(0

备库中的密码文件trace如下：

$ strings orapwtest

]\[Z

ORACLE Remote Password file

INTERNAL

F309445D01B9354C

bHB!

B3EBA9B843B3A7D2

可以看出还是存在明显的不同，再次手工拷贝一份密码文件到备库，再做一次trace

$ strings orapwtest

]\[Z

ORACLE Remote Password file

INTERNAL

9B811A3069EE43B6

3C0E90D8664116E3

bF(0

这次就和主库一致了，尽管时间戳不同，但是从trace来看内容是一致的了。

$ ll orapwtest

-rw-r----- 1 oracle oinstall 1536 Oct 9 19:52 orapwtest

然后再次尝试，就正常了。

$ sqlplus sys@s2tset as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Fri Oct 9 19:53:39 2015

Copyright (c) 1982, 2011, Oracle. All rights reserved.

Enter password:

Connected to an idle instance.

问题到此还没有结束，自己还是对于用户组的问题带有疑惑，趁热打铁，把环境刷掉，再试一试用户组不同的时候，是否有影响，

# groupmod -g 506 oinstall

# id oracle

uid=501(oracle) gid=501 groups=501,502(dba)

# usermod -g oinstall -G dba oracle

# id oracle

uid=501(oracle) gid=506(oinstall) groups=506(oinstall),502(dba)

然后把原来的$ORACLE_HOME删掉重新克隆安装一遍。重新同步密码文件，尝试发现还是可以的。

$ sqlplus sys@s2test as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Fri Oct 9 20:07:05 2015

Copyright (c) 1982, 2011, Oracle. All rights reserved.

Enter password:

Connected to an idle instance.

SQL>

所以这个时候自己基本可以论证出问题不在主机名，不在用户组的id，而是因为密码文件的不同导致了这么多的插曲，自己也尝试了各种方法，尽管知道问题出在 密码文件上，但是竟然没有专门去验证一下密码文件，带着想当然的态度认为压缩包最近更新的，所以密码文件应该是一样的。这个经验教训很深刻，大家也需要注 意一下。