Oracle 11g dataguard三种模式以及实时查询（Real-time query）功能设置

321312

之前我们讨论过《Linux Oracle 11g dataguard物理standby 配置过程》，

但是在实际过程中会遇到不同的问题，首先我们讨论下ＯＲＡＣＬＥ　ＤＡＴＡＧＵＡＲＤ的三种模式，

保护最大化：这种模式的配置可以保证主库和备库的同步，任何情况下主库的损毁都不会导致已提交数据的丢失。如果主库和备库之间的网络出现问题，或者备库本身出现问题，都会导致主库停止数据处理。

可用最大化：这种模式和上面一种类似，也是会保证主库和备库的同步，区别在于，当网络或备库不可用时，主库仍然可以继续处理。

性能最大化：主库和备库是异步的。这种模式可能在主库出现损毁时，丢失一部分数据。但是这种模式对主库负荷最小，因此具有最好的性能。

1.最大保护模式：(如果采用这种模式，最好能建立多个standby database，以确保日志能够至少归档到一台备用机上，减少down机的机会。)
1).这种模式提供了最高级别的数据保护能力
2).重做日志在至少一个物理从库[url=]数据库[/url]后，主库的事务才能够提交
3).主库找不到合适的从库写入时，主库会自动关闭，防止无保护的数据出现
4).优点：该模式可以保证从库没有数据丢失
5).缺点：主库的自动关闭会影响到主库的可用性，同时需要从库恢复后才能提交，对网络等客观条件要求非常的高，主库的性能会受到非常大的影响。

2.最大可用性模式：(如果只有一台standby，又不想有数据丢失的话，推荐采用这种模式。)
1).这种模式提供了仅次于“最大保护模式”的数据保护能力
2).重做日志在至少一个物理从库数据库后，主库的事务才能够提交
3).主库找不到合适的从库写入时，主库不会关闭，而是临时降低到“最大性能模式”模式，直到问题得到处理
4).优点：该模式可以在没有问题出现的情况下保证从库没有数据丢失，是一种折中的方法
5).缺点：在正常运行的过程中缺点是主库的性能收到诸多因素的影响

3.最大性能模式：
1).默认模式，提供主数据库的最高可用性
2).保证主库运行过程中不受从库的影响，主库事务正常提交，不因从库的任何问题影响到主库的运行
4).优点：避免了从库对主数据库的性能和可用性影响
5).缺点：如果与主库提交的事务相关的恢复数据没有发送到从库，这些事务数据将被丢失，不能保证数据无损失

可以选择适合自己合适的模式进行配置，在这里我们选择更改模式为Protection

打开主库，修改主库DataGuard保护模式

1 2 3 4 5 6 7 8 9 10 11

SQL> shutdown immediate     SQL> startup mount     SQL> select name,db_unique_name,protection_mode from v$database;     NAME DB_UNIQUE_NAME PROTECTION_MODE     ----- --------------- --------------------     ORCL orcl            MAXIMUM PERFORMANCE     SQL> alter database set standby database to maximize protection;

切换主库保护模式的语法：

1	ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE }

打开主库到OPEN状态，监控alert日志文件，查看是否配置成功。

有实际切换中可能会遇到若干问题,如本人在切换过程中日志报以下错误,主数据不能OPEN

错误日志:

LGWR: Minimum of 1 synchronous standby database required

Errors in file /oracle/app/oracle/diag/rdbms/nod1/test/trace/test_lgwr_7255.trc:

ORA-16072: a minimum of one standby database destination is required

Errors in file /oracle/app/oracle/diag/rdbms/nod1/test/trace/test_lgwr_7255.trc:

ORA-16072: a minimum of one standby database destination is required

解决方法如下:

1 2 3 4 5 6 7 8 9 10 11 12 13 14

SQL> conn /as sysdba SQL>startup mount; SQL> alter database set standby database to maximize protection; SQL>alter system set log_archive_dest_2='SERVICE=nod2 LGWR SYNC AFFIRM NET_TIMEOUT=120 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=nod2'  ; SQL> alter database open; Database altered. SQL> select name,db_unique_name,protection_mode from v$database; NAME      DB_UNIQUE_NAME                 PROTECTION_MODE --------- ------------------------------ -------------------- TEST    nod1                           MAXIMUM PROTECTION

在实际运行中又有一个问题，就是发现日志恢复不能实时到备库，能不能在日志恢复的同时可以用只读的方式打开数据库，这就不得不提到ＯＲＡＣＬＥ　１１Ｇ中的一个特性：Oracle 11g物理Active Data Guard实时查询（Real-time query）功能，用以下方法实现

此过程只须在备库实现

1）查看备库当前状态

1 2 3 4 5 6 7

ＳＱＬ> select open_mode from v$database; OPEN_MODE -------------------- MOUNTED 此时备库处于MOUNT状态。

2）取消备库的自动恢复

1 2 3

ＳＱＬ> alter database recover managed standby database cancel; Database altered.

3）OPEN备库调整为“READ ONLY”状态

1 2 3 4 5 6 7 8 9

ＳＱＬ> alter database open; Database altered. ＳＱＬ> select open_mode from v$database; OPEN_MODE -------------------- READ ONLY

4）在“READ ONLY”状态下进一步启动备库的恢复

1 2 3 4 5 6 7 8 9 10 11

sys@ora11gdg@> alter database recover managed standby database using current logfile disconnect; Database altered. 选项“USING CURRENT LOGFILE”的含义是当备库收到日志后，尽快完成恢复。 ＳＱＬ> select open_mode from v$database; OPEN_MODE -------------------- READ ONLY WITH APPLY

状态“READ ONLY WITH APPLY”即表示此时备库处于Read Only状态的同时可以接受主库传过来的日志进行恢复，以便达到备库可以即时查看到主库变化的目的。

　　测试过程过程比较简单，我们在主库导入一个数据表，然后会看到在备库几乎没有什么延迟就过去了，

1	[iyunv@nod1 ~]# imp system/wolf@nod1 fromuser=kiss touser=kiss file=kiss.DMP ignore=y log=kiss.log