杨建荣的学习笔记

每天坚持一点点,个人微信公众号: jianrong-notes, 个人邮箱:jeanrock@126.com

  • 博客访问: 12590142
  • 博文数量: 1324
  • 用 户 组: 普通用户
  • 注册时间: 2012-05-14 23:24
  • 认证徽章:
个人简介

每日发文,或技术、或总结,偶有日间小事也以为记,谓之学习笔记,成年累月1200多天,中间几乎没有间断,要旨只有一个:学习交流,共同进步 。 学习笔记精华整理,个人新书《Oracle DBA工作笔记》已开售,在京东,当当,亚马逊,淘宝,天猫均有售,欢迎选购。

ITPUB论坛APP

ITPUB论坛APP



APP发帖 享双倍积分

文章分类

全部博文(1324)

文章存档

2017年(250)

2016年(358)

2015年(360)

2014年(278)

2013年(48)

2012年(21)

微信关注

IT168企业级官微



微信号:IT168qiye



系统架构师大会



微信号:SACC2013

订阅
热词专题

分类: Oracle

今天在搭建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这个结果让我有一种顿悟的感觉,我再次审视/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.xx.166  Queuedb_ZS.test.com
10.129.xx.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

所以这些看起来琐碎的配置还是尤其需要注意的。





阅读(1393) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册