Oracle Dataguard备库失败与主库响应测试方案

63 阅读 0 评论 42 点赞

我是靠谱客的博主魁梧纸鹤，最近开发中收集的这篇文章主要介绍Oracle Dataguard备库失败与主库响应测试方案，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

在客户环境中，应用了Oracle 10.2.0.4 DataGuard技术，透过最大可用性形式进展数据保护。

　　以次简略测试，应备库封闭后，再重启备库，主库及备库的响应历程。

　　在备库实施如次方法：

　　SQL> shutdown immediate;

　　ORA-01109: database not open

　　Database dismounted.

　　ORACLE instance shut down.

　　SQL> startup mount;

　　ORACLE instance started.

　　Total System Global Area 1610612736 bytes

　　Fixed Size 2084400 bytes

　　Variable Size 385876432 bytes

　　Database Buffers 1207959552 bytes

　　Redo Buffers 14692352 bytes

　　Database mounted.

　　SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

　　Database altered.

　　SQL> exit

　　应备库封锁后，主库马上检测到备库的失败：

　　Tue Nov 17 20:34:58 2009

　　ARC一: Attempting destination LOG_ARCHIVE_DEST_二 network reconnect (3113)

　　ARC一: Destination LOG_ARCHIVE_DEST_二 network reconnect abandoned

　　PING[ARC一]: Error 3113 when pinging standby STANDBY.

　　Tue Nov 17 20:35:17 2009

　　LGWR: Attempting destination LOG_ARCHIVE_DEST_二 network reconnect (3113)

　　LGWR: Destination LOG_ARCHIVE_DEST_二 network reconnect abandoned

　　Tue Nov 17 20:35:17 2009

　　Errors in file /opt/oracle/admin/oradbt/bdump/oradbt_lgwr_319632.trc:

　　ORA-03113: end-of-file on communication channel

　　LGWR: Network asynch I/O wait error 3113 log 一 service 'STANDBY'

　　Tue Nov 17 20:35:17 2009

　　Destination LOG_ARCHIVE_DEST_二 is UNSYNCHRONIZED

　　LGWR: Failed to archive log 一 thread 一 sequence 3466 (3113)

　　Tue Nov 17 20:35:18 2009

　　LGWR: Closing remote archive destination LOG_ARCHIVE_DEST_二: 'STANDBY' (error 3113)

　　(oradbt)

　　Tue Nov 17 20:35:18 2009

　　Errors in file /opt/oracle/admin/oradbt/bdump/oradbt_lgwr_319632.trc:

　　ORA-01041: internal error. hostdef extension doesn't exist

　　LGWR: Error 1041 closing archivelog file 'STANDBY'

　　LGWR: Error 1041 disconnecting from destination LOG_ARCHIVE_DEST_二 standby host 'STANDBY'
应备库重启后：

　　Tue Nov 17 20:35:23 2009

　　Thread 一 advanced to log sequence 3467 (LGWR switch)

　　Current log# 二 seq# 3467 mem# 零: /redodata/oradbt/redo02.log

　　Tue Nov 17 20:38:34 2009

　　Thread 一 advanced to log sequence 3468 (LGWR switch)

　　Current log# 三 seq# 3468 mem# 零: /redodata/oradbt/redo03.log

　　Tue Nov 17 20:39:59 2009

　　Thread 一 cannot allocate new log, sequence 3469

　　Checkpoint not complete

　　Current log# 三 seq# 3468 mem# 零: /redodata/oradbt/redo03.log

　　LNSb started with pid=19, OS id=573716

　　Tue Nov 17 20:40:05 2009

　　Destination LOG_ARCHIVE_DEST_二 is SYNCHRONIZED

　　LGWR: Standby redo logfile selected to archive thread 一 sequence 3469

　　LGWR: Standby redo logfile selected for thread 一 sequence 3469 for destination LOG_ARCHIVE_DEST_二

　　Tue Nov 17 20:40:05 2009

　　Thread 一 advanced to log sequence 3469 (LGWR switch)

　　Current log# 一 seq# 3469 mem# 零: /redodata/oradbt/redo01.log

　　Tue Nov 17 20:40:05 2009

　　ARC零: LGWR is actively archiving destination LOG_ARCHIVE_DEST_二

　　ARC零: Standby redo logfile selected for thread 一 sequence 3468 for destination LOG_ARCHIVE_DEST_二

　　此时此刻备库也回复了同步：

　　Tue Nov 17 20:35:30 2009

　　ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION

　　Tue Nov 17 20:35:30 2009

　　Attempt to start background Managed Standby Recovery process (oradbt)

　　MRP零 started with pid=19, OS id=254276

　　Tue Nov 17 20:35:30 2009

　　MRP零: Background Managed Standby Recovery process started (oradbt)

　　Managed Standby Recovery not using Real Time Apply

　　parallel recovery started with 11 processes

　　Tue Nov 17 20:35:35 2009

　　Waiting for all non-current ORLs to be archived...

　　Media Recovery Waiting for thread 一 sequence 3466

　　Tue Nov 17 20:35:36 2009

　　Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION

　　Redo Shipping Client Connected as PUBLIC

　　-- Connected User is Valid

　　RFS[一]: Assigned to RFS process 172068

　　RFS[一]: Identified database type as 'physical standby'

　　Tue Nov 17 20:39:58 2009

　　RFS LogMiner: Client disabled from further notification

　　RFS[一]: Archived Log: '/oradata/archive/一_3466_690213276.dbf'

　　RFS[一]: Archived Log: '/oradata/archive/一_3467_690213276.dbf'

　　Tue Nov 17 20:40:00 2009

　　Media Recovery Log /oradata/archive/一_3466_690213276.dbf

　　Media Recovery Log /oradata/archive/一_3467_690213276.dbf

　　Media Recovery Waiting for thread 一 sequence 3468

　　Tue Nov 17 20:40:05 2009

　　Redo Shipping Client Connected as PUBLIC

　　-- Connected User is Valid

　　RFS[二]: Assigned to RFS process 1441960

　　RFS[二]: Identified database type as 'physical standby'

　　Primary database is in MAXIMUM AVAILABILITY mode

　　Changing standby controlfile to RESYNCHRONIZATION level

　　Primary database is in MAXIMUM AVAILABILITY mode

　　Changing standby controlfile to MAXIMUM AVAILABILITY level

　　RFS[二]: Successfully opened standby log 四: '/redodata/oradbt/stdrd一.log'
Tue Nov 17 20:40:05 2009

　　Redo Shipping Client Connected as PUBLIC

　　-- Connected User is Valid

　　RFS[三]: Assigned to RFS process 1442140

　　RFS[三]: Identified database type as 'physical standby'

　　RFS[三]: Successfully opened standby log 五: '/redodata/oradbt/stdrd二.log'

　　Tue Nov 17 20:40:06 2009

　　Media Recovery Log /oradata/archive/一_3468_690213276.dbf

　　Media Recovery Waiting for thread 一 sequence 3469 (in transit)

　　稽查主库的LGWR日记，可以看到整个进程的靠山处置：

　　*** 2009-11-17 20:35:23.248 64165 kcrr.c

　　LGWR: Error 1041 disconnecting from destination LOG_ARCHIVE_DEST_二 standby host 'STANDBY'

　　Ignoring krslcmp() detach error 1041

　　kcrrtsync: Standby mount ID 零xc896b692 not found

　　*** 2009-11-17 20:35:23.249 2342 krsl.c

　　No standby database destinations have been configured

　　as being archived by the LGWR process

　　This instance will operate at a reduced protection mode until

　　network connectivity to the standby databases is restored and

　　all archivelog gaps have been resolved.

　　*** 2009-11-17 20:38:34.160

　　kcrrtsync: Standby mount ID 零xc896b692 not found

　　*** 2009-11-17 20:38:34.160 2342 krsl.c

　　No standby database destinations have been configured

　　as being archived by the LGWR process

　　This instance will operate at a reduced protection mode until

　　network connectivity to the standby databases is restored and

　　all archivelog gaps have been resolved.

　　*** 2009-11-17 20:40:02.286

　　kcrrtsync: Standby mount ID 零xc896b692 not found

　　Oracle透过数据库的Mount ID来查寻目标范例，备库封闭Mount ID不存在，则错处出现。

　　从新初始化加你LNS过程的进程如次：

　　*** 2009-11-17 20:40:02.286 56939 kcrr.c

　　Initializing NetServer[LNSb] for dest=STANDBY mode SYNC

　　LNSb is not running anymore.

　　New SYNC LNSb needs to be started

　　Waiting for subscriber count on LGWR-LNSb channel to go to zero

　　Subscriber count went to zero - time now is <11/17/2009 20:40:02>

　　Starting LNSb ...

　　Waiting for LNSb to initialize itself

　　*** 2009-11-17 20:40:05.330 57230 kcrr.c

　　Netserver LNSb [pid 573716] for mode SYNC has been initialized

　　Performing a channel reset to ignore previous responses

　　Successfully started LNSb [pid 573716] for dest STANDBY mode SYNC ocis=零x1104db358

　　*** 2009-11-17 20:40:05.330 57733 kcrr.c

　　Making upiahm request to LNSb [pid 573716]: Begin Time is <11/17/2009 20:40:02>. NET_TIMEOUT = <180> seconds

　　Waiting for LNSb to respond to upiahm

　　*** 2009-11-17 20:40:05.413 57897 kcrr.c

　　upiahm connect done status is 零

　　Receiving message from LNSb

　　Receiving message from LNSb

　　Receiving message from LNSb

　　*** 2009-11-17 20:40:05.609 59112 kcrr.c

　　Making upinbls request to LNSb (ocis 零x1104db358). Begin time is <11/17/2009 20:40:02> and NET_TIMEOUT is <180> seconds

　　NetServer pid:573716

　　明晰的懂得这个进程是很好玩儿的，记要一下子。

本文来源：
我的异常网
Java Exception
Dotnet Exception
Oracle Exception