之前我们讨论过《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保护模式
|
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
|
[root@nod1 ~]# imp system/wolf@nod1 fromuser=kiss touser=kiss file=kiss.DMP ignore=y log=kiss.log
|