之前我们讨论过《Linux Oracle 11g dataguard物理standby 配置过程》,
但是在实际过程中会遇到不同的问题,首先我们讨论下ORACLE DATAGUARD的三种模式,
保护最大化:这种模式的配置可以保证主库和备库的同步,任何情况下主库的损毁都不会导致已提交数据的丢失。如果主库和备库之间的网络出现问题,或者备库本身出现问题,都会导致主库停止数据处理。
可用最大化:这种模式和上面一种类似,也是会保证主库和备库的同步,区别在于,当网络或备库不可用时,主库仍然可以继续处理。
性能最大化:主库和备库是异步的。这种模式可能在主库出现损毁时,丢失一部分数据。但是这种模式对主库负荷最小,因此具有最好的性能。
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中的一个特性:Oracle 11g物理Active Data Guard实时查询(Real-time query)功能,用以下方法实现
此过程只须在备库实现
1)查看备库当前状态
SQL> select open_mode from v$database; OPEN_MODE -------------------- MOUNTED 此时备库处于MOUNT状态。
2)取消备库的自动恢复
SQL> alter database recover managed standby database cancel; Database altered.
3)OPEN备库调整为“READ ONLY”状态
SQL> alter database open; Database altered. SQL> 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”的含义是当备库收到日志后,尽快完成恢复。 SQL> 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