ITPub博客

首页 > Linux操作系统 > Linux操作系统 > dataguard(rac)

dataguard(rac)

原创 Linux操作系统 作者:tolilong 时间:2012-06-18 10:30:52 0 删除 编辑
         


  Rac and dataguard(singal)

 

Dataguard 架构可以按照功能分为3部分:

l         日志发送(redo send)

l         日志接受(redo receive)

l         日志应用(redo apply)

1.日志发送

     可以由primary databaseLGWR或者ARCH进程完成,不同的规定目的可以使用不同的方法,一个目的地只能选用一种方法。

     (a).ARCH(默认情况下,primary database使用)

         (1)LGWR将连接日志写满后,会发生log switch,并处罚本地归档。

         (2)完成本地归档后,连接日志就可以被覆盖重用。

(3)ARCH进程通过net把归档日志发送给standby databaseRFS进程。

(4)Standby database端的RFS进程将接受到的日志写入到归档日志。

(5)standby database端的MRP进程(redo apply) or LSP process(sql apply)standby database apply这些日志,同步数据。


  Log_archive_dest_2=’service=st’

           缺点:只有发生归档的时候才会将日志发送到standby,如果primary database发送岩机。日志就不能传送过去了。

          

 

   要想避免数据丢失,就必须使用LGWRLGWR包含SYNCASYNC

      (b).LGWRSYNC同步

          (1).Primary database通过LGWR,LNSn(network server process)将日志写到本地日志文件和远程目的地(network

          (2).LGWR必须等待本地和网络传输成功,才能算提交

          (3).standby database RFS进程将接受到的日志写入到standby redo log日志中。

          (4).primary database的日志切换也会触发standby database上的日志切换。

            Redo是实时传输的,于是standby database可以使用两种恢复方式:实时恢复(real-time apply:只要RFS写入了standby redo log就立即恢复)和归档时恢复(在完成对standby redo log归档时才触发恢复)

      

           Log_archive_dest_2=’service=st lgwr sync net_timeout=30’

           Net_timeout(s)表示多长时间没有发送成功,lgwr会抛出错误。

 

 

       (c).LGWRASYNC

           lgwr sync 如果发送给standby database失败,则lgwr就会出错误,lgwr sync特别依赖于网络

           (1).primary database产生redo日志后,lgwr把日志同时提交给日志文件和本地lns进程,但是lgwr进程只需要写入日志文件就可以,不必等待lnsn进程的网络传送成功。

           (2).LNSn进程异步地把日志内容传送到standby database.多个LNSn进程并发发送

           (3).primary databaseonline redo log写满后发生log switch,触发归档操作,也充分standby databasestandby redo log的归档,然后触发MRPLSP进程恢复归档日志      

  

Log_archive_dest_2=’service=st lgwr async’

 

 

 

2.日志接受

     如果写到standby redo log,primary database发送日志切换是,standby database也会触发日志切换,并把这个standby redo log归档。Standby database归档日志位置算法如下:

       

 

3.日志应用 (redo apply)

 Physical standby use media recovery没有数据类型限制,mount下恢复

 Logical standby user logminer技术,通过日志内容还原成sql,可以查看dba_logstdby_unsupported不支持的类型

 

 Redo apply分为real-time apply(必须standby redo log) 和归档时应用(发送在primary database日志切换时)

Alter database recover managed standby database disconnect from session

 Alter database recover managed standby database using current logfile

             --physical standby,real-time

Alter database start logical standby apply immediate

--logical standby ,real-time

 

 

4.重要进程

Primary database

LGWR ---

LNS  ---logwrite network service

ARCH ---归档进程

Standby

RFS  ---reote file server:接受来自网络上的redo日志,写入到standby redo log(SRL)

ARCH ---归档进程

MRP  ---managed recovery process负责协调介质恢复管理工作

PR0X ---parallel recover process具体恢复工作进程,real-time中,会从SRL中读取日志,其他模式下,是从归档日志中读取日志进行应用。

LSP  ---parallel recover process只有在logical standby 才有

 

 

 

5.standby redo logfile (SRL)

SRL只在standby database,对于standby role而言,从primary数据库接

受到的日志记录在SRL中,也可以记录在archived log中。不会写在ORL中。

SRL必须和ORL大小完全相同,否则SRL不会被用到。数量上应该按照每个

实例n+1的数量关系来配置

 

 

 

6.数据保护类型

a.maximun protection –必须配置standby redo log.rac中,一个实例和standby发送网络问题,这个实例会crash,另一个实例crash recovery.standby会忽视crash掉的实例。

b.maximun avalilability –SYNCstandby redo log,如果在30s(默认)内没有收到反馈信息,standby database就标记为failedMaximun availability 变成了maximun protection了。

c.maximun performance(默认)

shutdown immediate à alter database set standby database maximize availability à alter database open

 

7.GAP

Gap解决机制.

事前主动式proactive –arch process  ping 来完成的。

另一种是reactive  --通过standby databaseapply进程完成的,配置fal_client(standby),fal_server(primary)定义从那些数据库获取缺少的日志(oracle net name)

 Alter database register logfile ‘logfilename’

 

 

 

 

 

 

 

 




 

8 real-time apply (RTA)

Normal 0 0 2 false false false MicrosoftInternetExplorer4 必须配置standby redo logfile减少了恢复时间,提供实时数据(11g active dataGuard,在恢复的同时可以对外提供服务) Normal 0 0 2 false false false MicrosoftInternetExplorer4  


 

 

 

 

 

 

 

9.如何监控恢复性能

Standby database

Select * from v$recovery_progress where item in

(‘Active Apply Rate’,’Average Apply Rate’,’Redo Applied’)

Active apply rate3s的平均日志应用速率 kb/s

Average apply rate 自从本次恢复开始来平均的日志应用速率 kb/s

Redo applied 本次恢复开始以来,已经应用的日志数量

 

查看redo传输和redo应用的延迟情况

Standby database

Select * from v$dataguard_stats

Where name in(‘transport lag’,’apply lag’)

transport lag 代表primary standby之间日志传输的延迟。0表示没有延迟

apply lag日志应用的延迟情况。

 

 

 

 

 

 

Eg: rac primary and single standby

1.在两个数据库上配置tnsname.ora listener.ora

   rac的两台主机上配置tnsname.ora

standby =

  (DESCRIPTION =

    (ADDRESS = (PROTOCOL = TCP)(HOST = 10.201.18.196)(PORT = 1521))

    (CONNECT_DATA =

      (SERVER = DEDICATED)

      (SERVICE_NAME = myrac)

    )

  )

 

 

standby上配置

Listener.ora

 

SID_LIST_LISTENER =

  (SID_LIST =

    (SID_DESC =

      (GLOBAL_DBNAME = myrac)

      (ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1)

      (SID_NAME = myrac)

    )

  )

 

LISTENER =

  (DESCRIPTION =

    (ADDRESS = (PROTOCOL = TCP)(HOST = 10.201.18.196)(PORT = 1521))

  )

 

ADR_BASE_LISTENER = /u01/oracle

 

Tnsname.ora

 

MYRAC1 =

  (DESCRIPTION =

    (ADDRESS = (PROTOCOL = TCP)(HOST = 10.201.18.193)(PORT = 1521))

    (CONNECT_DATA =

      (SERVER = DEDICATED)

      (SERVICE_NAME = myrac)

      (INSTANCE_NAME = myrac1)

    )

  )

 

 

MYRAC2 =

  (DESCRIPTION =

    (ADDRESS = (PROTOCOL = TCP)(HOST = 10.201.18.194)(PORT = 1521))

    (CONNECT_DATA =

      (SERVER = DEDICATED)

      (SERVICE_NAME = myrac)

      (INSTANCE_NAME = myrac2)

    )

  )

 

 

 

2.准备参数文件。

db_name='myrac'

myrac1.thread=1

myrac2.thread=2

*.sga_target=429916160

compatible='10.2.0.1.0'

control_files='/u01/app/oradata/myrac/control01.ctl','/u01/app/oradata/myrac/control02.ctl','/u01/app/oradata/myrac/control03.ctl'

db_name='myrac'

instance_name=myrac

remote_login_passwordfile='exclusive'

undo_management='AUTO'

undo_tablespace='UNDOTBS1'

myrac2.undo_tablespace='UNDOTBS2'

db_file_name_convert='+dgdata/myrac/datafile','/u01/app/oradata/myrac','+dgdata/myrac/tempfile','/u01/app/oradata/myrac'

log_file_name_convert='+dgdata/myrac/onlinelog','/u01/app/oradata/myrac'

 

 

3.create password for standby

orapwd password=oracle file=orapwmyrac entries=10

 

 

4.rman 备份primary database

RMAN> run{

2> backup as compressed backupset database plus archivelog format '/u01/rmanbackup/%U';

3> backup current controlfile for standby format '/u01/rmanbackup/%c';

4> }

 

backup的文件copystandby的相同目录下。

 

 

 

 

5.standby启动到nomount阶段

SQL> startup nomount;

ORACLE instance started.

 

Total System Global Area  167772160 bytes

Fixed Size                  2019320 bytes

Variable Size             113246216 bytes

Database Buffers           50331648 bytes

Redo Buffers                2174976 bytes

 

6.利用rman创建standby database

primary database

[oracle@rac10g1 rmanbackup]$ rman target / auxiliary sys/oracle@standby

 

Recovery Manager: Release 10.2.0.1.0 - Production on Sun Jun 17 09:02:10 2012

 

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

 

connected to target database: MYRAC (DBID=4188454358)

connected to auxiliary database: MYRAC (not mounted)

 

RMAN> duplicate target database for standby;

 

Starting Duplicate Db at 17-JUN-12

using target database control file instead of recovery catalog

allocated channel: ORA_AUX_DISK_1

channel ORA_AUX_DISK_1: sid=35 devtype=DISK

 

contents of Memory Script.:

{

   restore clone standby controlfile;

   sql clone 'alter database mount standby database';

}

executing Memory Script

 

Starting restore at 17-JUN-12

using channel ORA_AUX_DISK_1

 

channel ORA_AUX_DISK_1: starting datafile backupset restore

channel ORA_AUX_DISK_1: restoring control file

channel ORA_AUX_DISK_1: reading from backup piece /u01/rmanbackup/23ndofos_1_1

channel ORA_AUX_DISK_1: restored backup piece 1

piece handle=/u01/rmanbackup/23ndofos_1_1 tag=TAG20120617T090011

channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:13

output filename=/u01/app/oradata/myrac/control01.ctl

output filename=/u01/app/oradata/myrac/control02.ctl

output filename=/u01/app/oradata/myrac/control03.ctl

Finished restore at 17-JUN-12

 

sql statement: alter database mount standby database

released channel: ORA_AUX_DISK_1

 

contents of Memory Script.:

{

   set newname for tempfile  1 to

 "/u01/app/oradata/myrac/temp.263.784025901";

   switch clone tempfile all;

   set newname for datafile  1 to

 "/u01/app/oradata/myrac/system.259.785492493";

   set newname for datafile  2 to

 "/u01/app/oradata/myrac/undotbs1.265.785492537";

   set newname for datafile  3 to

 "/u01/app/oradata/myrac/sysaux.258.785492545";

   set newname for datafile  4 to

 "/u01/app/oradata/myrac/users.272.785492561";

   set newname for datafile  5 to

 "/u01/app/oradata/myrac/example.256.785492571";

   set newname for datafile  6 to

 "/u01/app/oradata/myrac/undotbs2.257.785492581";

   set newname for datafile  7 to

 "/u01/app/oradata/myrac/test.264.785492583";

   set newname for datafile  8 to

 "/u01/app/oradata/myrac/users.260.785492597";

   restore

   check readonly

   clone database

   ;

}

executing Memory Script

 

executing command: SET NEWNAME

 

renamed temporary file 1 to /u01/app/oradata/myrac/temp.263.784025901 in control file

 

executing command: SET NEWNAME

 

executing command: SET NEWNAME

 

executing command: SET NEWNAME

 

executing command: SET NEWNAME

 

executing command: SET NEWNAME

 

executing command: SET NEWNAME

 

executing command: SET NEWNAME

 

executing command: SET NEWNAME

 

Starting restore at 17-JUN-12

allocated channel: ORA_AUX_DISK_1

channel ORA_AUX_DISK_1: sid=35 devtype=DISK

 

channel ORA_AUX_DISK_1: starting datafile backupset restore

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

restoring datafile 00001 to /u01/app/oradata/myrac/system.259.785492493

restoring datafile 00002 to /u01/app/oradata/myrac/undotbs1.265.785492537

restoring datafile 00003 to /u01/app/oradata/myrac/sysaux.258.785492545

restoring datafile 00004 to /u01/app/oradata/myrac/users.272.785492561

restoring datafile 00005 to /u01/app/oradata/myrac/example.256.785492571

restoring datafile 00006 to /u01/app/oradata/myrac/undotbs2.257.785492581

restoring datafile 00007 to /u01/app/oradata/myrac/test.264.785492583

restoring datafile 00008 to /u01/app/oradata/myrac/users.260.785492597

channel ORA_AUX_DISK_1: reading from backup piece /u01/rmanbackup/22ndoflo_1_1

channel ORA_AUX_DISK_1: restored backup piece 1

piece handle=/u01/rmanbackup/22ndoflo_1_1 tag=TAG20120617T085832

channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:01:59

Finished restore at 17-JUN-12

 

contents of Memory Script.:

{

   switch clone datafile all;

}

executing Memory Script

 

datafile 1 switched to datafile copy

input datafile copy recid=26 stamp=786193911 filename=/u01/app/oradata/myrac/system.259.785492493

datafile 2 switched to datafile copy

input datafile copy recid=27 stamp=786193911 filename=/u01/app/oradata/myrac/undotbs1.265.785492537

datafile 3 switched to datafile copy

input datafile copy recid=28 stamp=786193911 filename=/u01/app/oradata/myrac/sysaux.258.785492545

datafile 4 switched to datafile copy

input datafile copy recid=29 stamp=786193911 filename=/u01/app/oradata/myrac/users.272.785492561

datafile 5 switched to datafile copy

input datafile copy recid=30 stamp=786193911 filename=/u01/app/oradata/myrac/example.256.785492571

datafile 6 switched to datafile copy

input datafile copy recid=31 stamp=786193911 filename=/u01/app/oradata/myrac/undotbs2.257.785492581

datafile 7 switched to datafile copy

input datafile copy recid=32 stamp=786193911 filename=/u01/app/oradata/myrac/test.264.785492583

datafile 8 switched to datafile copy

input datafile copy recid=33 stamp=786193911 filename=/u01/app/oradata/myrac/users.260.785492597

Finished Duplicate Db at 17-JUN-12

 

检查standby数据库

Select status from v$instance;

Select member from v$Logfile;

Select name from v$datafile

Select name from v$tempfile;

 

 

 

7.create standby redo log日志

alter database add standby  logfile thread 1  group 7  ('/u01/app/oradata/myrac/standby_log7') size 50m

alter database add standby  logfile thread 1  group 8  ('/u01/app/oradata/myrac/standby_log8') size 50m

alter database add standby  logfile thread 1  group 9  ('/u01/app/oradata/myrac/standby_log9') size 50m

alter database add standby  logfile thread 1  group 10  ('/u01/app/oradata/myrac/standby_log10') size 50m

alter database add standby  logfile thread 2  group 11  ('/u01/app/oradata/myrac/standby_log11') size 50m

alter database add standby  logfile thread 2  group 12  ('/u01/app/oradata/myrac/standby_log12') size 50m

alter database add standby  logfile thread 2  group 13  ('/u01/app/oradata/myrac/standby_log13') size 50m

alter database add standby  logfile thread 2  group 14  ('/u01/app/oradata/myrac/standby_log14') size 50m

 

 

 

 

8.检查各个实例上日志传送情况:

select dest_name,status,error from v$archive_dest

 

9.切换switchover

Rac中,切换primary and standby都只能有一个instance活动,其他的

instance必须关闭

rac10g2中执行

SQL> shutdown immediate

Rac10g1中:

SQL> alter database commit to switchover to physical standby with session shutdown;

Database altered.

 

SQL> shutdown immediate

ORA-01507: database not mounted

ORACLE instance shut down.

 

standby 中执行:

SQL> alter database commit to switchover to primary with session shutdown;

SQL> shutdown immediate

ORA-01109: database not open

 

Database dismounted.

ORACLE instance shut down.

SQL> startup

ORACLE instance started.

 

Total System Global Area  167772160 bytes

Fixed Size                  2019320 bytes

Variable Size             113246216 bytes

Database Buffers           50331648 bytes

Redo Buffers                2174976 bytes

Database mounted.

Database opened.

 

SQL> alter system set log_archive_dest_1='service=myrac';

 

 

rac10g1中:

Startup mount;

然后create standby redo logfile;

 

 

其中会遇到如下错误:

ORA-16009: remote archive log destination must be a STANDBY database

需要做如下修改(primary,standby)

SQL> alter system set log_archive_dest_3='service=myrac’

SQL> alter system set log_archive_dest_3='service=myrac VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)';  --增加

 

 

 

 

 

 

 10.角色转换

包括switchoverfailover

l         switchover用于有准备的,有计划的(升级)failover用于意料之外的突发情况(断电)

l         数据丢失不同:switchover不会有数据丢失,failvoer通常意味着数据丢失

l         善后不同:switchover之后dataguard环境不会破坏,仍然有primary,standbyFailoverdataguard环境被破坏,需要重建。

(A).switchover

(i)Alter database commit to switchover to physical standby[with session shutdown]

With session shutdown –表示如果当前有活动,则无法进行切换。

执行上面命令会发生这样几个事情:

l         执行完这条命令之后,primary database不再生成redo,所有DML相关cursor都会失效,用户将不能在执行事务

l         日志线程的当前日志被归档,并在接下来的每个thread新的日志头记录一个特殊的切换标志EOR(end of redo),然后再次归档,其结果就是把EOR发送给所有standby databaseprimary database转化为standby.

l         在这个旧的primary database上,MRP(managed recovery process)进程会自动启动,并应用最后一个归档日志,也就是EOR这个日志,一旦这个EOR应用完成,数据库dismounted,并且必须启动成一个standby database;

(ii)standby database上将会出现如下信息:

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

Media Recovery Log +DGFLASH/myrac/archivelog/2012_06_17/thread_1_seq_48.271.786198131

Identified End-Of-Redo for thread 1 sequence 48

Sun Jun 17 12:22:23 2012

Media Recovery End-Of-Redo indicator encountered

Sun Jun 17 12:22:23 2012

Media Recovery Applied until change 2992775

Sun Jun 17 12:22:23 2012

MRP0: Media Recovery Complete: End-Of-REDO (myrac1)

Resetting standby activation ID 4190630354 (0xf9c7f1d2)

Sun Jun 17 12:22:24 2012

MRP0: Background Media Recovery process shutdown (myrac1)

(iii)Alter database commit to switchover to primary with session

Standby database的控制文件也从standby控制文件转换为标准的控制文件。

(B)failover

failover步骤:

l         primary database出现故障,需要将standby database强制转换为primary database

Alter database recover managed standby database cancel

l         Alter database recover managed standby database finish [force]

这个命令告诉standby databaseMRP,不要在等redo。并尽可以多的应用现在的redo记录,并模拟一个switchover命令,把EOR记录在redo投中,就像primary database收到的EOR一样。

Force参数的作用是关闭RFS进程,否则MPR进程看到的RFS还存在,就会认为对应的primary database还是正常的,就不会允许进行failover。到了oracle11g之后,这个是默认的行为,force参数取消了。

l         之后,dataguard的保护级别会降到 maximum performance

l         Standby database已经处于EOR记录状态,就可以正常的switchover

Alter database commit to switchover to primary with session shutdown

l         Close database and startup database

 

Eg

(1).确定现在primary,standby database一样。

select max(sequence#) from v$archived_log

(2).关闭standby database

SQL> shutdown immediate

ORA-01109: database not open

 

Database dismounted.

ORACLE instance shut down.

(3).primary database产生日志

create table scott.t2 as select * from all_objects

alter system switch logfile

create table scott.t3 as select * from all_objects

alter system switch logfile

create table scott.t4 as select * from all_objects

alter system switch logfile

insert into scott.t4 select * from scott.t4

alter system switch logfile

(4).主库上删除产生的日志,防止standby启动时,Gap Resulation机制重传这些日志

(5).启动standby database

SQL> startup mount;

ORACLE instance started.

 

Total System Global Area  167772160 bytes

Fixed Size                  2019320 bytes

Variable Size             113246216 bytes

Database Buffers           50331648 bytes

Redo Buffers                2174976 bytes

Database mounted.

SQL> alter database recover managed standby database disconnect from session;

 

Database altered.

 

primary database上执行,启动gap resulation

SQL> alter system switch logfile;

 

System altered.

 

查看standbyalter日志

RFS[1]: Assigned to RFS process 16971

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

Sun Jun 17 17:36:10 2012

RFS LogMiner: Client disabled from further notification

RFS[1]: Archived Log: '/u01/arch/1_64_785498077.dbf'

Sun Jun 17 17:37:02 2012

Redo Shipping Client Connected as PUBLIC

-- Connected User is Valid

RFS[2]: Assigned to RFS process 16974

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

Sun Jun 17 17:37:06 2012

Fetching gap sequence in thread 2, gap sequence 46-49

FAL[client]: Error fetching gap sequence, no FAL server specified

Sun Jun 17 17:37:13 2012

RFS[2]: Archived Log: '/u01/arch/2_46_785498077.dbf'

Sun Jun 17 17:37:36 2012

……

FAL[client]: Failed to request gap sequence

 GAP - thread 1 sequence 63-63

 DBID 4188454358 branch 785498077

FAL[client]: All defined FAL servers have been attempted.

 

 

(6).重新产生日志,并进行日志切换:

可以查询v$archived_log看出,RFS正常工作,日志被正常接收。

 

 

(7).standby database ,停止MRP进程

Alter database recover managed standby database cancel

 

(8).使用如下finish命令

Alter database recover managed standby database finish

 

alter database recover managed standby database finish

Sun Jun 17 18:16:34 2012

SKIP STANDBY LOGFILE option no longer needed for RECOVERFINISH. Option ignored

Sun Jun 17 18:16:34 2012

Attempt to do a Terminal Incomplete Recovery (myrac)

Sun Jun 17 18:16:34 2012

Media Recovery Start: Managed Standby Recovery (myrac)

Managed Standby Recovery not using Real Time Apply

Media Recovery Waiting for thread 1 sequence 63

Fetching gap sequence in thread 1, gap sequence 63-63

FAL[client]: Error fetching gap sequence, no FAL server specified

FAL[client]: Failed to request gap sequence

 GAP - thread 1 sequence 63-63

 DBID 4188454358 branch 785498077

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.

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

RECOVER...FINISH not allowed due to gap

 GAP - thread 1 sequence 63-63

 DBID 4188454358 branch 785498077

Recovery interrupted!

Sun Jun 17 18:16:34 2012

Media Recovery failed with error 16171

ORA-283 signalled during: alter database recover managed standby database finish...

 

(9).alter database activate standby database

这个命令是不完全恢复,然后用resetlogs方式打开数据库。这个scn也被

记录到数据库中

SQL> select standby_became_primary_scn from v$database;

 

STANDBY_BECAME_PRIMARY_SCN

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

                   3003715

 

alter database activate standby database

Sun Jun 17 18:17:46 2012

ALTER DATABASE ACTIVATE [PHYSICAL] STANDBY DATABASE (myrac)

Sun Jun 17 18:17:47 2012

RESETLOGS after incomplete recovery UNTIL CHANGE 3003717

Resetting resetlogs activation ID 4190600575 (0xf9c77d7f)

Online log /u01/app/oradata/myrac/group_1.270.785492673: Thread 1 Group 1 was previously cleared

Online log /u01/app/oradata/myrac/group_2.269.785492691: Thread 1 Group 2 was previously cleared

Online log /u01/app/oradata/myrac/group_3.267.785497739: Thread 2 Group 3 was previously cleared

Online log /u01/app/oradata/myrac/group_4.266.785492721: Thread 2 Group 4 was previously cleared

Online log /u01/app/oradata/myrac/group_5.262.785492745: Thread 1 Group 5 was previously cleared

Online log /u01/app/oradata/myrac/group_6.261.785498131: Thread 2 Group 6 was previously cleared

Standby became primary SCN: 3003715

Sun Jun 17 18:17:47 2012

Setting recovery target incarnation to 7

Sun Jun 17 18:17:47 2012

Converting standby mount to primary mount.

Sun Jun 17 18:17:47 2012

ACTIVATE STANDBY: Complete - Database mounted as primary (myrac)

Completed: alter database activate standby database

 

 

 

11.failover之后工作

Failover之后,dataguar的环境被破坏。就需要重新建立dataguard环境。

可以使用flashback 快速完成恢复。

步骤如下:

1.alter system set db_recovery_file_dest_size=xG;

  Alter system set db_recovery_file_dest=’xxxxxxxx’

  Shutdown immediate à startup mount à

  Alter database flashback on à alter database open

2.primary database 的生成时间

SQL> select standby_became_primary_scn from v$database;

 

STANDBY_BECAME_PRIMARY_SCN

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

                   3003715

3.在得到scn后,flashback database primary database 到这个scn

Flashback database to scn xxxxx;

4.转换为standby database

Alter database convert to physical standby

 

5.重启这个数据库

startup

 

6.alter database recover managed standby database disconnect from session

在执行过程中,MRP进程很快就停止了。需要重新一遍这个命令

 

 

 

12.standby下维护联机日志

(1)手工添加日志文件

Alter database recover managed standby database cancel

Alter system set standby_file_management=’manual’

Alter database add logfile group 4 ‘xxxx’ size 50m

Alter system set standby_file_management=’auto’

Alter database recover managed standby database disconnect from session

(2)手工删除日志文件

Clearing_current,current这两种状态的日志不能删除。

对于clearing,unused,inactive状态的日志,可执行如下操作:

Alter database recover managed standby database cancel

Alter system set standby_file_management=’manual’

Alter database clear logfile group 2

Alter database drop logfile group 2

Alter system set standby_file_management=’auto’

Alter database recover managed standby database disconnect from session

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/24237320/viewspace-733113/,如需转载,请注明出处,否则将追究法律责任。

下一篇: scn and timestamp
请登录后发表评论 登录
全部评论

注册时间:2010-07-13

  • 博文量
    406
  • 访问量
    958637