oracle 12.1.0.2的mgmt 导致的ORA-01017 bug

两节点12c RAC，在两节点上export ORACLE_SID再sqlplus / as sysdba都正常登录，然而Commvault通过service_name方式（sqlplus sys/password@service_name as sysdba）登录则是在节点1正常，而节点2报：

ORA-01017: invalid username/password; logon denied 

测试一：1.怀疑是密码文件错误，通守PWD 重生成文件，问题未解决

测试二：2.创建普通用户测试，发现测试帐号节点一可以通过物理IP，VIP连接，节点二不可以连

测试三：3.把节点重启，此时节点二也不可以连接 

通过查询文档，网上有一篇 现象和此类似的情况，并按照文档操作，问题得以解决：https://blogs.oracle.com/database4cn/12cchm-bugora-01017 

4、对节点2的service连接做了strace：

 strace -fo /tmp/strace_ONE.output sqlplus ONE/password@ONE_TEST

并在设置了ORA-1017的errorstack（ errorstack对于这种口令错误问题没什么用，但通过它可以判断连接在哪个实例上遇到的ORA-01017错误）：

alter system set events '1017 trace name ERRORSTACK level 3';

然而重现问题之后，两实例上均无errorstack trace生成，alert log中也没有ORA-01017的记录。

故此怀疑报错的实例并非是这两个。

5、通过strace输出发现走了nameserver。但客户并没用到GNS解析，且只使用vip连接。建议客户将/etc/resolv.conf中的nameserver行注释掉看看。注释掉之后问题依旧，但从strace上已可以完全确定ORA-01017报错还是发生在本地库上。

6、回想起一开始检查listener status输出时曾发现如下可疑情况：

$lsnrctl status

... 

Service "ONE" has 2 instance(s).

 Instance "-MGMTDB", status READY, has 1 handler(s) for this service...<===

 Instance "ONE2", status READY, has 1 handler(s) for this service...

当时询问客户怎么这个service下多了个mgmtdb实例，客户说这个应该是12c自带的吧，所以并没在意。

但是它们在同一个service下，如果连接被传递给mgmtdb实例的话，那么肯定会发生ora-01017。查了下mgmtdb的用途，发现其与12c的新特性有关：原本在11g中由Berkeley DB管理的CHM repository改成了Oracle db管理：

MGMTDB is new database instance which is used for storing Cluster Health Monitor (CHM) data. In 11g this was being stored in berkley database but starting Oracle database 12c it is configured as  Oracle Database Instance.

7、于是建议客户将mgmtdb停掉试试。客户反馈停掉之后果然正常连接了。

8、进一步查看相关文档，发现如下bug：

MGMTDB registers Database Service (Doc ID 2063662.1)

GIMR (Management Database) Registers Into Same Service that the Database Instance also registers On RAC (Doc ID 2024572.1)

该问题在数据库与cluster name同名时发生，会导致mgmtdb把自己注册到这个与cluster name同名数据库的default service下。

经客户确认，其数据库名的确与Cluster name相同。 

文档中给出的Workaround有二：

一是办法将GIMR重建到不同的共享存储上；

另一个办法是按Doc ID 2024572.1给mgmtdb配置local_listener。当然如果可以使用不同的dbname重建数据库则是从根本上避免此bug。

应该还有个办法是通过srvctl stop mgmtdb和srvctl disable mgmtdb来禁用它，但Oracle不推荐将其禁用，因为使用opatchauto打psu时会去尝试启动mgmtdb，如果发现它被disable，则会报错：

PRCR-1005 : Resource ora.mgmtdb is already stopped

来源： https://blogs.oracle.com/database4cn/12cchm-bugora-01017

1)connect to MGMTDB
$ export ORACLE_SID=-MGMTDB
$ sqlplus / as sysdba
2)modify local_listener of MGMTDB
SQL> alter system set local_listener='(ADDRESS=(PROTOCOL=TCP)(HOST=<node1 interconnect IP>)(PORT=<mgmtlsnr port number>))','(ADDRESS=(PROTOCOL=TCP)(HOST=<node2 interconnectのIP>)(PORT=<mgmtlsnr port number>))' scope=both;

5

 

1

1)connect to MGMTDB

2

$ export ORACLE_SID=-MGMTDB

3

$ sqlplus / as sysdba

4

2)modify local_listener of MGMTDB

5

SQL> alter system set local_listener='(ADDRESS=(PROTOCOL=TCP)(HOST=<node1 interconnect IP>)(PORT=<mgmtlsnr port number>))','(ADDRESS=(PROTOCOL=TCP)(HOST=<node2 interconnectのIP>)(PORT=<mgmtlsnr port number>))' scope=both;

来源： https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=162799663872500&parent=DOCUMENT&sourceId=2063662.1&id=2024572.1&_afrWindowMode=0&_adf.ctrl-state=18m05itvb2_109

来自为知笔记(Wiz)