点击打开链接
探索Oracle11gR2 之 DataGuard_03 三种保护模式
作者：吴伟龙
Oracle的DataGuard技术有三种实现模式，分别是max performance、max availability、maxprotection这三种模式。
以下是来自Oracle文档的摘要信息：
In some situations, a business cannot afford to lose data. In other situations,the availability of the database may be more important than the loss of data.Some applications require maximum database performance and can tolerate somesmall amount of data loss. The following descriptions summarize the threedistinct modes of data protection.
Maximum protection This protection mode ensuresthat no data loss will occur if the primary database fails. To provide thislevel of protection, the redo data needed to recover each transaction must bewritten to both the local online redo log and to the standby redo log on atleast one standby database before the transaction commits. To ensure data losscannot occur, the primary database shuts down if a fault prevents it fromwriting its redo stream to the standby redo log of at least one transactionallyconsistent standby database.
Maximum availability Thisprotection mode provides the highest level of data protection that is possiblewithout compromising the availability of the primary database. Like maximumprotection mode, a transaction will not commit until the redo needed to recoverthat transaction is written to the local online redo log and to the standbyredo log of at least one transactionally consistent standby database. Unlikemaximum protection mode, the primary database does not shut down if a faultprevents it from writing its redo stream to a remote standby redo log. Instead,the primary database operates in maximum performance mode until the fault iscorrected, and all gaps in redo log files are resolved. When all gaps areresolved, the primary database automatically resumes operating in maximumavailability mode.
This mode ensures that no data loss will occur if the primarydatabase fails, but only if a second fault does not prevent a complete set ofredo data from being sent from the primary database to at least one standbydatabase.
Maximum performance This protection mode (thedefault) provides the highest level of data protection that is possible withoutaffecting the performance of the primary database. This is accomplished by allowinga transaction to commit as soon as the redo data needed to recover thattransaction is written to the local online redo log. The primary database'sredo data stream is also written to at least one standby database, but thatredo stream is written asynchronously with respect to the transactions thatcreate the redo data.
When network links with sufficient bandwidth are used, this modeprovides a level of data protection that approaches that of maximumavailability mode with minimal impact on primary database performance.
The maximum protection and maximum availability modes requirethat standby redo log files are configured on at least one standby database inthe configuration. All three protection modes require that specific logtransport attributes be specified on the LOG_ARCHIVE_DEST_n initializationparameter to send redo data to at least one standby database. See Section 5.6for complete information about the data protection modes.
以下是对以上摘要信息的翻译信息：
在一些情况下，业务不允许丢失数据。在另外一些情况下，数据库的可用性比丢失数据更为重要。一些应用需要最强的数据库性能并且能容忍丢失少量的数据。下面的描述概述了三种不同的数据保护模式。
最大保护模式 -- 这种保护模式确保如果主数据库故障不会发生数据丢失。要提供这种级别的保护，恢复每个事务所需的重做数据必须在事务提交之前同时写到本地联机重做日志和至少一个备数据库上的备重做日志。要确保不发生数据丢失，如果故障导致主数据库无法写重做流到至少一个事务一致性备数据库的备重做日志时，主数据库会关闭。
最大可用性模式 -- 这种保护模式提供了可能的最高级别的数据保护，而不用与主数据库的可用性相折衷。与最大保护模式相同，在恢复事务所需的重做写到本地联机重做日志和至少一个事务一致性备数据库上的备重做日志之前，事务将不会提交。与最大保护模式不同的是，如果故障导致主数据库无法写重做流到异地备重做日志时，主数据库不会关闭。替代地，主数据库以最大性能模式运行直到故障消除，并且解决所有重做日志文件中的中断。当所有中断解决之后，主数据库自动继续以最大可用性模式运行。
这种模式确保如果主数据库故障，但是只有当第二次故障没有阻止完整的重做数据集从主数据库发送到至少一个备数据库时，不发生数据丢失。
最大性能模式 -- 这种保护模式（默认）提供了可能的最高级别的数据保护，而不影响主数据库的性能。这是通过允许事务在恢复该事务所需重做数据在写到本地联机重做日志后立即提交而实现的。主数据库的重做数据流也写到至少一个备数据库，但是那个重做流相对于创建重做数据的事务是异步写的。
当所用的网络连接有足够的带宽，这种模式提供了近似于最大可用性模式的数据保护级别，并且对主数据库性能的影响最小。
最大保护和最大可用性模式需要备重做日志文件配置在配置中的至少一个备数据库上。所有三种保护模式需要在LOG_ARCHIVE_DEST_n 初始化参数上指定特定的日志传输属性以发送重做数据到至少一个备数据库。查看5.6 节以获得数据保护模式的完整信息。
实验过程:
DG在最大性能模式MAXIMUM PERFORMANCE
- SQL> select protection_mode,protection_level from v$database;
-
- PROTECTION_MODE PROTECTION_LEVEL
-
- MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE
-
- SQL> select * from tab;
-
- TNAME TABTYPE CLUSTERID
-
- BONUS TABLE
- DEPT TABLE
- EMP TABLE
- SALGRADE TABLE
-
- SQL> create table emp001 as select *from emp; 创建了一张表emp001
-
- Table created.
-
- SQL> select * from tab;
-
- TNAME TABTYPE CLUSTERID
-
- BONUS TABLE
- DEPT TABLE
- EMP TABLE
- EMP001 TABLE
- SALGRADE TABLE
去备机上查看，这张表并没有出现：
- SQL> select * from tab;
-
- TNAME TABTYPE CLUSTERID
-
- BONUS TABLE
- DEPT TABLE
- EMP TABLE
- SALGRADE TABLE
- 这个时候，我需要在主库上执行一次日志切换：
- SQL> alter system switch logfile;
-
- System altered.
-
- 再备库上再次查询，表已经出来：
- SQL> /
-
- TNAME TABTYPE CLUSTERID
-
- BONUS TABLE
- DEPT TABLE
- EMP TABLE
- EMP001 TABLE
- SALGRADE TABLE
DG在最大可用性模式Maximum availability
Primary端操作
- 修改初始化参数
- SQL> alter system set log_archive_dest_2='SERVICE=sty OPTIONAL LGWR SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)DB_UNIQUE_NAME=sty';
-
- System altered.
-
- SQL> show parameter log_archive_dest_2
-
- NAME TYPE VALUE
-
- log_archive_dest_2 string SERVICE=sty OPTIONAL LGWR SYNC
- AFFIRM VALID_FOR=(ONLINE_LOGF
- ILES,PRIMARY_ROLE) DB_UNIQUE_N
- AME=sty
- SQL> startup mount;
- ORACLE instance started.
-
- Total System Global Area 839282688 bytes
- Fixed Size 2217992 bytes
- Variable Size 549455864 bytes
- Database Buffers 285212672 bytes
- Redo Buffers 2396160 bytes
- Database mounted.
-
- SQL> alter database set standby databaseto maximize availability;
-
- Database altered.
提示：
maximize
后可跟
{PROTECTION | AVAILABILITY | PERFORMANCE}
，分别对应最大保护，最高可用性及最高性能。
Down掉数据库，重新启动
- SQL> alter database open;
-
- Database altered.
-
- 看一下当前的保护模式
- SQL> select protection_mode,protection_level from v$database;
-
- PROTECTION_MODE PROTECTION_LEVEL
-
- MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY
-
- SQL>
Standby端操作
- SQL> alter system set log_archive_dest_2='SERVICE=pri OPTIONAL LGWR SYNCAFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=pri';
-
- System altered.
-
- SQL> show parameter log_archive_dest_2
-
- NAME TYPE VALUE
-
- log_archive_dest_2 string SERVICE=pri OPTIONAL LGWR SYNC
- AFFIRM VALID_FOR=(ONLINE_LOGF
- ILES,PRIMARY_ROLE)DB_UNIQUE_N
- AME=pri
-
- SQL> selectprotection_mode,protection_level from v$database;
-
- PROTECTION_MODE PROTECTION_LEVEL
-
- MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY
-
- SQL>
这样就已经配置完成了。
我们现在停掉standby数据库，再看看primary数据库状态
- SQL> shutdown immediate
- Database closed.
- Database dismounted.
- ORACLE instance shut down.
-
- SQL> selectprotection_mode,protection_level,name from v$database;
-
- PROTECTION_MODE PROTECTION_LEVEL NAME
-
- MAXIMUM AVAILABILITY RESYNCHRONIZATION WOO
Standby
数据库
shutdown
后，
primary
数据库保护级别切换为待同步。
启备机器后，一会儿就好了：
- SQL> startup
- ORACLE instance started.
-
- Total System Global Area 839282688 bytes
- Fixed Size 2217992 bytes
- Variable Size 507512824 bytes
- Database Buffers 327155712 bytes
- Redo Buffers 2396160 bytes
- Database mounted.
- Database opened.
- SQL> selectprotection_mode,protection_level,name from v$database;
-
- PROTECTION_MODE PROTECTION_LEVEL NAME
-
- MAXIMUM AVAILABILITY RESYNCHRONIZATION WOO
-
- SQL> selectprotection_mode,protection_level,name from v$database;
-
- PROTECTION_MODE PROTECTION_LEVEL NAME
-
- MAXIMUM AVAILABILITY MAXIMUM AVAILABILITYWOO
-
- SQL>
再查看下主库状态：
- SQL> selectprotection_mode,protection_level,name from v$database;
-
- PROTECTION_MODE PROTECTION_LEVEL NAME
-
- MAXIMUM AVAILABILITY MAXIMUM AVAILABILITYWOO
测试:
在primary 执行创建表
查看当前表的数量
- SQL> select * from tab;
-
- TNAME TABTYPE CLUSTERID
-
- BONUS TABLE
- DEPT TABLE
- EMP TABLE
- EMP001 TABLE
- EMP003 TABLE
- SALGRADE TABLE
-
- 6 rows selected.
删除emp003表
- SQL> drop table emp003 purge;
-
- Table dropped.
创建emp004表
- SQL> create table emp004 as select *from emp001;
-
- Table created.
查看emp003表已经被删除，emp004表被创建成功。
- SQL> select * from tab;
-
- TNAME TABTYPE CLUSTERID
-
- BONUS TABLE
- DEPT TABLE
- EMP TABLE
- EMP001 TABLE
- EMP004 TABLE
- SALGRADE TABLE
-
- 6 rows selected.
备库上数据直接就可以过来了：
查询到数据和第一次pry数据库一致：
- SQL> select * from tab;
-
- TNAME TABTYPE CLUSTERID
-
- BONUS TABLE
- DEPT TABLE
- EMP TABLE
- EMP001 TABLE
- EMP003 TABLE
- SALGRADE TABLE
-
- 6 rows selected.
在pri端删除emp003后，可以看到在sty端也随即删除。
- SQL> select * from tab;
-
- TNAME TABTYPE CLUSTERID
-
- BONUS TABLE
- DEPT TABLE
- EMP TABLE
- EMP001 TABLE
- SALGRADE TABLE
在pri端创建emp004后，在sty端也随即实时创建。
- SQL> select * from tab;
-
- TNAME TABTYPE CLUSTERID
-
- BONUS TABLE
- DEPT TABLE
- EMP TABLE
- EMP001 TABLE
- EMP004 TABLE
- SALGRADE TABLE
-
- 6 rows selected.
-
- SQL>
实验二，在maximum availability 模式下关闭standby端，在主库执行DML操作后起备库，是否会有数据丢失:
1、 关闭standby端:
- [root@sty ~]# shutdown -h now
-
- Broadcast message from root (pts/1) (TueMay 21 02:09:34 2013):
-
- The system is going down for system haltNOW!
- [root@sty ~]#
-
2、 查看主库这个时候的状态，已经检测到了standby失败
- SQL> selectname,open_mode,database_role,protection_mode,SWITCHOVER_STATUS From v$database;
-
- NAME OPEN_MODE DATABASE_ROLE PROTECTION_MODE SWITCHOVER_STATUS
-
- WOO READ WRITE PRIMARY MAXIMUM AVAILABILITY FAILEDDESTINATION
-
- SQL>
3、 这个时候我们删除emp004及创建emp005
- SQL> select * from tab;
-
- TNAME TABTYPE CLUSTERID
-
- BONUS TABLE
- DEPT TABLE
- EMP TABLE
- EMP001 TABLE
- EMP004 TABLE
- SALGRADE TABLE
-
- 6 rows selected.
-
- SQL> drop table emp004 purge;
-
- Table dropped.
-
- SQL> create table emp005 as select *from emp001;
-
- Table created.
-
- SQL> select * from tab;
-
- TNAME TABTYPE CLUSTERID
-
- BONUS TABLE
- DEPT TABLE
- EMP TABLE
- EMP001 TABLE
- EMP005 TABLE
- SALGRADE TABLE
-
- 6 rows selected.
-
4、 把sty服务器启起来，open数据库：
打开备库后，我们可以看到，standby现在正在应用日志：
- SQL> select process, status fromv$managed_standby;
-
- PROCESS STATUS
-
- ARCH CLOSING
- ARCH CLOSING
- ARCH CONNECTED
- ARCH CLOSING
- RFS IDLE
- RFS IDLE
- RFS IDLE
- MRP0 APPLYING_LOG
-
过一会儿，我们再查询，发现standby 端宕机过程中primary端数据库的改变也同样通过日志更新过来了。
- SQL> select * from tab;
-
- TNAME TABTYPE CLUSTERID
-
- BONUS TABLE
- DEPT TABLE
- EMP TABLE
- EMP001 TABLE
- EMP005 TABLE
- SALGRADE TABLE
-
- 6 rows selected.
我们通过这个实验可以看出，将DataGuard配置为Maximumavailability模式后，pri数据是实时同步到sty端。
DG最大保护模式Maximum protection
1、将主库修改为最大保护模式
- 先关闭主库
- SQL>shutdown immediate
- Databaseclosed.
- Databasedismounted.
- ORACLEinstance shut down.
- 启动到mount状态
- SQL>startup mount;
- ORACLEinstance started.
-
- TotalSystem Global Area 839282688 bytes
- FixedSize 2217992 bytes
- VariableSize 557844472 bytes
- DatabaseBuffers 276824064 bytes
- RedoBuffers 2396160 bytes
- Databasemounted.
-
- 修改为最大保护模式
- SQL>alter database set standby database to maximize protection;
-
- Databasealtered.
-
- Open数据库
- SQL>alter database open;
-
- Databasealtered.
-
Primary端查询状态：
- SQL>select name,open_mode,database_role,protection_mode,SWITCHOVER_STATUS From v$database;
-
- NAME OPEN_MODE DATABASE_ROLE PROTECTION_MODE SWITCHOVER_STATUS
-
- WOO READ WRITE PRIMARY MAXIMUM PROTECTION TO STANDBY
Standby端查询状态（切换只需要操作主库，备库不需要动即可）
- SQL>select name,open_mode,database_role,protection_mode,SWITCHOVER_STATUS From v$database;
-
- NAME OPEN_MODE DATABASE_ROLE PROTECTION_MODE SWITCHOVER_STATUS
-
- WOO READ ONLY WITH APPLY PHYSICAL STANDBYMAXIMUM PROTECTION NOT ALLOWED
-
我们现在可以看到，primary和standby端现在都为Maximumprotection 最大保护模式。
实验
先查看当前的表
- SQL> select * from tab;
-
- TNAME TABTYPE CLUSTERID
-
- BONUS TABLE
- DEPT TABLE
- EMP TABLE
- EMP001 TABLE
- EMP005 TABLE
- SALGRADE TABLE
-
- 6 rows selected.
我们删除emp005以及创建emp006表
- SQL> drop table emp005 purge;
-
- Table dropped.
-
- SQL> create table emp006 as select* from emp001;
-
- Table created.
-
我们可以看到emp005已经被删除，并且emp006表也被创建好了。
- SQL> select * from tab;
-
- TNAME TABTYPE CLUSTERID
-
- BONUS TABLE
- DEPT TABLE
- EMP TABLE
- EMP001 TABLE
- EMP006 TABLE
- SALGRADE TABLE
-
- 6 rows selected.
-
- SQL>
现在看standby端，我们可以发现如下
两边的表是一样的
- SQL> select * from tab;
-
- TNAME TABTYPE CLUSTERID
-
- BONUS TABLE
- DEPT TABLE
- EMP TABLE
- EMP001 TABLE
- EMP005 TABLE
- SALGRADE TABLE
-
- 6 rows selected.
在主库端删除的emp005及新创建的emp006也实时同步过来了
- SQL> select * from tab;
-
- TNAME TABTYPE CLUSTERID
-
- BONUS TABLE
- DEPT TABLE
- EMP TABLE
- EMP001 TABLE
- EMP006 TABLE
- SALGRADE TABLE
-
- 6 rows selected.
-
- SQL>
我现在关闭sty端服务器：
- [root@sty ~]# shutdown -h now
-
- Broadcast message from root (pts/1)(Tue May 21 03:14:28 2013):
-
- The system is going down for systemhalt NOW!
-
返回来看主库的状态:
日志传输以及终止了:
- Log Transport Services Error ORA-16198: LGWR received timedout error from KSR
- Log Transport Services Error Error 12543 received logging on to the standby
- Log Transport Services Error LGWR: Error 12543 attaching to RFS for reconnect
- Log Transport Services Error Error 12543 received logging on to the standby
- Log Transport Services Error LGWR: Error 12543 attaching to RFS for reconnect
-
一段时间之后，primary端也宕机了：
- SQL> selectname,open_mode,database_role,protection_mode,SWITCHOVER_STATUS From v$database;
-
- NAME OPEN_MODE DATABASE_ROLE PROTECTION_MODE SWITCHOVER_STATUS
-
- WOO READWRITE PRIMARY MAXIMUM PROTECTION TO STANDBY
-
- SQL> selectname,open_mode,database_role,protection_mode,SWITCHOVER_STATUS From v$database;
- selectname,open_mode,database_role,protection_mode,SWITCHOVER_STATUS From v$database
- *
- ERROR at line 1:
- ORA-03135: connection lost contact
- Process ID: 8386
- Session ID: 39 Serial number: 5
这个时候需要把standby端起来，primary端，数据库才能起来。
- SQL> startup mount;
- ORACLE instance started.
-
- Total System Global Area 839282688 bytes
- Fixed Size 2217992 bytes
- Variable Size 507512824 bytes
- Database Buffers 327155712 bytes
- Redo Buffers 2396160 bytes
- Database mounted.
停止redo应用
- SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASECANCEL;
- Database altered.
Open数据库
- SQL> alter database open;
-
- Database altered.
开启redo应用
- SQL> ALTER DATABASE RECOVER MANAGEDSTANDBY DATABASE DISCONNECT FROM SESSION;
-
- Database altered.
Database altered.再启主库
- SQL> startup
- ORACLE instance started.
-
- Total System Global Area 839282688 bytes
- Fixed Size 2217992 bytes
- Variable Size 507512824 bytes
- Database Buffers 327155712 bytes
- Redo Buffers 2396160 bytes
- Database mounted.
- Database opened.
最后我们一块来看一个表格，一目了然的清楚DG三种模式的区别：
| | 最大保护模式 | 最大可用 | 最大性能 |
| 进程 | LGWR | LGWR | LGWR或ARCH |
| 网络传输模式 | SYNC | SYNC | LGWR时设置SYNC |
| 磁盘写操作 | AFFIRM | AFFIRM | NOAFFIRM |
| 备用日志 | Yes | Phycal 备库需要 | LGWR和物理需要 |
| 备用库类型 | Phycal mode | Phycal and logical | Phycal and logical
|
扫一扫
1207
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
