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

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

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

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

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

 

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

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

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

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

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

 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;

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

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

解决方法如下:

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）查看备库当前状态

ＳＱＬ> select open_mode from v$database;

OPEN_MODE
--------------------
MOUNTED

此时备库处于MOUNT状态。

2）取消备库的自动恢复

ＳＱＬ> alter database recover managed standby database cancel;

Database altered.

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

ＳＱＬ> alter database open;

Database altered.

ＳＱＬ> select open_mode from v$database;

OPEN_MODE
--------------------
READ ONLY

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

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状态的同时可以接受主库传过来的日志进行恢复，以便达到备库可以即时查看到主库变化的目的。

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

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