前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Oracle备库的PDB无法连接的问题(r11笔记第6天)

Oracle备库的PDB无法连接的问题(r11笔记第6天)

作者头像
jeanron100
发布2018-03-21 10:36:40
9040
发布2018-03-21 10:36:40
举报

今天在测试12c的temp_undo的时候,准备在备库上测试一下,突然发现备库使用TNS连接竟然失败。

抛出的错误如下:

$ sqlplus sys/oracle@testdb as sysdba SQL*Plus: Release 12.1.0.2.0 Production on Thu Dec 8 15:30:10 2016 Copyright (c) 1982, 2014, Oracle. All rights reserved. ERROR: ORA-12514: TNS:listener does not currently know of service requested in connect descriptor

尝试连接PDB也是同样的错误。

查看$ORACLE_HOME/network/admin/listener.ora的配置。

已经做了静态注册.

SID_LIST_LISTENER_12c_1526= (SID_LIST= (SID_DESC= (GLOBAL_DBNAME=testdb) (ORACLE_HOME=/home/U01/app/oracle/product/12c/db_1) (SID_NAME=testdb) ) (SID_DESC= (GLOBAL_DBNAME=test) (ORACLE_HOME=/home/U01/app/oracle/product/12c/db_1) (SID_NAME=testdb) ))

查看tnsnames.ora的配置也没有问题,

test = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = xxx)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = test) (SERVER = DEDICATED) ) )

随便查看了一个监听的配置,比如1526

lsnrct status listener_12c_1526,输出也全然没有什么问题,所以自己感觉这问题越发奇怪,甚至还想,莫非又碰到了12c的一个bug了。

如果备库在ADG模式,备库TNS不可用,那备库就没有什么其他的意义了。

这个时候我们还是来看看监听日志,到指定目录下,发现了下面的内容。Thu Dec 08 14:43:17 2016 08-DEC-2016 14:43:17 * (CONNECT_DATA=(SERVICE_NAME=test)(SERVER=DEDICATED)(CID=(PROGRAM=sqlplus)(HOST=testdb2.cyou.com)(USER=oracle) )) * (ADDRESS=(PROTOCOL=tcp)(HOST=xxxx)(PORT=2437)) * establish * test * 12514 TNS-12514: TNS:listener does not currently know of service requested in connect descriptor Thu Dec 08 14:44:46 2016

看着这段内容,感觉哪里好像不大对劲,但是又实在说不出。

查看MOS,和主库反复做监听配置的比对,也没有发现问题,一筹莫展的时候,决定从头开始来看待这个问题。

监听的配置没有问题,根据错误只能指向监听的状态了。

我们来看看监听的进程状态

00:14:32 /home/U01/app/oracle/product/11.2.3/db_1/bin/tnslsnr LISTENER_1522 -inherit 00:13:43 /home/U01/app/oracle/product/11.2.3/db_1/bin/tnslsnr LISTENER_1528 -inherit 00:25:48 /home/U01/app/oracle/product/11.2.3/db_1/bin/tnslsnr LISTENER_1525 -inherit 00:14:35 /home/U01/app/oracle/product/11.2.3/db_1/bin/tnslsnr LISTENER_1523 -inherit 00:00:47 /home/U01/app/oracle/product/12c/db_1/bin/tnslsnr listener_12c_1526 -inherit 00:17:28 /home/U01/app/oracle/product/11.2.3/db_1/bin/tnslsnr LISTENER -inherit

看到这里,决定面壁5分钟。

原来我这个库上最早是安装了11g的ORACLE_HOME,没想到后来整合系统的时候,用了12c,搭建备库的时候,因为主备库的连接配置只设置了1526的端口,其它的都没动,所以n多天后用起来的时候,栽在了这里。

所以修复方式就很简单了,切换到11g的ORACLE_HOME,把之前的监听都停止,然后重新启动12c的监听即可。

所以说透过这个简单的问题,其实可以总结出很多小经验。

  1. 问题解决不能止步于当前,因为偷懒,疏忽导致的后来的潜在问题,遗留问题
  2. 另外一个是标准化,规范化的使用。无规矩不成方圆。
  3. 测试验证,备库搭建完成后,可以做一些简单的应用测试,保证备库在ADG模式下可用
  4. 这个过程中,有一个推理的逻辑不够严谨,连接的端口是1521,而我是用1526来做的简单验证。
  5. 尽管这是一个测试环境,但是还是需要引以为戒。
本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2016-12-08,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 杨建荣的学习笔记 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档