今天在搭建DG的时候碰到了一个蛮有意思的问题，耗费了不少脑细胞，简单记录一下。
首先主库是Queuedb,备库是s2queuedb，使用RMAN的duplicate来搭建，主备库的网络配置listener.ora,tnsnames.ora都没有问题。
但是使用RMAN命令的时候就抛出了下面的错误，从错误信息可以看出来，主库是没有启动起来。
$ rman target sys@Queuedb auxiliary sys@s2queuedb nocatalog
connected to target database: QUEUEDB (not mounted)
using target database control file instead of recovery catalog
auxiliary database Password:
connected to auxiliary database: QUEUEDB (not mounted)
看到这里，心里咯噔一下，难道数据库宕机了?
赶紧连接到主库去看，发现主库的状态都正常，松了一口气，继续在备库看问题的缘由。
在备库端使用TNS的方式连接，抛出了错误，看起来数据库是明显连接到备库了。
$ sqlplus xx/xx@queuedb
ERROR:
ORA-01033: ORACLE initialization or shutdown in progress
Process ID: 0
Session ID: 0 Serial number: 0
但是查看tnsping的结果，和主库的输出一致，完全没问题啊。
而换一个思路，直接连备库，因为还没有open，输出肯定是01033的错误。
$ sqlplus xx/xx@s2queuedb
ERROR:
ORA-01033: ORACLE initialization or shutdown in progress
Process ID: 0
Session ID: 0 Serial number: 0
反反复复确认了主机名的配置，暂时都没有发现问题。带着疑惑也对比了ORACLE_HOME,依然无果。
[oracle@s2queuedb admin]$ ps -ef|grep smon
oracle 43186 1 0 11:15 ? 00:00:00 ora_smon_Queuedb
oracle 43277 43064 0 11:28 pts/0 00:00:00 grep smon
$ cat /proc/43188/environ|xargs -0 -n1|grep ORACLE_HOME
ORACLE_HOME=/U01/app/oracle/product/11.2.0.4
$ echo $ORACLE_HOME
/U01/app/oracle/product/11.2.0.4
所以说上面的检查就只能到这里了，我们得换个思路来看待这个问题。
既然/etc/hosts里面的配置没问题，主机名Queuedb_ZS.test.com指向主库，tnsping没问题，拿我就使用ping来测试。
$ ping Queuedb_ZS.test.com
PING Queuedb_ZS.test.com (127.0.0.1) 56(84) bytes of data.
64 bytes from Queuedb_ZS.test.com (127.0.0.1): icmp_seq=1 ttl=64 time=0.019 ms
64 bytes from Queuedb_ZS.test.com (127.0.0.1): icmp_seq=2 ttl=64 time=0.008 ms
^C
— Queuedb_ZS.test.com ping statistics —
6 packets transmitted, 6 received, 0% packet loss, time 5414ms
rtt min/avg/max/mdev = 0.003/0.007/0.019/0.006 ms
这个结果让我有一种顿悟的感觉，我再次审视/etc/hosts文件的配置。
$ cat /etc/hosts
127.0.0.1 Queuedb_ZS.test.com localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
10.127.128.166 Queuedb_ZS.test.com
10.129.130.190 s2queuedb.test.com
发现竟然在127.0.0.1的地方配置了一个主机名Queuedb_ZS.test.com，这样就会优先去走这个访问路径了，果断删除，再次尝试就没有问题了。
而如果你删除不得当，直接把127.0.0.1的配置全删除了，那么启动监听肯定会抛出下面的错误。
-bash-4.1$ lsnrctl start LISTENER_1528
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=s3nstatdb.test.com)(PORT=1528)))
TNS-12547: TNS:lost contact
TNS-12560: TNS:protocol adapter error
TNS-00517: Lost contact
Linux Error: 104: Connection reset by peer
所以这些看起来琐碎的配置还是尤其需要注意的。
限 时 特 惠： 本站每日持续更新海量各大内部创业教程，一年会员只需98元，全站资源免费下载 点击查看详情
站 长 微 信： lzxmw777
