ORACLE 11G通过SCN做增量备份修复standby库详细过程

背景描述：Oracle 的standby库后台alert报错，如下：

ORA-00354: corrupt redo log block header
ORA-00353: log corruption near block 10240change 11125950022 time 05/08/2015 22:00:41
ORA-00334: archived log:‘/data/oracle/oradgdata/standby_archive/1_32350_821708334.dbf‘
Recovery interrupted!
Wed May 13 13:26:08 2015
Trace dumping is performingid=[cdmp_20150513132608]
Wed May 13 13:26:08 2015
Sweep [inc][273026]: completed
Recovered data files to a consistent stateat change 11125946527
Errors in file/oracle/app/oracle/diag/rdbms/pddgunq/powerdes/trace/powerdes_pr00_21813.trc:
ORA-00354: corrupt redo log block header
ORA-00353: log corruption near block 10240change 11125950022 time 05/08/2015 22:00:41
ORA-00334: archived log:‘/data/oracle/oradgdata/standby_archive/1_32350_821708334.dbf‘
MRP0: Background Media Recovery processshutdown (powerdes)
Wed May 13 13:39:58 2015
Standby controlfile consistent with primary
RFS[3]: Selected log 5 for thread 1sequence 32488 dbid -903205653 branch 821708334
Wed May 13 13:39:58 2015
Archived Log entry 24243 added for thread 1sequence 32487 ID 0xca2ab4eb dest 3:

分析：

这表明standby已经无法应用归档了，在32350这个归档日志错误，但是归档日志文件/data/oracle/oradgdata/standby_archive/1_32350_821708334.dbf存在，只是无法应用了。

以前使用Duplicate target database命令恢复线上oracle datagard备库，但是这个是整个库恢复，消耗时间比较长；想到oracle还有一种可以基于scn的方式来恢复standby库，所以才有那个基于scn的增量备份来恢复standby库。

1，去备库查询下未归档的记录的起始值

SQL> select min(sequence#) fromv$archived_log where applied=‘NO‘

2  ;

MIN(SEQUENCE#)

--------------

32350

SQL> select max(sequence#) fromv$archived_log where applied=‘NO‘;

MAX(SEQUENCE#)

--------------

32508

SQL>

看到从32350到32508，都是没有应用的归档日志记录。

----------------------------------------------------------------------------------------------------------------
<版权所有，文章允许转载，但必须以链接方式注明源地址，否则追究法律责任!>
原博客地址：   http://blog.csdn.net/mchdba/article/details/45826893
原作者：黄杉 (mchdba)
----------------------------------------------------------------------------------------------------------------

2，去主库查询增量备份需要的SCN号

去主库查询下传输过来的32530归档日志所对应的scn号，查询sql如下：

SELECT SEQUENCE#,to_char(FIRST_CHANGE#)fc,to_char(NEXT_CHANGE#)nc FROM v$archived_log WHERE SEQUENCE# > 32349 ORDERBY 1;

SELECT SEQUENCE#,to_char(FIRST_CHANGE#)fc,to_char(NEXT_CHANGE#)nc FROM v$archived_log WHERE SEQUENCE# = 32350 ORDER BY1;

SQL> SELECT SEQUENCE#,to_char(FIRST_CHANGE#)fc,to_char(NEXT_CHANGE#)nc FROM v$archived_log WHERE SEQUENCE# = 32350 ORDER BY1;

SEQUENCE# FC                                                NC

-------------------------------------------------- ----------------------------------------

32350 11125946510                                      11125975101

32350 11125946510                                      11125975101

SQL>

我们看到主库32350归档日志在主库对应的FIRST_CHANGE#的scn号是11125946510

去主备库检查下scn，可以看到彼此scn不一致：

select to_char(current_scn) scn fromv$database;

主库：

SQL> select to_char(current_scn) scnfrom v$database;

SCN

----------------------------------------

11134239189

SQL>

备库：

SQL> select to_char(current_scn) scnfrom v$database;

SCN

----------------------------------------

11125946526

SQL>

也可以按照备库的最后一个scn号来在主库上进行增量备份，不过为了保险起见，我们以主库的scn号为准，那么就需要基于11125946510这个scn号去主库上做增量备份。

3，在主库上设置log_archive_dest_state_2值，主库的日志无法归档到备库.

先查询自己的归档目录select * from V$ARCHIVE_DEST;

PS：select * from V$ARCHIVE_DEST;查询到STATUS为VALID的，然后DESTINATION为PD_DG（这里是备库的标识）的dest编号就是往备库传输归档日志的；另外一个有目录/oracle/app/oracle/flash_recovery_area/archivelog的就是主库本身的归档日志dest，这个目录存储的就是主库本身的归档日志

ALTER system SET log_archive_dest_state_2 =‘defer‘;

SQL> ALTER system SETlog_archive_dest_state_2 = ‘defer‘;

System altered.

SQL>

4，去备库先停止备库应用

ALTER DATABASE RECOVER MANAGED STANDBYDATABASE CANCEL;

SQL> ALTER DATABASE RECOVER MANAGEDSTANDBY DATABASE CANCEL;

ALTER DATABASE RECOVER MANAGED STANDBYDATABASE CANCEL

*

ERROR at line 1:

ORA-16136: Managed Standby Recovery notactive

SQL>

看到standby已经是not active了，所以不需要执行了。

5，在主库执行备份

基于SCN增量备份：

backup device type disk incremental fromscn 11125946510 database format ‘/home/oracle/db_incre%U.bbk‘;

RMAN> backup device type diskincremental from scn 11125946510 database format‘/home/oracle/db_incre%U.bbk‘;

Starting backup at 13-MAY-15

using target database control file insteadof recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=212 devicetype=DISK

backup will be obsolete on date20-MAY-15

archived logs will not be kept or backed up

channel ORA_DISK_1: starting full datafilebackup set

channel ORA_DISK_1: specifying datafile(s) inbackup set

input datafile file number=00005name=/home/oradata/powerdes/powerdesk01.dbf

input datafile file number=00003name=/home/oradata/powerdes/undotbs01.dbf

input datafile file number=00006name=/home/oradata/powerdes/plas01.dbf

input datafile file number=00001name=/home/oradata/powerdes/system01.dbf

input datafile file number=00002name=/home/oradata/powerdes/sysaux01.dbf

input datafile file number=00007name=/home/oradata/powerdes/pl01.dbf

input datafile file number=00011 name=/home/oradata/powerdes/plcrm01.dbf

input datafile file number=00004name=/home/oradata/powerdes/users01.dbf

input datafile file number=00008name=/home/oradata/powerdes/help01.dbf

input datafile file number=00009name=/home/oradata/powerdes/adobelc01.dbf

input datafile file number=00010name=/home/oradata/powerdes/sms01.dbf

channel ORA_DISK_1: starting piece 1 at13-MAY-15

channel ORA_DISK_1: finished piece 1 at13-MAY-15

piecehandle=/home/oracle/db_increi3q6s13g_1_1.bbk tag=TAG20150513T202207comment=NONE

channel ORA_DISK_1: backup set complete,elapsed time: 00:09:45

using channel ORA_DISK_1

backup will be obsolete on date 20-MAY-15

archived logs will not be kept or backed up

channel ORA_DISK_1: starting full datafilebackup set

channel ORA_DISK_1: specifying datafile(s)in backup set

including current control file in backupset

channel ORA_DISK_1: starting piece 1 at13-MAY-15

channel ORA_DISK_1: finished piece 1 at13-MAY-15

piecehandle=/home/oracle/db_increi4q6s1lp_1_1.bbk tag=TAG20150513T202207comment=NONE

channel ORA_DISK_1: backup set complete,elapsed time: 00:00:01

Finished backup at 13-MAY-15

RMAN>

查看是否备份成功

RMAN> list backup of database;

......

BS Key Type LV Size       Device TypeElapsed Time Completion Time

------- ---- -- ---------- ----------------------- ---------------

3343   Incr    2.41G      DISK        00:09:35     13-MAY-15

BP Key: 3343   Status:AVAILABLE  Compressed: NO  Tag: TAG20150513T202207

Piece Name: /home/oracle/db_increi3q6s13g_1_1.bbk

Keep: NOLOGS             Until:20-MAY-15

List of Datafiles in backup set 3343

File LV Type Ckp SCN    CkpTime  Name

---- -- ---- ---------- --------- ----

1       Incr 11134253054 13-MAY-15/home/oradata/powerdes/system01.dbf

2       Incr 11134253054 13-MAY-15/home/oradata/powerdes/sysaux01.dbf

3       Incr 11134253054 13-MAY-15/home/oradata/powerdes/undotbs01.dbf

4       Incr 11134253054 13-MAY-15/home/oradata/powerdes/users01.dbf

5       Incr 11134253054 13-MAY-15/home/oradata/powerdes/powerdesk01.dbf

6       Incr 11134253054 13-MAY-15/home/oradata/powerdes/plas01.dbf

7       Incr 11134253054 13-MAY-15/home/oradata/powerdes/pl01.dbf

8       Incr 11134253054 13-MAY-15/home/oradata/powerdes/help01.dbf

9       Incr 11134253054 13-MAY-15/home/oradata/powerdes/adobelc01.dbf

10      Incr 11134253054 13-MAY-15/home/oradata/powerdes/sms01.dbf

11      Incr 11134253054 13-MAY-15/home/oradata/powerdes/plcrm01.dbf

RMAN>

去查看备份的文件，看到2个bbk，表示备份成功，如下所示：

[[email protected] ~]$ ll db*

-rw-r----- 1 oracle oinstall 2591825920 May13 20:31 db_increi3q6s13g_1_1.bbk

-rw-r----- 1 oracle oinstall   19234816 May 13 20:31db_increi4q6s1lp_1_1.bbk

[[email protected] ~]$

6，在主库重新生成控制文件

ALTER DATABASE CREATE standby controlfileAS ‘/home/oracle/standby.ctl‘;

SQL> ALTER DATABASE CREATE standbycontrolfile AS ‘/home/oracle/standby.ctl‘;

Database altered.

SQL>

7，copy备份文件到备库

[[email protected] ~]$ scp db*/home/oracle/standby.ctl [email protected]:/data/oracle/backup/restore/

[email protected]‘s password:

db_increi3q6s13g_1_1.bbk                                                                                                                                    100% 2472MB  95.1MB/s   00:26

db_increi4q6s1lp_1_1.bbk                                                                                                                                    100%   18MB  18.3MB/s  00:00

standby.ctl                                                                                                                                                 100%   18MB 18.3MB/s   00:00

[[email protected] ~]$

8，在备库操作，准备好rman前环境

关闭备库

SQL> shutdown immediate

ORA-01109: database not open

Database dismounted.

ORACLE instance shut down.

SQL>

然后启动到nomont状态

SQL> startup nomount

ORACLE instance started.

Total System Global Area 5344731136 bytes

Fixed Size              2213136 bytes

Variable Size              3489663728 bytes

Database Buffers    1811939328 bytes

Redo Buffers                40914944 bytes

SQL>

9，备库上通过rman恢复控制文件

restore controlfile from‘/data/oracle/backup/restore/standby.ctl‘;

RMAN> restore controlfile from‘/data/oracle/backup/restore/standby.ctl‘;

Starting restore at 13-MAY-15

using channel ORA_DISK_1

RMAN-00571:===========================================================

RMAN-00569: =============== ERROR MESSAGESTACK FOLLOWS ===============

RMAN-00571:===========================================================

RMAN-03002: failure of restore command at05/13/2015 20:44:02

RMAN-06172: no AUTOBACKUP found orspecified handle is not a valid copy or piece

RMAN>

是目录权限的问题，需要设置成oracle用户

[[email protected] restore]# ll

total 2568604

-rw-r----- 1 root root 2591825920 May 1320:35 db_increi3q6s13g_1_1.bbk

-rw-r----- 1 root root   19234816 May 13 20:35db_increi4q6s1lp_1_1.bbk

-rw-r----- 1 root root   19185664 May 13 20:35 standby.ctl

[[email protected] restore]# chown -Roracle.dba *

[[email protected] restore]#

RMAN> restore controlfile from‘/data/oracle/backup/restore/standby.ctl‘;

Starting restore at 13-MAY-15

using target database control file insteadof recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=386 devicetype=DISK

channel ORA_DISK_1: copied control filecopy

output filename=/home/oradata/powerdes/control01.ctl

output filename=/oracle/app/oracle/flash_recovery_area/powerdes/control02.ctl

Finished restore at 13-MAY-15

RMAN>

10，备库上rman执行catalog操作

先将数据库加载到mount，然后再执行catalog start with ‘/data/oracle/backup/restore‘恢复

RMAN> alter database mount

2> ;

using target database control file insteadof recovery catalog

database mounted

RMAN> catalog start with ‘/data/oracle/backup/restore‘

RMAN> catalog start with‘/data/oracle/backup/restore‘;

Starting implicit crosscheck backup at13-MAY-15

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=867 devicetype=DISK

Crosschecked 51 objects

Finished implicit crosscheck backup at13-MAY-15

Starting implicit crosscheck copy at13-MAY-15

using channel ORA_DISK_1

Finished implicit crosscheck copy at13-MAY-15

searching for all files in the recoveryarea

cataloging files...

no files cataloged

searching for all files that match thepattern /data/oracle/backup/restore

List of Files Unknown to the Database

=====================================

File Name:/data/oracle/backup/restore/db_increi3q6s13g_1_1.bbk

File Name:/data/oracle/backup/restore/db_increi4q6s1lp_1_1.bbk

File Name: /data/oracle/backup/restore/standby.ctl

Do you really want to catalog the abovefiles (enter YES or NO)? yes

cataloging files...

cataloging done

List of Cataloged Files

=======================

File Name: /data/oracle/backup/restore/db_increi3q6s13g_1_1.bbk

File Name:/data/oracle/backup/restore/db_increi4q6s1lp_1_1.bbk

File Name:/data/oracle/backup/restore/standby.ctl

RMAN>

11，备库上rman执行restore操作

RECOVER DATABASE NOREDO; PS：加NOREDO不用在线日志

RMAN> RECOVER DATABASE NOREDO;

Starting recover at 13-MAY-15

using channel ORA_DISK_1

channel ORA_DISK_1: starting incrementaldatafile backup set restore

channel ORA_DISK_1: specifying datafile(s)to restore from backup set

destination for restore of datafile 00001:/home/oradata/powerdes/system01.dbf

destination for restore of datafile 00002:/home/oradata/powerdes/sysaux01.dbf

destination for restore of datafile 00003:/home/oradata/powerdes/undotbs01.dbf

destination for restore of datafile 00004:/home/oradata/powerdes/users01.dbf

destination for restore of datafile 00005:/home/oradata/powerdes/powerdesk01.dbf

destination for restore of datafile 00006:/home/oradata/powerdes/plas01.dbf

destination for restore of datafile 00007:/home/oradata/powerdes/pl01.dbf

destination for restore of datafile 00008:/home/oradata/powerdes/help01.dbf

destination for restore of datafile 00009:/home/oradata/powerdes/adobelc01.dbf

destination for restore of datafile 00010:/home/oradata/powerdes/sms01.dbf

destination for restore of datafile 00011:/home/oradata/powerdes/plcrm01.dbf

channel ORA_DISK_1: reading from backuppiece /data/oracle/backup/restore/db_increi3q6s13g_1_1.bbk

channel ORA_DISK_1: piecehandle=/data/oracle/backup/restore/db_increi3q6s13g_1_1.bbktag=TAG20150513T202207

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete,elapsed time: 00:05:45

Finished recover at 13-MAY-15

RMAN>

后台alert日志输出为：

Using STANDBY_ARCHIVE_DEST parameterdefault value as /data/oracle/oradgdata/standby_archive

Wed May 13 20:54:42 2015

Incremental restore complete of datafile 4/home/oradata/powerdes/users01.dbf

checkpoint is 11134253054

last deallocation scn is 10905979642

Wed May 13 20:54:53 2015

Incremental restore complete of datafile 8/home/oradata/powerdes/help01.dbf

checkpoint is 11134253054

last deallocation scn is 9881798870

Wed May 13 20:55:08 2015

Incremental restore complete of datafile 9/home/oradata/powerdes/adobelc01.dbf

checkpoint is 11134253054

Wed May 13 20:55:21 2015

Incremental restore complete of datafile 10/home/oradata/powerdes/sms01.dbf

checkpoint is 11134253054

Wed May 13 20:55:34 2015

Incremental restore complete of datafile 11/home/oradata/powerdes/plcrm01.dbf

checkpoint is 11134253054

Incremental restore complete of datafile 7/home/oradata/powerdes/pl01.dbf

checkpoint is 11134253054

last deallocation scn is 10905470965

Wed May 13 20:56:24 2015

db_recovery_file_dest_size of 15360 MB is0.00% used. This is a

user-specified limit on the amount of spacethat will be used by this

database for recovery-related files, anddoes not reflect the amount of

space available in the underlyingfilesystem or ASM diskgroup.

Wed May 13 20:56:26 2015

Incremental restore complete of datafile 2/home/oradata/powerdes/sysaux01.dbf

checkpoint is 11134253054

last deallocation scn is 10906515871

Wed May 13 20:56:43 2015

Incremental restore complete of datafile 1/home/oradata/powerdes/system01.dbf

checkpoint is 11134253054

last deallocation scn is 10825889348

Incremental restore complete of datafile 6/home/oradata/powerdes/plas01.dbf

checkpoint is 11134253054

last deallocation scn is 10905977986

Incremental restore complete of datafile 3/home/oradata/powerdes/undotbs01.dbf

checkpoint is 11134253054

last deallocation scn is 10908635608

Wed May 13 20:59:58 2015

Incremental restore complete of datafile 5/home/oradata/powerdes/powerdesk01.dbf

checkpoint is 11134253054

last deallocation scn is 10906663694

12，备库上重新启动应用日志

ALTER DATABASE recover managed standby DATABASE disconnect FROM SESSION;

SQL>ALTER DATABASE recover managed standby DATABASE disconnect FROM SESSION;

Databasealtered.

SQL>

  后台alert日志输出为：

ALTER DATABASE recover managed standby DATABASE disconnect FROM SESSION

Attemptto start background Managed Standby Recovery process (powerdes)

WedMay 13 21:04:41 2015

MRP0started with pid=19, OS id=23729

MRP0:Background Managed Standby Recovery process started (powerdes)

started logmerger process

WedMay 13 21:04:46 2015

ManagedStandby Recovery not using Real Time Apply

ParallelMedia Recovery started with 16 slaves

Waitingfor all non-current ORLs to be archived...

Allnon-current ORLs have been archived.

MediaRecovery Waiting for thread 1 sequence 32510

Completed:ALTER DATABASE recover managed standby DATABASE disconnect FROM SESSION

13，主库操作往备库传输归档日志

命令为：

ALTER system SET log_archive_dest_state_2 =‘enable‘;

去备库后台alert日志信息为：

Standby controlfile consistent with primary

SRL log 4 needs clearing because log hasnot been created

Errors in file/oracle/app/oracle/diag/rdbms/pddgunq/powerdes/trace/powerdes_rfs_23767.trc:

ORA-00367: checksum error in log fileheader

ORA-00315: log 4 of thread 0, wrong thread# 1 in header

ORA-00312: online log 4 thread 0:‘/home/oradata/powerdes/redo_dg_01.log‘

SRL log 5 needs clearing because log hasnot been created

Errors in file/oracle/app/oracle/diag/rdbms/pddgunq/powerdes/trace/powerdes_rfs_23767.trc:

ORA-00367: checksum error in log fileheader

ORA-00315: log 5 of thread 0, wrong thread# 1 in header

ORA-00312: online log 5 thread 0:‘/home/oradata/powerdes/redo_dg_02.log‘

SRL log 6 needs clearing because log hasnot been created

Errors in file/oracle/app/oracle/diag/rdbms/pddgunq/powerdes/trace/powerdes_rfs_23767.trc:

ORA-00367: checksum error in log fileheader

ORA-00315: log 6 of thread 0, wrong thread# 1 in header

ORA-00312: online log 6 thread 0:‘/home/oradata/powerdes/redo_dg_03.log‘

SRL log 5 needs clearing because log hasnot been created

Errors in file/oracle/app/oracle/diag/rdbms/pddgunq/powerdes/trace/powerdes_rfs_23767.trc:

ORA-00367: checksum error in log fileheader

ORA-00315: log 5 of thread 0, wrong thread# 1 in header

ORA-00312: online log 5 thread 0:‘/home/oradata/powerdes/redo_dg_02.log‘

SRL log 6 needs clearing because log hasnot been created

Errors in file/oracle/app/oracle/diag/rdbms/pddgunq/powerdes/trace/powerdes_rfs_23767.trc:

ORA-00367: checksum error in log fileheader

ORA-00315: log 6 of thread 0, wrong thread# 1 in header

ORA-00312: online log 6 thread 0: ‘/home/oradata/powerdes/redo_dg_03.log‘

SRL log 6 needs clearing because log hasnot been created

Errors in file/oracle/app/oracle/diag/rdbms/pddgunq/powerdes/trace/powerdes_rfs_23767.trc:

ORA-00367: checksum error in log fileheader

ORA-00315: log 6 of thread 0, wrong thread# 1 in header

ORA-00312: online log 6 thread 0:‘/home/oradata/powerdes/redo_dg_03.log‘

RFS[1]: No standby redo logfiles of filesize 52428800 AND block size 512 exist

Clearing online log 6 of thread 0 sequencenumber 0

Errors in file/oracle/app/oracle/diag/rdbms/pddgunq/powerdes/trace/powerdes_rfs_23767.trc:

ORA-00367: checksum error in log fileheader

ORA-00315: log 6 of thread 0, wrong thread# 1 in header

ORA-00312: online log 6 thread 0:‘/home/oradata/powerdes/redo_dg_03.log‘

Wed May 13 21:06:47 2015

Clearing online log 4 of thread 0 sequencenumber 0

Errors in file/oracle/app/oracle/diag/rdbms/pddgunq/powerdes/trace/powerdes_arc4_23630.trc:

ORA-00367: checksum error in log fileheader

ORA-00315: log 4 of thread 0, wrong thread# 1 in header

ORA-00312: online log 4 thread 0:‘/home/oradata/powerdes/redo_dg_01.log‘

Clearing online log 5 of thread 0 sequencenumber 0

Errors in file/oracle/app/oracle/diag/rdbms/pddgunq/powerdes/trace/powerdes_arc4_23630.trc:

ORA-00367: checksum error in log fileheader

ORA-00315: log 5 of thread 0, wrong thread# 1 in header

ORA-00312: online log 5 thread 0:‘/home/oradata/powerdes/redo_dg_02.log‘

RFS[1]: Selected log 4 for thread 1sequence 32511 dbid -903205653 branch 821708334

Wed May 13 21:06:51 2015

RFS[2]: Assigned to RFS process 23775

RFS[2]: Identified database type as‘physical standby‘: Client is ARCH pid 20139

RFS[2]: Selected log 5 for thread 1sequence 32510 dbid -903205653 branch 821708334

Wed May 13 21:06:52 2015

RFS[3]: Assigned to RFS process 23777

RFS[3]: Identified database type as‘physical standby‘: Client is ARCH pid 20131

Wed May 13 21:06:52 2015

Archived Log entry 1 added for thread 1sequence 32510 ID 0xca2ab4eb dest 3:

Wed May 13 21:06:52 2015

Media Recovery Log/data/oracle/oradgdata/standby_archive/1_32510_821708334.dbf

Wed May 13 21:06:54 2015

Archived Log entry 2 added for thread 1sequence 32511 ID 0xca2ab4eb dest 3:

Changing standby controlfile to MAXIMUMAVAILABILITY level

RFS[1]: Selected log 4 for thread 1sequence 32512 dbid -903205653 branch 821708334

Wed May 13 21:07:07 2015

Media Recovery Log/data/oracle/oradgdata/standby_archive/1_32511_821708334.dbf

Media Recovery Waiting for thread 1sequence 32512 (in transit)

14，去主库备库查看归档日志情况，是否保持一致

主库：

SQL> archive log list;

Database log mode        Archive Mode

Automatic archival         Enabled

Archive destination       /oracle/app/oracle/flash_recovery_area/archivelog

Oldest online log sequence     32510

Next log sequence to archive   32512

Current log sequence             32512

SQL>

备库：

SQL> archive log list;

Database log mode        Archive Mode

Automatic archival         Enabled

Archive destination        /data/oracle/oradgdata/standby_archive

Oldest online log sequence     32511

Next log sequence to archive   0

Current log sequence             32512

SQL>

15，在主库切下归档日志，看是否应用到备库

PS：此操作有一定危险性，切勿在业务高峰期操作，最后在凌晨时分业务低峰时期操作，以免误伤无数，^_^

alter system switch logfile;

SQL> alter system switch logfile;

System altered.

SQL> archive log list;

Database log mode        Archive Mode

Automatic archival         Enabled

Archive destination       /oracle/app/oracle/flash_recovery_area/archivelog

Oldest online log sequence     32511

Next log sequence to archive   32513

Current log sequence             32513

SQL>

16，在主库切完日志后，去备库看下日志有没有传输过去并应用起来

备库alert日志

Wed May 13 21:11:23 2015

Media Recovery Log/data/oracle/oradgdata/standby_archive/1_32512_821708334.dbf

Media Recovery Waiting for thread 1sequence 32513 (in transit)

备库alert loglist;

SQL> archive log list;

Database log mode        Archive Mode

Automatic archival         Enabled

Archive destination       /data/oracle/oradgdata/standby_archive

Oldest online log sequence     32512

Next log sequence to archive   0

Current log sequence             32513

SQL>

17，以open read only模式打开备库，在备库操作

先查看数据库状态

SQL> select open_mode fromv$database;

OPEN_MODE

--------------------

MOUNTED

SQL>

取消applied

alter database recover managed standbydatabase using current logfile disconnect from session;

SQL> alter database recover managedstandby database using current logfile disconnect from session;

alter database recover managed standbydatabase using current logfile disconnect from session

*

ERROR at line 1:

ORA-01153: an incompatible media recoveryis active

SQL> SQL>

有报错，如下解决

SQL> alter database recover managedstandby database cancel;

Database altered.

SQL>

再查看下是否有未应用的NO的，没有NO的，正常如下：

SQL> select sequence# ,applied fromv$archived_log where applied=‘NO‘ order by sequence# ;

no rows selected

SQL>

以open readonly模式打开

SQL> alter database open read only;

Database altered.

SQL>

SQL> select open_mode fromv$database;

OPEN_MODE

--------------------

READ ONLY

SQL>

然后启动应用

SQL> alter database recover managedstandby database disconnect from session;

Database altered.

SQL>

SQL> select open_mode fromv$database;

OPEN_MODE

--------------------

READ ONLY WITH APPLY

SQL>

18，再检查主库备库是否一致

通过以下命令查看：

select sequence#,applied fromv$archived_log order by sequence# asc;

archive log list;

查询最大归档日志序列号：

SELECTSEQUENCE#,to_char(FIRST_CHANGE#),to_char(NEXT_CHANGE#) FROM v$archived_logWHERE SEQUENCE# > 32507 ORDER BY 1;

参考文章：http://www.cnblogs.com/shawnloong/p/3970419.html

时间： 2024-10-20 08:55:16

ORACLE 11G通过SCN做增量备份修复standby库详细过程的相关文章

【Oracle】基于SCN的增量备份修复DataGuard GAP

1. 首先来模拟Gap的产生 1.1. 备库关闭: [email protected]_s>shutdown immediate; 1.2. 主库切换日志 [email protected]>select SEQUENCE#,ARCHIVED,STATUS from v$log; SEQUENCE# ARC STATUS ---------- --- ---------------- 61 YES ACTIVE 62 YES ACTIVE 63 NO  CURRENT [email prote

【RMAN】使用RMAN增量备份刷新 Standby Database

Step 1: Create the Incremental Backup RMAN> BACKUP DEVICE TYPE DISK INCREMENTAL FROM SCN 750983 DATABASE FORMAT '/tmp/incr_for_standby/bkup_%U'; Step 2: Make the Incremental Backup Accessible at the Standby Database ftp or scp copy 增量备份到 standby 端 St

ORACLE 11G DataGuard Failover后如何修复standby库

failover后的问题场景:由于做failover测试,一个standby已经被我变成了primary库,如何将这个新的primary库(原来的standby)变回来重新成为standby两个都是primary,p1,p2,如何将一个primary库1设置成p1,而另外一个primary库p2设置成p1的standby库呢? 1,问题描述原来的primary库:SQL> select open_mode,database_role from v$database; OPEN_MODE    

xtrabackup2.4 备份Precona5.6数据库，做增量备份与还原

1.Full backuop,一定要先做:     innobackupex --defaults-file=/etc/my.cnf --user=root --password=evlink /home/mysql/backup/2.Incremental backup,可以每隔一小时或者三小时做一次:    innobackupex --defaults-file=/etc/my.cnf --user=root --password=evlink --incremental /home/my

ORACLE 11G 利用泠备份恢复standby库

利用泠备份恢复standby数据库 1 開始在备库上进行泠备份 先查好控制文件.redo.undo文件.数据文件的路径 1.1 先关闭主库的归档日志传输 SQL> ALTER system SETlog_archive_dest_state_2 ='DEFER'; System altered. SQL> 1.2 先关闭standby库 SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instan

增量备份解决dataguard库日志gap

有时候备库滞后于主库很长时间了,而主库的归档日志已经不存在了,此时的日志间隔如何消除那,很多人选择重建备库,这个是很麻烦的,尤其当主库数据量很大的时候,此时我们还有另外一种选择,那就是使用增量数据库备份来前滚备库,消除日志间隔,具体作法如下:1.备库查看丢失的归档时的scn号 idle> select current_scn from v$database; CURRENT_SCN ----------- 96458277 2.主库创建基于丢失归档scn号为起始的增量备份(要确定主库和备库的目标

增量备份解决dg库日志gap

有时候备库滞后于主库很长时间了,而主库的归档日志已经不存在了,此时的日志间隔如何消除那,很多人选择重建备库,这个是很麻烦的,尤其当主库数据量很大的时候,此时我们还有另外一种选择,那就是使用增量数据库备份来前滚备库,消除日志间隔,具体作法如下: 1.备库查看丢失的归档时的scn号 idle> select current_scn from v$database; CURRENT_SCN ----------- 96458277 2.主库创建基于丢失归档scn号为起始的增量备份(要确定主库和备库的目

mysql增量备份依次恢复库

#!/bin/bash#scripts sh recovery_increment.sh 时间 日期 例如: 14 20180228 bakfile=/data/dbbackuplogfile=/data/bak.log dbuser=xxxdbpasswd=xxxxip=ifconfig | grep "inet addr"| grep Bcast| awk '{print $2}'| awk -F":" '{print $2}' #增量还原 recoveryin

ORACLE 11g 用Duplicate恢复Data Guard 备库详细过程

1.先查找备库控制文件路径 先在备库上找出控制文件的路径,通过和主库一样,不过为了以防万一,还是check为好. SQL>  select name from v$controlfile; NAME -------------------------------------------------------------------------------- /Oracle/app/oracle/oradata/powerdes/control01.ctl /oracle/app/oracle/