本文只涉及Oracle9iR2 Data Guard的physical standby
一、三种保护模式
最大性能(maximize performance):这是data guard默认的保护模式。primay上的事务commit前不需要从standby上收到反⌒畔ⅰ8媚J皆趐rimary故障时可能丢失数据,但standby对primary的性能影响最小。
最大可用(maximize availability):在正常情况下,最大可用模式和最大保护模式一样;在standby不可用时,最大可用模式自动最大性能模式,所以standby故障不会导致primay不可用。只要至少有一个standby可用的情况下,即使primarydown机,也能保证不丢失数据。
最大保护(maximize protection):最高级别的保护模式。primay上的事务在commit前必须确认redo已经传递到至少一个standby上,如果所有standby不可用,则primary会挂起。该模式能保证零数据丢失。
二、查看当前保护模式
SQL> select DATABASE_ROLE,PROTECTION_MODE,PROTECTION_LEVEL from v$database;
DATABASE_ROLE PROTECTION_MODE PROTECTION_LEVEL
---------------- -------------------- --------------------
PRIMARY MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE
三、两种日志传输方式
Arch:传统的日志传送方式。现在只有在最大性能模式时才能采用。归档日志通过primary上的arch进程传送给standby的RFS进程。
LGWr:oracle9i开始可以使用LGWR即时将日志传送到standby,而不再需要等到归档操作时才传送,已减少可能的数据丢失。在三种保护模式下都可以使用该方式传送日志。使用LGWR方式传送,在standby必须先建立standby redo logfile
四、查看日志传送方式
SQL> select dest_name,archiver from v$archive_dest;
DEST_NAME ARCHIVER
-------------------- ----------
LOG_ARCHIVE_DEST_1 ARCH
LOG_ARCHIVE_DEST_2 LGWR
LOG_ARCHIVE_DEST_3 ARCH
LOG_ARCHIVE_DEST_4 ARCH
LOG_ARCHIVE_DEST_5 ARCH
LOG_ARCHIVE_DEST_6 ARCH
LOG_ARCHIVE_DEST_7 ARCH
LOG_ARCHIVE_DEST_8 ARCH
LOG_ARCHIVE_DEST_9 ARCH
LOG_ARCHIVE_DEST_10 ARCH
10 rows selected.
五、添加standby redo logfile
首先停止standby的自动恢复状态
SQL> alter database recover managed standby database finish;
Database altered.
如果没有停止自动恢复状态就添加standby logfile,会报错:
ORA-01156: recovery in progress may need access to files
SQL> alter database add standby logfile group 4 ('d:/oracle/oradata/test/standby
04.redo') size 10m;
Database altered.
SQL> alter database add standby logfile group 5 ('d:/oracle/oradata/test/standby
05.redo') size 10m;
Database altered.
SQL> alter database add standby logfile group 6 ('d:/oracle/oradata/test/standby
06.redo') size 10m;
Database altered.
注意standby logfile的group名不能和primary的redo logfile group重复,因为我的primay已经有3组日志了,这里添加的三组standby logfile从group 4开始。同时standby redo logfile的大小和primary的redo logfile保持一致。
六、设置standby的归档路径
log_archive_dest_1='location=d:/oracle/arch/test'
standby_archive_dest='d:/oracle/arch/test/standby'
七、在primary上修改为用LGWR传送日志
SQL> alter system set log_archive_dest_2='service=test lgwr async affirm';
System altered.
在primary上swith logfile
SQL> alter system switch logfile;
System altered.
在primary的alter中可以看到成功的记录
Thu Nov 23 12:41:28 2006
ALTER SYSTEM SET log_archive_dest_2='service=test lgwr async' SCOPE=BOTH;
Thu Nov 23 12:43:12 2006
******************************************************************
LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2
******************************************************************
Creating archive destination LOG_ARCHIVE_DEST_2: 'test'
LNS0 started with pid=13
Thu Nov 23 12:43:16 2006
LGWR: Beginning to archive log 3 thread 1 sequence 102
Thread 1 advanced to log sequence 102
Current log# 3 seq# 102 mem# 0: D:ORACLEORADATANINGREDO03.LOG
Thu Nov 23 12:43:16 2006
ARC0: Evaluating archive log 2 thread 1 sequence 101
ARC0: LGWR is actively archiving destination LOG_ARCHIVE_DEST_2
ARC0: Beginning to archive log 2 thread 1 sequence 101
Creating archive destination LOG_ARCHIVE_DEST_2: 'test'
Creating archive destination LOG_ARCHIVE_DEST_1: 'D:ORACLEARCHNINGARC00101.001'
ARC0: Completed archiving log 2 thread 1 sequence 101
八、切换standby的保护模式
切换保护模式的操作必须在primay执行,且primay必须处于mount状态
如果在open状态执行,则报错:
ORA-01126: database must be mounted EXCLUSIVE and not open for this operation
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 134814580 bytes
Fixed Size 453492 bytes
Variable Size 109051904 bytes
Database Buffers 25165824 bytes
Redo Buffers 143360 bytes
Database mounted.
SQL> alter database set standby database to maximize availability;
Database altered.
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-03113: end-of-file on communication channel
注意,这时需要先修改日志传送方式为lgwr同步方式,否则,数据库是无法open的
SQL> conn / as sysdba
Connected to an idle instance.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 134814580 bytes
Fixed Size 453492 bytes
Variable Size 109051904 bytes
Database Buffers 25165824 bytes
Redo Buffers 143360 bytes
Database mounted.
SQL> alter system set log_archive_dest_2='service=test lgwr sync';
System altered.
SQL> alter database open;
Database altered.
再来看看当前保护模式
SQL> select DATABASE_ROLE,PROTECTION_MODE,PROTECTION_LEVEL from v$database;
DATABASE_ROLE PROTECTION_MODE PROTECTION_LEVEL
---------------- -------------------- --------------------
PHYSICAL STANDBY MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY
切换成maximize protection也需要类似的步骤,这里就不演示了。
注:在10gR2的data guard中,按照上述步骤切换保护模式的时候却不成功。主库完成切换语句后再open就报错:ORA-03113: end-of-file on communication channel。看alert文件,只要是ORA-16072: a minimum of one standby database destination is required。但实际上备库的standby logfile都已经建好了,检查参数设置也查不出问题。
解决方法:将主备库的flashback打开:
启动到mount
SQL> select FLASHBACK_ON from v$database;
FLASHBACK_ON
------------------------------------
NO
SQL> alter database flashback on;
数据库已更改。
然后再切换到最大可用或者最大保护模式就ok了,切换前注意备库已经处于mount状态,并且主库原有的归档日志都已经全部复制到备库对应的归档目录下了,否则传送方式由arch改成lgwr后这些差异日志就无法自动传过去了。今天做10gR2备库的一个试验中,就是由于这个原因,导致切换成最大保护模式后,主库无法open,老是报错:ORA-03113: end-of-file on communication channel。查看alert日志里都是ORA-16072: a minimum of one standby database destination is required错误,这个错误有点让人纳闷,明明参数都是正确设置的,却报这么个错误。后来将主库的所有归档日志手动复制到备库后,启动正常。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/193161/viewspace-50235/,如需转载,请注明出处,否则将追究法律责任。