Oracle主库归档丢失，备库日志有gap，在不重建备库的情况下，恢复备库
本文主要描述Oracle备库日志与主库日志之间有gap，切主库这部分gap的归档日志已经删除或丢失，如何在不重建备库的情况下，恢复备库。
欢迎转载，请注明作者、出处。
作者：张正
blog：http://space.itpub.net/26355921
QQ：176036317
如有疑问，欢迎联系。
在dataguard环境中，由于主库archivelog丢失，且尚未同步到standby，问如何在避免
重建standby的情况下来将standby恢复成功的。 下面是我的测试过程，供参考！
—-主库
SQL> SELECT database_role FROM v$database;
DATABASE_ROLE
----------------
PRIMARY
SQL> archive log list;
DATABASE log mode Archive Mode
Automatic archival Enabled
Archive destination /arch
Oldest online log SEQUENCE 382
NEXT log SEQUENCE TO archive 383
CURRENT log SEQUENCE 383
SQL> SELECT COUNT(1) FROM roger.test;
COUNT(1)
----------
30
—-备库
SQL> SELECT database_role FROM v$database;
DATABASE_ROLE
----------------
PHYSICAL STANDBY
SQL> archive log list;
DATABASE log mode Archive Mode
Automatic archival Enabled
Archive destination /arch2
Oldest online log SEQUENCE 382
NEXT log SEQUENCE TO archive 0
CURRENT log SEQUENCE 383
SQL>
SQL> ALTER DATABASE recover managed standby DATABASE cancel;
DATABASE altered.
SQL> ALTER DATABASE OPEN READ ONLY;
DATABASE altered.
SQL> SELECT COUNT(1) FROM roger.test;
COUNT(1)
----------
30
模拟主库丢失归档的情况：
—主库
SQL> SELECT * FROM v$Log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ------------
1 1 383 10485760 1 NO CURRENT 740638 10-OCT-12
2 1 382 20971520 1 YES INACTIVE 740633 10-OCT-12
SQL> archive log list;
DATABASE log mode Archive Mode
Automatic archival Enabled
Archive destination /arch
Oldest online log SEQUENCE 382
NEXT log SEQUENCE TO archive 383
CURRENT log SEQUENCE 383
SQL> ALTER system SET log_archive_dest_state_2 = 'defer';
System altered.
SQL> DELETE FROM roger.test WHERE rownum < 11;
10 ROWS deleted.
SQL> commit;
Commit complete.
SQL> SELECT COUNT(*) FROM roger.test;
COUNT(*)
----------
20
SQL> ALTER system switch logfile;
System altered.
SQL> /
System altered.
SQL> /
System altered.
SQL> !
[oracle@primarydb ~]$ cd /arch
[oracle@primarydb arch]$ ls -ltr|tail -10
-rw-r----- 1 oracle dba 3456000 Oct 10 15:18 1_374_726529113.dbf
-rw-r----- 1 oracle dba 593408 Oct 10 15:23 1_375_726529113.dbf
-rw-r----- 1 oracle dba 4608 Oct 10 15:23 1_376_726529113.dbf
-rw-r----- 1 oracle dba 1024 Oct 10 15:23 1_377_726529113.dbf
-rw-r----- 1 oracle dba 68096 Oct 10 15:25 1_378_726529113.dbf
-rw-r----- 1 oracle dba 1297408 Oct 10 15:34 1_379_726529113.dbf
-rw-r----- 1 oracle dba 2048 Oct 10 18:35 1_382_726529113.dbf
-rw-r----- 1 oracle dba 166400 Oct 10 18:44 1_383_726529113.dbf
-rw-r----- 1 oracle dba 2560 Oct 10 18:44 1_384_726529113.dbf
-rw-r----- 1 oracle dba 1024 Oct 10 18:44 1_385_726529113.dbf
[oracle@primarydb arch]$ rm 1_383_726529113.dbf ---删除archivelog
[oracle@primarydb arch]$ rm 1_384_726529113.dbf
[oracle@primarydb arch]$ exit
exit
SQL> ALTER system SET log_archive_dest_state_2 = 'enable';
System altered.
SQL>
—备库
SQL> ALTER DATABASE recover managed standby DATABASE disconnect FROM SESSION;
DATABASE altered.
SQL>
此时alert log信息如下：
Tue Nov 13 14:45:26 2012
MRP0: Background Managed Standby Recovery process started (test)
Managed Standby Recovery NOT USING REAL TIME Apply
parallel recovery started WITH 2 processes
Tue Nov 13 14:45:31 2012
Waiting FOR ALL non-CURRENT ORLs TO be archived...
Media Recovery Waiting FOR thread 1 SEQUENCE 383
Tue Nov 13 14:45:32 2012
Completed: ALTER DATABASE recover managed standby DATABASE disconnect FROM SESSION
Tue Nov 13 14:45:59 2012
Redo Shipping Client Connected AS PUBLIC
-- Connected User is Valid
RFS[2]: Assigned TO RFS process 9542
RFS[2]: IDENTIFIED DATABASE TYPE AS 'physical standby'
RFS[2]: Archived Log: '/arch2/1_385_726529113.dbf'
Tue Nov 13 14:46:02 2012
Fetching gap SEQUENCE IN thread 1, gap SEQUENCE 383-384
Tue Nov 13 14:47:02 2012
FAL[client]: Failed TO request gap SEQUENCE
GAP - thread 1 SEQUENCE 383-384
DBID 2024668720 branch 726529113
FAL[client]: ALL defined FAL servers have been attempted.
-------------------------------------------------------------
CHECK that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter IS defined TO a VALUE that IS sufficiently LARGE
enough TO maintain adequate log switch information TO resolve
archivelog gaps.
如何在重建standby的情况下搞好备库呢？mos上,其实也有文章进行描述的,就是利用rman进行增量scn的恢复,下面我来进行展示：
1)首先定位到scn
SQL> SELECT SEQUENCE#,FIRST_CHANGE#,NEXT_CHANGE# FROM v$archived_log WHERE SEQUENCE# > 382 ORDER BY 1;
SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ------------- ------------
383 740638 740911
384 740911 740915
385 740915 740917
385 740915 740917
2)根据scn，进行rman增量备份
[oracle@primarydb ~]$ cd $ORACLE_HOME/bin
[oracle@primarydb bin]$ ./rman target /
Recovery Manager: Release 10.2.0.4.0 - Production on Wed Oct 10 18:51:57 2012
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database: TEST (DBID=2024668720)
RMAN> backup device type disk incremental from scn 740638 database format '/tmp/test_db_incre.bbk';
Starting backup at 10-OCT-12
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=147 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00004 name=/oracle/product/oradata/test/test01.dbf
input datafile fno=00007 name=/oracle/product/oradata/test/sysaux01.dbf
input datafile fno=00009 name=/oracle/product/oradata/test/test03.dbf
input datafile fno=00006 name=/oracle/product/oradata/test/undo02.dbf
input datafile fno=00001 name=/oracle/product/oradata/test/system01.dbf
input datafile fno=00005 name=/oracle/product/oradata/test/perfstat.dbf
input datafile fno=00003 name=/oracle/product/oradata/test/rman.dbf
input datafile fno=00002 name=/oracle/product/oradata/test/undo01.dbf
input datafile fno=00008 name=/oracle/product/oradata/test/test02.dbf
input datafile fno=00010 name=/oracle/product/oradata/test/test04.dbf
input datafile fno=00011 name=/oracle/product/oradata/test/test05.dbf
channel ORA_DISK_1: starting piece 1 at 10-OCT-12
channel ORA_DISK_1: finished piece 1 at 10-OCT-12
piece handle=/tmp/test_db_incre.bbk tag=TAG20121010T185204 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:03:26
Finished backup at 10-OCT-12
RMAN>
3) 拷贝增量备份到standby
[oracle@primarydb bin]$ cd /tmp
[oracle@primarydb tmp]$ scp test_db_incre.bbk 192.168.3.176:/tmp/backup
The authenticity of host '192.168.3.176 (192.168.3.176)' can't be established.
RSA key fingerprint is a4:54:6b:bf:12:34:42:73:f5:ba:5f:38:c7:28:9c:b5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.3.176' (RSA) to the list of known hosts.
oracle@192.168.3.176's password:
test_db_incre.bbk 100% 736KB 736.0KB/s 00:00
[oracle@primarydb tmp]$
4) standby进行recover
[oracle@standbydb bin]$ sqlplus "/as sysdba"
SQL*Plus: Release 10.2.0.4.0 - Production ON Tue Nov 13 15:03:46 2012
Copyright (c) 1982, 2007, Oracle. ALL Rights Reserved.
Connected TO:
Oracle DATABASE 10g Enterprise Edition Release 10.2.0.4.0 - Production
WITH the Partitioning, OLAP, DATA Mining AND REAL Application Testing options
SQL> ALTER DATABASE recover managed standby DATABASE cancel;
DATABASE altered.
SQL> exit
Disconnected FROM Oracle DATABASE 10g Enterprise Edition Release 10.2.0.4.0 - Production
WITH the Partitioning, OLAP, DATA Mining AND REAL Application Testing options
[oracle@standbydb ~]$ cd $ORACLE_HOME/bin
[oracle@standbydb bin]$ ./rman target /
Recovery Manager: Release 10.2.0.4.0 - Production ON Tue Nov 13 14:58:25 2012
Copyright (c) 1982, 2007, Oracle. ALL rights reserved.
connected TO target DATABASE: TEST (DBID=2024668720, NOT OPEN)
RMAN> catalog backuppiece '/tmp/backup/test_db_incre.bbk';
USING target DATABASE control file instead OF recovery catalog
cataloged backuppiece
backup piece handle=/tmp/backup/test_db_incre.bbk recid=49 stamp=799253957
RMAN> recover DATABASE noredo;
Starting recover at 13-NOV-12
USING target DATABASE control file instead OF recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=97 devtype=DISK
channel ORA_DISK_1: starting incremental datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) TO restore FROM backup SET
destination FOR restore OF datafile 00001: /oracle/product/oradata/test/system01.dbf
destination FOR restore OF datafile 00002: /oracle/product/oradata/test/undo01.dbf
destination FOR restore OF datafile 00003: /oracle/product/oradata/test/rman.dbf
destination FOR restore OF datafile 00004: /oracle/product/oradata/test/test01.dbf
destination FOR restore OF datafile 00005: /oracle/product/oradata/test/perfstat.dbf
destination FOR restore OF datafile 00006: /oracle/product/oradata/test/undo02.dbf
destination FOR restore OF datafile 00007: /oracle/product/oradata/test/sysaux01.dbf
destination FOR restore OF datafile 00008: /oracle/product/oradata/test/test02.dbf
destination FOR restore OF datafile 00009: /oracle/product/oradata/test/test03.dbf
destination FOR restore OF datafile 00010: /oracle/product/oradata/test/test04.dbf
destination FOR restore OF datafile 00011: /oracle/product/oradata/test/test05.dbf
channel ORA_DISK_1: reading FROM backup piece /tmp/backup/test_db_incre.bbk
channel ORA_DISK_1: restored backup piece 1
piece handle=/tmp/backup/test_db_incre.bbk tag=TAG20121010T185204
channel ORA_DISK_1: restore complete, elapsed TIME: 00:00:01
Finished recover at 13-NOV-12
RMAN>
如下信息是recover时，alert log的记录信息：
Tue Nov 13 15:04:05 2012
Completed: ALTER DATABASE recover managed standby DATABASE cancel
Tue Nov 13 15:04:55 2012
Incremental restore complete OF datafile 2 /oracle/product/oradata/test/undo01.dbf
checkpoint IS 741134
Incremental restore complete OF datafile 8 /oracle/product/oradata/test/test02.dbf
checkpoint IS 741134
Incremental restore complete OF datafile 10 /oracle/product/oradata/test/test04.dbf
checkpoint IS 741134
Incremental restore complete OF datafile 11 /oracle/product/oradata/test/test05.dbf
checkpoint IS 741134
Incremental restore complete OF datafile 3 /oracle/product/oradata/test/rman.dbf
checkpoint IS 741134
Incremental restore complete OF datafile 5 /oracle/product/oradata/test/perfstat.dbf
checkpoint IS 741134
Incremental restore complete OF datafile 1 /oracle/product/oradata/test/system01.dbf
checkpoint IS 741134
Incremental restore complete OF datafile 6 /oracle/product/oradata/test/undo02.dbf
checkpoint IS 741134
Incremental restore complete OF datafile 4 /oracle/product/oradata/test/test01.dbf
checkpoint IS 741134
Incremental restore complete OF datafile 7 /oracle/product/oradata/test/sysaux01.dbf
checkpoint IS 741134
Incremental restore complete OF datafile 9 /oracle/product/oradata/test/test03.dbf
checkpoint IS 741134
5) 开启standby同步，检查是否ok。
SQL> ALTER DATABASE recover managed standby DATABASE disconnect FROM SESSION;
DATABASE altered.
SQL> SELECT database_role,open_mode FROM v$database;
DATABASE_ROLE OPEN_MODE
---------------- ----------
PHYSICAL STANDBY MOUNTED
--主库切换日志
SQL> SELECT database_role,open_mode FROM v$database;
DATABASE_ROLE OPEN_MODE
---------------- ----------
PRIMARY READ WRITE
SQL>
SQL> ALTER system switch logfile;
System altered.
SQL> SELECT MAX(al.SEQUENCE#) "Last Seq Recieved",
2 MAX(lh.SEQUENCE#) "Last Seq Applied"
3 FROM v$archived_log al, v$log_history lh;
LAST Seq Recieved LAST Seq Applied
----------------- ----------------
386 386
SQL>
--备库
SQL> SELECT MAX(al.SEQUENCE#) "Last Seq Recieved",
2 MAX(lh.SEQUENCE#) "Last Seq Applied"
3 FROM v$archived_log al, v$log_history lh;
LAST Seq Recieved LAST Seq Applied
----------------- ----------------
386 382
SQL>
SQL> SELECT * FROM v$archive_gap;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
---------- ------------- --------------
1 383 384
备库archivelog：
[oracle@standbydb arch2]$ ls -ltr |tail -5
-rw-r----- 1 oracle dba 2048 Nov 13 14:33 1_381_726529113.dbf
-rw-r----- 1 oracle dba 2048 Nov 13 14:34 1_382_726529113.dbf
-rw-r----- 1 oracle dba 1024 Nov 13 14:45 1_385_726529113.dbf
-rw-r----- 1 oracle dba 1262080 Nov 13 15:06 1_386_726529113.dbf
备库alert log此时的信息：
Tue Nov 13 15:06:17 2012
ALTER DATABASE recover managed standby DATABASE disconnect FROM SESSION
Tue Nov 13 15:06:17 2012
Attempt TO START background Managed Standby Recovery process (test)
MRP0 started WITH pid=19, OS id=13497
Tue Nov 13 15:06:17 2012
MRP0: Background Managed Standby Recovery process started (test)
Managed Standby Recovery NOT USING REAL TIME Apply
parallel recovery started WITH 2 processes
Tue Nov 13 15:06:22 2012
Waiting FOR ALL non-CURRENT ORLs TO be archived...
Media Recovery Waiting FOR thread 1 SEQUENCE 383
Fetching gap SEQUENCE IN thread 1, gap SEQUENCE 383-384
Tue Nov 13 15:06:23 2012
Completed: ALTER DATABASE recover managed standby DATABASE disconnect FROM SESSION
Tue Nov 13 15:06:54 2012
Redo Shipping Client Connected AS PUBLIC
-- Connected User is Valid
RFS[3]: Assigned TO RFS process 13596
RFS[3]: IDENTIFIED DATABASE TYPE AS 'physical standby'
PRIMARY DATABASE IS IN MAXIMUM PERFORMANCE mode
PRIMARY DATABASE IS IN MAXIMUM PERFORMANCE mode
RFS[3]: Successfully opened standby log 4: '/oracle/product/oradata/test/redo04.log'
Tue Nov 13 15:06:54 2012
RFS[2]: Successfully opened standby log 3: '/oracle/product/oradata/test/redo03.log'
Tue Nov 13 15:07:23 2012
FAL[client]: Failed TO request gap SEQUENCE
GAP - thread 1 SEQUENCE 383-384
DBID 2024668720 branch 726529113
FAL[client]: ALL defined FAL servers have been attempted.
-------------------------------------------------------------
CHECK that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter IS defined TO a VALUE that IS sufficiently LARGE
enough TO maintain adequate log switch information TO resolve
archivelog gaps.
我们可以看到，虽然备库，仍然在提示383,384是gap ，但是实际上已经是同步的了。
6)最后来验证下数据
SQL> ALTER DATABASE recover managed standby DATABASE cancel;
DATABASE altered.
SQL> SELECT file#,checkpoint_change# FROM v$datafile ORDER BY 1;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 740638
2 740638
3 740638
4 740638
5 740638
6 740638
7 740638
8 740638
9 740638
10 740638
11 740638
11 ROWS selected.
SQL> SELECT file#,checkpoint_change# FROM v$datafile_header ORDER BY 1;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 741134
2 741134
3 741134
4 741134
5 741134
6 741134
7 741134
8 741134
9 741134
10 741134
11 741134
11 ROWS selected.
SQL> ALTER DATABASE OPEN READ ONLY;
ALTER DATABASE OPEN READ ONLY
*
ERROR at line 1:
ORA-16004: backup DATABASE requires recovery
ORA-01152: file 1 was NOT restored FROM a sufficiently OLD backup
ORA-01110: DATA file 1: '/oracle/product/oradata/test/system01.dbf'
重建备库的standby controlfile：
SQL> ALTER DATABASE CREATE standby controlfile AS '/tmp/standby.ctl';
DATABASE altered.
SQL> exit
Disconnected FROM Oracle DATABASE 10g Enterprise Edition Release 10.2.0.4.0 - Production
WITH the Partitioning, OLAP, DATA Mining AND REAL Application Testing options
[oracle@primarydb tmp]$ scp standby.ctl 192.168.3.176:/tmp/backup
oracle@192.168.3.176's password:
standby.ctl 100% 3928KB 3.8MB/s 00:00
[oracle@primarydb tmp]$
[oracle@standbydb bin]$ ./rman target /
Recovery Manager: Release 10.2.0.4.0 - Production on Tue Nov 13 15:19:09 2012
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database (not started)
RMAN> startup nomount
Oracle instance started
Total System Global Area 264241152 bytes
Fixed Size 1266944 bytes
Variable Size 209718016 bytes
Database Buffers 50331648 bytes
Redo Buffers 2924544 bytes
RMAN> restore controlfile from '/tmp/backup/standby.ctl';
Starting restore at 13-NOV-12
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=101 devtype=DISK
channel ORA_DISK_1: copied control file copy
output filename=/oracle/product/oradata/test/control01.ctl
Finished restore at 13-NOV-12
RMAN> startup mount
database is already started
database mounted
released channel: ORA_DISK_1
RMAN> exit
Recovery Manager complete.
[oracle@standbydb bin]$ sqlplus "/as sysdba"
SQL*Plus: Release 10.2.0.4.0 - Production on Tue Nov 13 15:20:02 2012
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> alter database recover managed standby database disconnect from session;
Database altered.
SQL> alter database recover managed standby database cancel;
Database altered.
SQL>
SQL>
SQL> alter database open read only;
Database altered.
SQL> select count(1) from roger.test;
COUNT(1)
----------
20
SQL>
最后，我们可以看到，在主库archivelog丢失无法同步到备库时，可以利用增量scn的方式，来避免重建standby。
重建standby的情况下来将standby恢复成功的。 下面是我的测试过程，供参考！
—-主库
SQL> SELECT database_role FROM v$database;
DATABASE_ROLE
----------------
PRIMARY
SQL> archive log list;
DATABASE log mode Archive Mode
Automatic archival Enabled
Archive destination /arch
Oldest online log SEQUENCE 382
NEXT log SEQUENCE TO archive 383
CURRENT log SEQUENCE 383
SQL> SELECT COUNT(1) FROM roger.test;
COUNT(1)
----------
30
—-备库
SQL> SELECT database_role FROM v$database;
DATABASE_ROLE
----------------
PHYSICAL STANDBY
SQL> archive log list;
DATABASE log mode Archive Mode
Automatic archival Enabled
Archive destination /arch2
Oldest online log SEQUENCE 382
NEXT log SEQUENCE TO archive 0
CURRENT log SEQUENCE 383
SQL>
SQL> ALTER DATABASE recover managed standby DATABASE cancel;
DATABASE altered.
SQL> ALTER DATABASE OPEN READ ONLY;
DATABASE altered.
SQL> SELECT COUNT(1) FROM roger.test;
COUNT(1)
----------
30
模拟主库丢失归档的情况：
—主库
SQL> SELECT * FROM v$Log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ------------
1 1 383 10485760 1 NO CURRENT 740638 10-OCT-12
2 1 382 20971520 1 YES INACTIVE 740633 10-OCT-12
SQL> archive log list;
DATABASE log mode Archive Mode
Automatic archival Enabled
Archive destination /arch
Oldest online log SEQUENCE 382
NEXT log SEQUENCE TO archive 383
CURRENT log SEQUENCE 383
SQL> ALTER system SET log_archive_dest_state_2 = 'defer';
System altered.
SQL> DELETE FROM roger.test WHERE rownum < 11;
10 ROWS deleted.
SQL> commit;
Commit complete.
SQL> SELECT COUNT(*) FROM roger.test;
COUNT(*)
----------
20
SQL> ALTER system switch logfile;
System altered.
SQL> /
System altered.
SQL> /
System altered.
SQL> !
[oracle@primarydb ~]$ cd /arch
[oracle@primarydb arch]$ ls -ltr|tail -10
-rw-r----- 1 oracle dba 3456000 Oct 10 15:18 1_374_726529113.dbf
-rw-r----- 1 oracle dba 593408 Oct 10 15:23 1_375_726529113.dbf
-rw-r----- 1 oracle dba 4608 Oct 10 15:23 1_376_726529113.dbf
-rw-r----- 1 oracle dba 1024 Oct 10 15:23 1_377_726529113.dbf
-rw-r----- 1 oracle dba 68096 Oct 10 15:25 1_378_726529113.dbf
-rw-r----- 1 oracle dba 1297408 Oct 10 15:34 1_379_726529113.dbf
-rw-r----- 1 oracle dba 2048 Oct 10 18:35 1_382_726529113.dbf
-rw-r----- 1 oracle dba 166400 Oct 10 18:44 1_383_726529113.dbf
-rw-r----- 1 oracle dba 2560 Oct 10 18:44 1_384_726529113.dbf
-rw-r----- 1 oracle dba 1024 Oct 10 18:44 1_385_726529113.dbf
[oracle@primarydb arch]$ rm 1_383_726529113.dbf ---删除archivelog
[oracle@primarydb arch]$ rm 1_384_726529113.dbf
[oracle@primarydb arch]$ exit
exit
SQL> ALTER system SET log_archive_dest_state_2 = 'enable';
System altered.
SQL>
—备库
SQL> ALTER DATABASE recover managed standby DATABASE disconnect FROM SESSION;
DATABASE altered.
SQL>
此时alert log信息如下：
Tue Nov 13 14:45:26 2012
MRP0: Background Managed Standby Recovery process started (test)
Managed Standby Recovery NOT USING REAL TIME Apply
parallel recovery started WITH 2 processes
Tue Nov 13 14:45:31 2012
Waiting FOR ALL non-CURRENT ORLs TO be archived...
Media Recovery Waiting FOR thread 1 SEQUENCE 383
Tue Nov 13 14:45:32 2012
Completed: ALTER DATABASE recover managed standby DATABASE disconnect FROM SESSION
Tue Nov 13 14:45:59 2012
Redo Shipping Client Connected AS PUBLIC
-- Connected User is Valid
RFS[2]: Assigned TO RFS process 9542
RFS[2]: IDENTIFIED DATABASE TYPE AS 'physical standby'
RFS[2]: Archived Log: '/arch2/1_385_726529113.dbf'
Tue Nov 13 14:46:02 2012
Fetching gap SEQUENCE IN thread 1, gap SEQUENCE 383-384
Tue Nov 13 14:47:02 2012
FAL[client]: Failed TO request gap SEQUENCE
GAP - thread 1 SEQUENCE 383-384
DBID 2024668720 branch 726529113
FAL[client]: ALL defined FAL servers have been attempted.
-------------------------------------------------------------
CHECK that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter IS defined TO a VALUE that IS sufficiently LARGE
enough TO maintain adequate log switch information TO resolve
archivelog gaps.
如何在重建standby的情况下搞好备库呢？mos上,其实也有文章进行描述的,就是利用rman进行增量scn的恢复,下面我来进行展示：
1)首先定位到scn
SQL> SELECT SEQUENCE#,FIRST_CHANGE#,NEXT_CHANGE# FROM v$archived_log WHERE SEQUENCE# > 382 ORDER BY 1;
SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ------------- ------------
383 740638 740911
384 740911 740915
385 740915 740917
385 740915 740917
2)根据scn，进行rman增量备份
[oracle@primarydb ~]$ cd $ORACLE_HOME/bin
[oracle@primarydb bin]$ ./rman target /
Recovery Manager: Release 10.2.0.4.0 - Production on Wed Oct 10 18:51:57 2012
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database: TEST (DBID=2024668720)
RMAN> backup device type disk incremental from scn 740638 database format '/tmp/test_db_incre.bbk';
Starting backup at 10-OCT-12
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=147 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00004 name=/oracle/product/oradata/test/test01.dbf
input datafile fno=00007 name=/oracle/product/oradata/test/sysaux01.dbf
input datafile fno=00009 name=/oracle/product/oradata/test/test03.dbf
input datafile fno=00006 name=/oracle/product/oradata/test/undo02.dbf
input datafile fno=00001 name=/oracle/product/oradata/test/system01.dbf
input datafile fno=00005 name=/oracle/product/oradata/test/perfstat.dbf
input datafile fno=00003 name=/oracle/product/oradata/test/rman.dbf
input datafile fno=00002 name=/oracle/product/oradata/test/undo01.dbf
input datafile fno=00008 name=/oracle/product/oradata/test/test02.dbf
input datafile fno=00010 name=/oracle/product/oradata/test/test04.dbf
input datafile fno=00011 name=/oracle/product/oradata/test/test05.dbf
channel ORA_DISK_1: starting piece 1 at 10-OCT-12
channel ORA_DISK_1: finished piece 1 at 10-OCT-12
piece handle=/tmp/test_db_incre.bbk tag=TAG20121010T185204 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:03:26
Finished backup at 10-OCT-12
RMAN>
3) 拷贝增量备份到standby
[oracle@primarydb bin]$ cd /tmp
[oracle@primarydb tmp]$ scp test_db_incre.bbk 192.168.3.176:/tmp/backup
The authenticity of host '192.168.3.176 (192.168.3.176)' can't be established.
RSA key fingerprint is a4:54:6b:bf:12:34:42:73:f5:ba:5f:38:c7:28:9c:b5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.3.176' (RSA) to the list of known hosts.
oracle@192.168.3.176's password:
test_db_incre.bbk 100% 736KB 736.0KB/s 00:00
[oracle@primarydb tmp]$
4) standby进行recover
[oracle@standbydb bin]$ sqlplus "/as sysdba"
SQL*Plus: Release 10.2.0.4.0 - Production ON Tue Nov 13 15:03:46 2012
Copyright (c) 1982, 2007, Oracle. ALL Rights Reserved.
Connected TO:
Oracle DATABASE 10g Enterprise Edition Release 10.2.0.4.0 - Production
WITH the Partitioning, OLAP, DATA Mining AND REAL Application Testing options
SQL> ALTER DATABASE recover managed standby DATABASE cancel;
DATABASE altered.
SQL> exit
Disconnected FROM Oracle DATABASE 10g Enterprise Edition Release 10.2.0.4.0 - Production
WITH the Partitioning, OLAP, DATA Mining AND REAL Application Testing options
[oracle@standbydb ~]$ cd $ORACLE_HOME/bin
[oracle@standbydb bin]$ ./rman target /
Recovery Manager: Release 10.2.0.4.0 - Production ON Tue Nov 13 14:58:25 2012
Copyright (c) 1982, 2007, Oracle. ALL rights reserved.
connected TO target DATABASE: TEST (DBID=2024668720, NOT OPEN)
RMAN> catalog backuppiece '/tmp/backup/test_db_incre.bbk';
USING target DATABASE control file instead OF recovery catalog
cataloged backuppiece
backup piece handle=/tmp/backup/test_db_incre.bbk recid=49 stamp=799253957
RMAN> recover DATABASE noredo;
Starting recover at 13-NOV-12
USING target DATABASE control file instead OF recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=97 devtype=DISK
channel ORA_DISK_1: starting incremental datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) TO restore FROM backup SET
destination FOR restore OF datafile 00001: /oracle/product/oradata/test/system01.dbf
destination FOR restore OF datafile 00002: /oracle/product/oradata/test/undo01.dbf
destination FOR restore OF datafile 00003: /oracle/product/oradata/test/rman.dbf
destination FOR restore OF datafile 00004: /oracle/product/oradata/test/test01.dbf
destination FOR restore OF datafile 00005: /oracle/product/oradata/test/perfstat.dbf
destination FOR restore OF datafile 00006: /oracle/product/oradata/test/undo02.dbf
destination FOR restore OF datafile 00007: /oracle/product/oradata/test/sysaux01.dbf
destination FOR restore OF datafile 00008: /oracle/product/oradata/test/test02.dbf
destination FOR restore OF datafile 00009: /oracle/product/oradata/test/test03.dbf
destination FOR restore OF datafile 00010: /oracle/product/oradata/test/test04.dbf
destination FOR restore OF datafile 00011: /oracle/product/oradata/test/test05.dbf
channel ORA_DISK_1: reading FROM backup piece /tmp/backup/test_db_incre.bbk
channel ORA_DISK_1: restored backup piece 1
piece handle=/tmp/backup/test_db_incre.bbk tag=TAG20121010T185204
channel ORA_DISK_1: restore complete, elapsed TIME: 00:00:01
Finished recover at 13-NOV-12
RMAN>
如下信息是recover时，alert log的记录信息：
Tue Nov 13 15:04:05 2012
Completed: ALTER DATABASE recover managed standby DATABASE cancel
Tue Nov 13 15:04:55 2012
Incremental restore complete OF datafile 2 /oracle/product/oradata/test/undo01.dbf
checkpoint IS 741134
Incremental restore complete OF datafile 8 /oracle/product/oradata/test/test02.dbf
checkpoint IS 741134
Incremental restore complete OF datafile 10 /oracle/product/oradata/test/test04.dbf
checkpoint IS 741134
Incremental restore complete OF datafile 11 /oracle/product/oradata/test/test05.dbf
checkpoint IS 741134
Incremental restore complete OF datafile 3 /oracle/product/oradata/test/rman.dbf
checkpoint IS 741134
Incremental restore complete OF datafile 5 /oracle/product/oradata/test/perfstat.dbf
checkpoint IS 741134
Incremental restore complete OF datafile 1 /oracle/product/oradata/test/system01.dbf
checkpoint IS 741134
Incremental restore complete OF datafile 6 /oracle/product/oradata/test/undo02.dbf
checkpoint IS 741134
Incremental restore complete OF datafile 4 /oracle/product/oradata/test/test01.dbf
checkpoint IS 741134
Incremental restore complete OF datafile 7 /oracle/product/oradata/test/sysaux01.dbf
checkpoint IS 741134
Incremental restore complete OF datafile 9 /oracle/product/oradata/test/test03.dbf
checkpoint IS 741134
5) 开启standby同步，检查是否ok。
SQL> ALTER DATABASE recover managed standby DATABASE disconnect FROM SESSION;
DATABASE altered.
SQL> SELECT database_role,open_mode FROM v$database;
DATABASE_ROLE OPEN_MODE
---------------- ----------
PHYSICAL STANDBY MOUNTED
--主库切换日志
SQL> SELECT database_role,open_mode FROM v$database;
DATABASE_ROLE OPEN_MODE
---------------- ----------
PRIMARY READ WRITE
SQL>
SQL> ALTER system switch logfile;
System altered.
SQL> SELECT MAX(al.SEQUENCE#) "Last Seq Recieved",
2 MAX(lh.SEQUENCE#) "Last Seq Applied"
3 FROM v$archived_log al, v$log_history lh;
LAST Seq Recieved LAST Seq Applied
----------------- ----------------
386 386
SQL>
--备库
SQL> SELECT MAX(al.SEQUENCE#) "Last Seq Recieved",
2 MAX(lh.SEQUENCE#) "Last Seq Applied"
3 FROM v$archived_log al, v$log_history lh;
LAST Seq Recieved LAST Seq Applied
----------------- ----------------
386 382
SQL>
SQL> SELECT * FROM v$archive_gap;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
---------- ------------- --------------
1 383 384
备库archivelog：
[oracle@standbydb arch2]$ ls -ltr |tail -5
-rw-r----- 1 oracle dba 2048 Nov 13 14:33 1_381_726529113.dbf
-rw-r----- 1 oracle dba 2048 Nov 13 14:34 1_382_726529113.dbf
-rw-r----- 1 oracle dba 1024 Nov 13 14:45 1_385_726529113.dbf
-rw-r----- 1 oracle dba 1262080 Nov 13 15:06 1_386_726529113.dbf
备库alert log此时的信息：
Tue Nov 13 15:06:17 2012
ALTER DATABASE recover managed standby DATABASE disconnect FROM SESSION
Tue Nov 13 15:06:17 2012
Attempt TO START background Managed Standby Recovery process (test)
MRP0 started WITH pid=19, OS id=13497
Tue Nov 13 15:06:17 2012
MRP0: Background Managed Standby Recovery process started (test)
Managed Standby Recovery NOT USING REAL TIME Apply
parallel recovery started WITH 2 processes
Tue Nov 13 15:06:22 2012
Waiting FOR ALL non-CURRENT ORLs TO be archived...
Media Recovery Waiting FOR thread 1 SEQUENCE 383
Fetching gap SEQUENCE IN thread 1, gap SEQUENCE 383-384
Tue Nov 13 15:06:23 2012
Completed: ALTER DATABASE recover managed standby DATABASE disconnect FROM SESSION
Tue Nov 13 15:06:54 2012
Redo Shipping Client Connected AS PUBLIC
-- Connected User is Valid
RFS[3]: Assigned TO RFS process 13596
RFS[3]: IDENTIFIED DATABASE TYPE AS 'physical standby'
PRIMARY DATABASE IS IN MAXIMUM PERFORMANCE mode
PRIMARY DATABASE IS IN MAXIMUM PERFORMANCE mode
RFS[3]: Successfully opened standby log 4: '/oracle/product/oradata/test/redo04.log'
Tue Nov 13 15:06:54 2012
RFS[2]: Successfully opened standby log 3: '/oracle/product/oradata/test/redo03.log'
Tue Nov 13 15:07:23 2012
FAL[client]: Failed TO request gap SEQUENCE
GAP - thread 1 SEQUENCE 383-384
DBID 2024668720 branch 726529113
FAL[client]: ALL defined FAL servers have been attempted.
-------------------------------------------------------------
CHECK that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter IS defined TO a VALUE that IS sufficiently LARGE
enough TO maintain adequate log switch information TO resolve
archivelog gaps.
我们可以看到，虽然备库，仍然在提示383,384是gap ，但是实际上已经是同步的了。
6)最后来验证下数据
SQL> ALTER DATABASE recover managed standby DATABASE cancel;
DATABASE altered.
SQL> SELECT file#,checkpoint_change# FROM v$datafile ORDER BY 1;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 740638
2 740638
3 740638
4 740638
5 740638
6 740638
7 740638
8 740638
9 740638
10 740638
11 740638
11 ROWS selected.
SQL> SELECT file#,checkpoint_change# FROM v$datafile_header ORDER BY 1;
FILE# CHECKPOINT_CHANGE#
---------- ------------------
1 741134
2 741134
3 741134
4 741134
5 741134
6 741134
7 741134
8 741134
9 741134
10 741134
11 741134
11 ROWS selected.
SQL> ALTER DATABASE OPEN READ ONLY;
ALTER DATABASE OPEN READ ONLY
*
ERROR at line 1:
ORA-16004: backup DATABASE requires recovery
ORA-01152: file 1 was NOT restored FROM a sufficiently OLD backup
ORA-01110: DATA file 1: '/oracle/product/oradata/test/system01.dbf'
重建备库的standby controlfile：
SQL> ALTER DATABASE CREATE standby controlfile AS '/tmp/standby.ctl';
DATABASE altered.
SQL> exit
Disconnected FROM Oracle DATABASE 10g Enterprise Edition Release 10.2.0.4.0 - Production
WITH the Partitioning, OLAP, DATA Mining AND REAL Application Testing options
[oracle@primarydb tmp]$ scp standby.ctl 192.168.3.176:/tmp/backup
oracle@192.168.3.176's password:
standby.ctl 100% 3928KB 3.8MB/s 00:00
[oracle@primarydb tmp]$
[oracle@standbydb bin]$ ./rman target /
Recovery Manager: Release 10.2.0.4.0 - Production on Tue Nov 13 15:19:09 2012
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database (not started)
RMAN> startup nomount
Oracle instance started
Total System Global Area 264241152 bytes
Fixed Size 1266944 bytes
Variable Size 209718016 bytes
Database Buffers 50331648 bytes
Redo Buffers 2924544 bytes
RMAN> restore controlfile from '/tmp/backup/standby.ctl';
Starting restore at 13-NOV-12
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=101 devtype=DISK
channel ORA_DISK_1: copied control file copy
output filename=/oracle/product/oradata/test/control01.ctl
Finished restore at 13-NOV-12
RMAN> startup mount
database is already started
database mounted
released channel: ORA_DISK_1
RMAN> exit
Recovery Manager complete.
[oracle@standbydb bin]$ sqlplus "/as sysdba"
SQL*Plus: Release 10.2.0.4.0 - Production on Tue Nov 13 15:20:02 2012
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> alter database recover managed standby database disconnect from session;
Database altered.
SQL> alter database recover managed standby database cancel;
Database altered.
SQL>
SQL>
SQL> alter database open read only;
Database altered.
SQL> select count(1) from roger.test;
COUNT(1)
----------
20
SQL>
最后，我们可以看到，在主库archivelog丢失无法同步到备库时，可以利用增量scn的方式，来避免重建standby。
本文是参考Roger的博客：
http://www.killdb.com/index-of-article
http://www.killdb.com/index-of-article
阅读(8403) | 评论(0) | 转发(0) |
Oracle主库归档丢失，备库日志有gap，在不重建备库的情况下，恢复备库的更多相关文章
- MySQL5.7(5.6)GTID环境下恢复从库思(qi)路(yin)方(ji)法(qiao)
要讨论如何恢复从库,我们得先来了解如下一些概念: GTID_EXECUTED:它是一组包含已经记录在二进制日志文件中的事务集合 GTID_PURGED:它是一组包含已经从二进制日志删除掉的事务集合 ...
- MySQL5.7(5.6)GTID环境下恢复从库思路方法(转发）
要讨论如何恢复从库,我们得先来了解如下一些概念: GTID_EXECUTED:它是一组包含已经记录在二进制日志文件中的事务集合 GTID_PURGED:它是一组包含已经从二进制日志删除掉的事务集合. ...
- Oracle备份恢复之无备份情况下恢复undo表空间
UNDO表空间存储着DML操作数据块的前镜像数据,在数据回滚,一致性读,闪回操作,实例恢复的时候都可能用到UNDO表空间中的数据.如果在生产过程中丢失或破坏了UNDO表空间,可能导致某些事务无法回滚, ...
- 不重新编译PHP文件的情况下php GD库扩展库的编译安装(centos)
gd-2.0.33.tar.gz http://www.boutell.com/gd/ jpegsrc.v6b.tar.gz http://www.ijg.org/ libpng-1.2.7.tar. ...
- C++ 使用 opencv 库时 Point 在已经引入了 core.hpp 的情况下仍无法识别的可能原因
引入了 core.hpp 是不够的.请加上 using namespace cv;
- 在本地库不连接远远程库的情况下操作远程库-----sql server
--创建链接服务器 --前面都是固定不变的------q:自己随便起-----38.107.111.185:远程服务器的ip exec sp_addlinkedserver 'q', ' ', 'SQ ...
- DG备库无法接受主库归档日志之密码文件
DG备库无法接受主库归档日志之密码文件 实验目的:还原某个客户案例,客户审计需要,对主库sys用户进行锁定,一小时后对sys用户进行解锁后,发现备库无法接受主库的归档日志 本篇文章,测试sys用户与D ...
- 使用RMAN增量备份处理Dataguard因归档丢失造成的gap
场景: 备库执行日志应用出现如下报错: Thu Mar 29 11:21:45 2018FAL[client]: Failed to request gap sequence GAP - thread ...
- 【DATAGUARD】物理dg在主库丢失归档文件的情况下的恢复(七)
[DATAGUARD]物理dg在主库丢失归档文件的情况下的恢复(七) 一.1 BLOG文档结构图 一.2 前言部分 一.2.1 导读 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到 ...
随机推荐
- axis2 WebService的发布与调用
1:准备: JDK:http://www.oracle.com/technetwork/java/javase/downloads/jdk6downloads-1902814.html e ...
- Ubuntu下如何将普通用户提升到root权限
在ubuntu的系统操作中,我们经常会使用到系统权限的,因为权限不足,导致在一些操作当中非常麻烦.要获取权限,最长使用的方法就是使用sudo指令,但是来回使用还是比较麻烦,有没有直接提升我们的用户权限 ...
- LED_9261在linux2.6.30中tick_led的实现
在linux2.6.30内核中,内核也提供了相关的平台驱动来操作gpio或LED,但更简便的方法是直接操作GPIO来控制led. 网上一博文中介绍直接封装led_on和led_off()函数直接调用即 ...
- python_字典
1. 字典的定义 字典由多个键及其对应的值构成(我们也把键/值对称为项).键是唯一的,值不唯一.键可以是数字.字符串甚至是元组. 2. 字典的创建 (1) phonebook = {"} 名 ...
- [地图代数]处理DEM中的高程异常值——ArcGIS栅格计算的应用
接了一个任务,要处理DEM原始数据中的高程异常值,如图中的异常亮点. 想了一下,以前处理过建筑物附近的DEM铲平,那么高程异常值应该如何处理呢? 显然直接铲平时不太合理的,需要利用异常值周围的高程进行 ...
- SqlServer跨库查询
由于业务的拆分,数据库拆分为两种作用: 汇总数据库(Master,头节点数据库), 子节点数据库(Compute Node,计算子节点数据库) 这样,就设计到子节点访问头节点数据库中的某张汇总表,这种 ...
- J2EE MyBatis使用
MyBatis 本是apache的一个开源项目iBatis, 2010年这个项目由apache software foundation 迁移到了google code,并且改名为MyBatis .20 ...
- 使用Mac的AppleScritp调用控制台的方式
使用Mac的AppleScritp调用 控制台的方法 tell application "Terminal" activate do script "cd Documen ...
- firefox中 checkbox属性checked="checked"已有，但复选框却不显示打钩的原因
最近在调试复选框的应用,在ie没有问题,考虑到兼容性,试试了firefox,遇到了问题. 复选框绑定了click事件,点一次选中,再点击取消选中,依次类推.这个功能在ie中没问题,但是在firefox ...
- mysql水平拆分与垂直拆分的详细介绍(转载http://www.cnblogs.com/nixi8/p/4524082.html)
垂直 垂直拆分是指数据表列的拆分,把一张列比较多的表拆分为多张表 通常我们按以下原则进行垂直拆分: 把不常用的字段单独放在一张表; 把text,blob等大字段拆分出来放在附表中; 经常组合查询的 ...