dataguard(rac)

最新推荐文章于 2024-01-06 11:17:41 发布

cizhiyou2391

最新推荐文章于 2024-01-06 11:17:41 发布

阅读量183

点赞数

Rac and dataguard(singal)

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

l 日志发送(redo send)

l 日志接受(redo receive)

l 日志应用(redo apply)

1.日志发送

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

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

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

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

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

(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发送岩机。日志就不能传送过去了。

要想避免数据丢失，就必须使用LGWR，LGWR包含SYNC和ASYNC

(b).LGWR的SYNC同步

(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).LGWR的ASYNC

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

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

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

(3).primary database的online redo log写满后发生log switch，触发归档操作，也充分standby database对standby redo log的归档，然后触发MRP或LSP进程恢复归档日志

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 –SYNC，standby redo log,如果在30s(默认)内没有收到反馈信息，standby database就标记为failed。Maximun 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 database的apply进程完成的，配置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 data Guard ，在恢复的同时可以对外提供服务 ) 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 rate前3s的平均日志应用速率 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的文件copy到standby的相同目录下。

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

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

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.角色转换

包括switchover和failover

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

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

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

(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 database，primary 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 database的MRP，不要在等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.

查看standby的alter日志

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/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/24237320/viewspace-733113/

cizhiyou2391

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
dataguard(rac)

Rac and dataguard(singal) Dataguard 架构可以按照功能分为3部分： ...
复制链接

扫一扫