[20170825]11G备库启用DRCP连接3.txt

[20170825]11G备库启用DRCP连接3.txt

--//昨天测试了11G备库启用DRCP连接,要设置alter system set audit_trail=none scope=spfile ;
--//参考链接http://blog.itpub.net/267265/viewspace-2144036/.
--//在测试过程中我遇到1个奇怪问题,就是如果主库没有打开drcp,备库执行exec dbms_connection_pool.start_pool();失败.
--//今天分析看看.

1.环境:
SYS@bookdg> @ ver1
PORT_STRING                    VERSION        BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx            11.2.0.4.0     Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

SYS@bookdg> exec dbms_connection_pool.start_pool();
BEGIN dbms_connection_pool.start_pool(); END;

*
ERROR at line 1:
ORA-56501: DRCP: Pool startup failed
ORA-56501: DRCP: Pool startup failed
ORA-06512: at "SYS.DBMS_CONNECTION_POOL", line 4
ORA-06512: at line 1

--//在主库没有启动drcp的情况下,在备库启动会报错.

$ oerr ora 56501
56501, 0000, "DRCP: Pool startup failed"
// *Cause: The connection pool failed to start up.
// *Action: Check logs for details.

2.分析:
--//先做一个10046跟踪看看.

SYS@bookdg> @ &r/10046on 12
old   1: alter session set events '10046 trace name context forever, level &1'
new   1: alter session set events '10046 trace name context forever, level 12'
Session altered.

SYS@bookdg> exec dbms_connection_pool.start_pool();
BEGIN dbms_connection_pool.start_pool(); END;
*
ERROR at line 1:
ORA-56501: DRCP: Pool startup failed
ORA-56501: DRCP: Pool startup failed
ORA-06512: at "SYS.DBMS_CONNECTION_POOL", line 4
ORA-06512: at line 1

SYS@bookdg> @ &r/10046off
Session altered.

--//检查跟踪文件发现如下:
...
=====================
PARSING IN CURSOR #182929053448 len=274 dep=1 uid=0 oct=3 lid=0 tim=1503624921300601 hv=3872345143 ad='7e890610' sqlid='2s0zgjvmcym1r'
SELECT connection_pool_name, status, minsize, maxsize,           incrsize, session_cached_cursors, inactivity_timeout,
max_think_time, max_use_session, max_lifetime_session,           num_cbrok, maxconn_cbrok FROM cpool$           WHERE (connection_pool_name = :1)
END OF STMT
BINDS #182929053448:
Bind#0
  oacdty=01 mxl=32(27) mxlc=00 mal=00 scl=00 pre=00
  oacflg=00 fl2=0000 frm=01 csi=852 siz=32 off=0
  kxsbbbfp=2a97747a38  bln=32  avl=27  flg=05
  value="SYS_DEFAULT_CONNECTION_POOL"
EXEC #182929053448:c=999,e=178,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=1,plh=1895327128,tim=1503624921300745
FETCH #182929053448:c=0,e=30,p=0,cr=2,cu=0,mis=0,r=1,dep=1,og=1,plh=1895327128,tim=1503624921300818
EXEC #182928806584:c=999,e=502,p=0,cr=2,cu=0,mis=0,r=0,dep=0,og=1,plh=0,tim=1503624921300951
ERROR #182928806584:err=56501 tim=1503624921300974
WAIT #182928806584: nam='SQL*Net break/reset to client' ela= 4 driver id=1650815232 break?=1 p3=0 obj#=5762 tim=1503624921301028
WAIT #182928806584: nam='SQL*Net break/reset to client' ela= 53 driver id=1650815232 break?=0 p3=0 obj#=5762 tim=1503624921301103
WAIT #182928806584: nam='SQL*Net message to client' ela= 2 driver id=1650815232 #bytes=1 p3=0 obj#=5762 tim=1503624921301128

*** 2017-08-25 09:35:25.227
WAIT #182928806584: nam='SQL*Net message from client' ela= 3926451 driver id=1650815232 #bytes=1 p3=0 obj#=5762 tim=1503624925227651
CLOSE #182928806584:c=0,e=41,dep=0,type=0,tim=1503624925227808
=====================

--//很明显因为访问底层基表cpool$
SYS@bookdg> @ &r/pt2 'select * from cpool$';
ROW_NUM COL_NUM COL_NAME               COL_VALUE
------- ------- ---------------------- ----------------------------
      1       1 CONNECTION_POOL_NAME   SYS_DEFAULT_CONNECTION_POOL
              2 STATUS                 INACTIVE
              3 MINSIZE                4
              4 MAXSIZE                40
              5 INCRSIZE               2
              6 SESSION_CACHED_CURSORS 20
              7 INACTIVITY_TIMEOUT     300
              8 MAX_THINK_TIME         120
              9 MAX_USE_SESSION        500000
             10 MAX_LIFETIME_SESSION   86400
             11 NUM_CBROK              1
             12 MAXCONN_CBROK          40000
12 rows selected.

--//而且在执行成功后STATUS='ACTIVE'.也就是exec dbms_connection_pool.start_pool();后如果STATUS='INACTIVE'要变成'状态是'ACTIVE'.
--//执行类似的dml语句,这在备库read only的情况下是不可行的.知道这个道理就明白为什么要在主库先执行exec dbms_connection_pool.start_pool();
--//修改STATUS='ACTIVE',这样备库也跟着修改.在备库执行exec dbms_connection_pool.start_pool();才能OK了.

3.有了以上知识,就可以通过一个特殊的例子说明问题.

--//在主库上执行如下,启动drcp.
SYS@book> exec dbms_connection_pool.start_pool()
PL/SQL procedure successfully completed.

--//检查备库
SYS@bookdg> @ &r/pt2 'select * from cpool$';
ROW_NUM    COL_NUM COL_NAME               COL_VALUE
------- ---------- ---------------------- ---------------------------
      1          1 CONNECTION_POOL_NAME   SYS_DEFAULT_CONNECTION_POOL
                 2 STATUS                 ACTIVE
                 3 MINSIZE                4
                 4 MAXSIZE                40
                 5 INCRSIZE               2
                 6 SESSION_CACHED_CURSORS 20
                 7 INACTIVITY_TIMEOUT     300
                 8 MAX_THINK_TIME         120
                 9 MAX_USE_SESSION        500000
                10 MAX_LIFETIME_SESSION   86400
                11 NUM_CBROK              1
                12 MAXCONN_CBROK          40000
12 rows selected.

--//取消redo应用.
SYS@bookdg> alter database recover managed standby database cancel ;
Database altered.

--//在主库上执行如下,停止drcp.
SYS@book> exec dbms_connection_pool.stop_pool()
PL/SQL procedure successfully completed.

SYS@book> select CONNECTION_POOL_NAME,STATUS from cpool$;
CONNECTION_POOL_NAME        STATUS
--------------------------- ---------
SYS_DEFAULT_CONNECTION_POOL INACTIVE

--//由于停止备库的日志应用,cpool$的记录不会修改.依旧是status='ACTIVE'
SYS@bookdg> select CONNECTION_POOL_NAME,STATUS from cpool$;
CONNECTION_POOL_NAME        STATUS
--------------------------- -------
SYS_DEFAULT_CONNECTION_POOL ACTIVE

SYS@bookdg> exec dbms_connection_pool.start_pool();
PL/SQL procedure successfully completed.

$ sqlplus scott/book@192.168.100.40:1521/bookdg:POOLED
--//测试连接ok.

--//同样的道理在当前的状态,无法在备库执行exec dbms_connection_pool.stop_pool();因为这样要修改staus,
--//而只读数据库是无法执行dml语句的.
SYS@bookdg> exec dbms_connection_pool.stop_pool();
BEGIN dbms_connection_pool.stop_pool(); END;
*
ERROR at line 1:
ORA-56506: DRCP: Pool shutdown failed
ORA-56506: DRCP: Pool shutdown failed
ORA-06512: at "SYS.DBMS_CONNECTION_POOL", line 16
ORA-06512: at line 1

--//而同步应用日志后,status变成了'INACTIVE',在备库再执行停止drcp就ok了.
SYS@bookdg> alter database recover managed standby database using current logfile disconnect ;
Database altered.

SYS@bookdg> select CONNECTION_POOL_NAME,STATUS from cpool$;
CONNECTION_POOL_NAME        STATUS
--------------------------- ---------
SYS_DEFAULT_CONNECTION_POOL INACTIVE

SYS@bookdg> exec dbms_connection_pool.stop_pool();
PL/SQL procedure successfully completed.

时间: 2024-09-22 13:45:23

[20170825]11G备库启用DRCP连接3.txt的相关文章

[20170824]11G备库启用DRCP连接.txt

[20170824]11G备库启用DRCP连接.txt --//参考链接: http://blog.itpub.net/267265/viewspace-2099397/ blogs.oracle.com/database4cn/adg%e5%a4%87%e5%ba%93%e7%9a%84drcp%e8%bf%9e%e6%8e%a5%e6%8a%a5%e9%94%99oci-21500%e8%a7%a3%e5%86%b3%e4%b8%80%e4%be%8b 1.测试环境: SYS@bookdg>

11g备库无法开启ADG的原因分析

今天碰到一个有些奇怪的问题,但是奇怪的现象背后都是有本质的因果. 下午在做一个环境的检查时,发现备库是在mount阶段,这可是一个11gR2的库,没有ADG实在是太浪费了,对于这种情况感觉太不应该了. 所以尝试启动至open阶段,发现状态一直是read only,在ADG中应该是READ ONLY WITH APPLY才对啊. 使用dg broker设置为READ-ONLY,备库的数据库日志如下:      Standby Database:           stestdb3, Enable

11g备库中碰到自己给自己埋的坑

记得之前在一半技术一半生活中分享过一个设计,因为业务的需求,为了提高业务的处理效率,采用了根据业务的拆库拆表的方式,类似下面的图示. 开发团队也很给力,帮我们协调了好的机器,加了内存,也在新业务2的环境上同步了表结构,抽取了部分数据,然后业务2就开始了紧张的测试, 通过这几天的测试,发现系统的性能逐步稳定下来.忙完了这茬,赶紧来考虑搭建备库. 自己也算是搭建过很多dataguard环境了,一般的环境中检测dataguard搭建成功与否的一种方式就是使用dg broker来验证,一条简单的show

Oracle备库TNS连接失败的分析

今天在测试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:listen

备库密码文件问题一波三折的插曲

昨天下午开始给一个新环境搭备库,本来想一两个小时全速搞定,没想到因为密码文件的问题耽搁了,整个过程也是一波三折,希望大家能够吸取过程之中的经验和教训. 首先这个环境没有安装oracle软件,只安装了操作系统,所以搭建备库先需要安装数据库软件,然后开始从主库使用duplicate的方式同步数据文件,然后用dg broker来配置即可. 没有安装数据库软件,又没有图形界面,也好办,采用克隆方式安装 首先在主库中发现$ORALE_HOME下有一个压缩包,看来已经提前准备好了. /U01/app/ora

Oracle 11g Dataguard物理备库配置(六) broker fastfailover测试

本文采用Oracle 11g Dataguard broker fastfailover测试 Oracle 11g Dataguard fast failover配置,需要主备数据库开启闪回功能,闪回功能开启本文略过. 闪回开启需要启动到mount状态时,主备库的监听不要随意关闭. 1. dgmgrl查看主备库状态 $ dgmgrl sys/oracle DGMGRL for Linux: Version 11.2.0.3.0 - 64bit Production Copyright (c) 2

Oracle 11g Dataguard物理备库配置(四) broker snapshot standby测试

Oracle 11g Dataguard Snapshot Standby数据库功能,可将备库置于打开读写状态,进行模拟生产环境主库中测试.当备库Snapshot standby任务完成后,可以切换回物理备库角色.在Snapshot Standby数据库状态下,备库是可以接受主库传过来的日志,但是不能够将变化应用在备库中. 本文采用Oracle 11g Dataguard broker snapshot standby配置 1. 采用dg broker配置snapshot standby配置 1

Oracle 11g Dataguard物理备库配置(五) broker switchover测试

本文采用Oracle 11g Dataguard broker switchover测试 1. 采用dataguard broker 测试switchover 1) 主库情况 SQL> select open_mode,database_role,db_unique_name from v$database; OPEN_MODE            DATABASE_ROLE    DB_UNIQUE_NAME -------------------- ---------------- ---

Oracle 11g Dataguard物理备库配置(二) Active Dataguard测试

在Oracle 11g之前,物理备库(physical Standby)在应用redo的时候,数据库需要处于mount状态.从11g开始,应用redo的时候,物理备库可以处于read-only模式,这就称为Active Data Guard,这种状态可以实现实时查询功能. 1. 备库上操作 1) 查看备库当前状态 mount SQL> select open_mode,database_role,db_unique_name from v$database; OPEN_MODE