高可用之4——Data Guard 配置Standby Redo Log
2012-07-27 09:45
260 查看
转载:http://blog.itpub.net/35489/viewspace-672422
Data Guard在最大保护和最高可用性模式下,Standby数据库必须配置standby redo log,通过下面的实
验展示创建的原则和过程。
1.原则
1).standby redo log的文件大小与primary 数据库online redo log 文件大小相同
2).standby redo log日志文件组的个数依照下面的原则进行计算
Standby redo log组数公式>=(每个instance日志组个数+1)*instance个数
例如在我的环境中,只有一个节点,这个节点有三组redo,所以
Standby redo log组数公式>=(3+1)*1 == 4
所以需要创建4组Standby redo log
3).每一日志组为了安全起见,可以包含多个成员文件
2.配置过程,正常情况下仅需要在Standby端进行配置,考虑到主备切换,在primary端亦进行配置
1)Standby库添加四组Standby redo log,用户备库的恢复
sys@ora10g> alter database add standby logfile group 4
('/oracle/u02/ORA10GDG/STANDBYRD01.LOG') size 200M;
Database altered.
sys@ora10g> alter database add standby logfile group 5
('/oracle/u02/ORA10GDG/STANDBYRD02.LOG') size 200M;
Database altered.
sys@ora10g> alter database add standby logfile group 6
('/oracle/u02/ORA10GDG/STANDBYRD03.LOG') size 200M;
Database altered.
sys@ora10g> alter database add standby logfile group 7
('/oracle/u02/ORA10GDG/STANDBYRD04.LOG') size 200M;
Database altered.
2)Primary库添加四组Standby redo log,用于主备切换
sys@ora10g> alter database add standby logfile group 4
('/oracle/u02/ORA10G/STANDBYRD01.LOG') size 200M;
Database altered.
sys@ora10g> alter database add standby logfile group 5
('/oracle/u02/ORA10G/STANDBYRD02.LOG') size 200M;
Database altered.
sys@ora10g> alter database add standby logfile group 6
('/oracle/u02/ORA10G/STANDBYRD03.LOG') size 200M;
Database altered.
sys@ora10g> alter database add standby logfile group 7
('/oracle/u02/ORA10G/STANDBYRD04.LOG') size 200M;
Database altered.
3.Standby redo log删除方法
sys@ora10g> alter database drop standby logfile group 4;
sys@ora10g> alter database drop standby logfile group 5;
sys@ora10g> alter database drop standby logfile group 6;
sys@ora10g> alter database drop standby logfile group 7;
4.通过V$STANDBY_LOG视图验证standby redo log文件组是否成功创建
sys@ora10g> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG;
GROUP# THREAD# SEQUENCE# ARC STATUS
---------- ---------- ---------- --- ----------
4 0 0 YES UNASSIGNED
5 0 0 YES UNASSIGNED
6 0 0 YES UNASSIGNED
7 0 0 YES UNASSIGNED
Question:
In Data Guard, why do we need standby redo log files? Should the the primary redo log files be enough?
Answer: A
standby redo log resides on the standby database site. The standby redo log file is similar to an online redo log, except that a standby redo log is used to store redo data that has been received from a primary database.
Oracle Data Guard used to have the onerous(严重的) problem of loosing the last redo log. If the primary instanced crashed, the "current" redo log (as written by
the LGWR process) would need to be flushed (with a log switch) before the most recent changes could be applied to the standby database. If you could not flush the current redo, data could be lost forever.
Also see these important notes on LNS
log transport waits.
allowing complete recovery in cases of catastrophic(灾难性的) instance failure.
Note: The standby redo logs are populated with redo information as fast as the primary redo logs, rather than waiting for the redo log to be archived and shipped to the standby database. This means that the standby redo log has more
current information than the log apply mechanism because it took a "shortcut" and was written to the standby, bypassing the traditional archiving and FTP to the standby database.
The Oracle documentation notes three Data Guard Protection Modes. The Maximum protection mode offers redo synchronization:
Maximum Protection?This mode offers the highest level of data protection. Data is synchronously transmitted to the standby database from the primary database and transactions are
not committed on the primary database unless the redo data is available on at least one standby database configured in this mode. If the last standby database configured in this mode becomes unavailable, processing stops on the primary database. This mode
ensures no-data-loss.
Maximum Availability?This mode is similar to the maximum protection mode, including zero data loss. However, if a standby database becomes unavailable (for example, because of network connectivity problems), processing continues on the primary
database. When the fault is corrected, the standby database is automatically resynchronized with the primary database.
Maximum Performance?This mode offers slightly less data protection on the primary database, but higher performance than maximum availability mode. In this mode, as the primary database processes transactions, redo data is asynchronously shipped
to the standby database. The commit operation of the primary database does not wait for the standby database to acknowledge receipt of redo data before completing write operations on the primary database. If any standby destination becomes unavailable, processing
continues on the primary database and there is little effect on primary database performance.
Redo Transmission" uses a new background process called LNSn:
Asynchronous redo transmission using the log writer process (LGWR ASYNC) has been improved to reduce the performance impact on the primary database. During asynchronous redo transmission, the network
server (LNSn) process transmits redo data out of the online redo log files on the primary database and no longer interacts directly with the log writer process.
This change in behavior allows the log writer process to write redo data to the current online redo log file and continue processing the next request without waiting for inter-process communication or network I/O to complete.
Data Guard在最大保护和最高可用性模式下,Standby数据库必须配置standby redo log,通过下面的实
验展示创建的原则和过程。
1.原则
1).standby redo log的文件大小与primary 数据库online redo log 文件大小相同
2).standby redo log日志文件组的个数依照下面的原则进行计算
Standby redo log组数公式>=(每个instance日志组个数+1)*instance个数
例如在我的环境中,只有一个节点,这个节点有三组redo,所以
Standby redo log组数公式>=(3+1)*1 == 4
所以需要创建4组Standby redo log
3).每一日志组为了安全起见,可以包含多个成员文件
2.配置过程,正常情况下仅需要在Standby端进行配置,考虑到主备切换,在primary端亦进行配置
1)Standby库添加四组Standby redo log,用户备库的恢复
sys@ora10g> alter database add standby logfile group 4
('/oracle/u02/ORA10GDG/STANDBYRD01.LOG') size 200M;
Database altered.
sys@ora10g> alter database add standby logfile group 5
('/oracle/u02/ORA10GDG/STANDBYRD02.LOG') size 200M;
Database altered.
sys@ora10g> alter database add standby logfile group 6
('/oracle/u02/ORA10GDG/STANDBYRD03.LOG') size 200M;
Database altered.
sys@ora10g> alter database add standby logfile group 7
('/oracle/u02/ORA10GDG/STANDBYRD04.LOG') size 200M;
Database altered.
2)Primary库添加四组Standby redo log,用于主备切换
sys@ora10g> alter database add standby logfile group 4
('/oracle/u02/ORA10G/STANDBYRD01.LOG') size 200M;
Database altered.
sys@ora10g> alter database add standby logfile group 5
('/oracle/u02/ORA10G/STANDBYRD02.LOG') size 200M;
Database altered.
sys@ora10g> alter database add standby logfile group 6
('/oracle/u02/ORA10G/STANDBYRD03.LOG') size 200M;
Database altered.
sys@ora10g> alter database add standby logfile group 7
('/oracle/u02/ORA10G/STANDBYRD04.LOG') size 200M;
Database altered.
3.Standby redo log删除方法
sys@ora10g> alter database drop standby logfile group 4;
sys@ora10g> alter database drop standby logfile group 5;
sys@ora10g> alter database drop standby logfile group 6;
sys@ora10g> alter database drop standby logfile group 7;
4.通过V$STANDBY_LOG视图验证standby redo log文件组是否成功创建
sys@ora10g> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG;
GROUP# THREAD# SEQUENCE# ARC STATUS
---------- ---------- ---------- --- ----------
4 0 0 YES UNASSIGNED
5 0 0 YES UNASSIGNED
6 0 0 YES UNASSIGNED
7 0 0 YES UNASSIGNED
Question:
In Data Guard, why do we need standby redo log files? Should the the primary redo log files be enough?
Answer: A
standby redo log resides on the standby database site. The standby redo log file is similar to an online redo log, except that a standby redo log is used to store redo data that has been received from a primary database.
Oracle Data Guard used to have the onerous(严重的) problem of loosing the last redo log. If the primary instanced crashed, the "current" redo log (as written by
the LGWR process) would need to be flushed (with a log switch) before the most recent changes could be applied to the standby database. If you could not flush the current redo, data could be lost forever.
Also see these important notes on LNS
log transport waits.
Standby Redo Logs
In Oracle 10g and beyond we see an exciting new approach to Data Guard management whereby we write the current redo log to a "standby redo log",allowing complete recovery in cases of catastrophic(灾难性的) instance failure.
Note: The standby redo logs are populated with redo information as fast as the primary redo logs, rather than waiting for the redo log to be archived and shipped to the standby database. This means that the standby redo log has more
current information than the log apply mechanism because it took a "shortcut" and was written to the standby, bypassing the traditional archiving and FTP to the standby database.
The Oracle documentation notes three Data Guard Protection Modes. The Maximum protection mode offers redo synchronization:
Maximum Protection?This mode offers the highest level of data protection. Data is synchronously transmitted to the standby database from the primary database and transactions are
not committed on the primary database unless the redo data is available on at least one standby database configured in this mode. If the last standby database configured in this mode becomes unavailable, processing stops on the primary database. This mode
ensures no-data-loss.
Maximum Availability?This mode is similar to the maximum protection mode, including zero data loss. However, if a standby database becomes unavailable (for example, because of network connectivity problems), processing continues on the primary
database. When the fault is corrected, the standby database is automatically resynchronized with the primary database.
Maximum Performance?This mode offers slightly less data protection on the primary database, but higher performance than maximum availability mode. In this mode, as the primary database processes transactions, redo data is asynchronously shipped
to the standby database. The commit operation of the primary database does not wait for the standby database to acknowledge receipt of redo data before completing write operations on the primary database. If any standby destination becomes unavailable, processing
continues on the primary database and there is little effect on primary database performance.
Asynchronous redo transmission
We see more about the standby redo log mode in the 10g r2 docs where a new feature called "AsynchronousRedo Transmission" uses a new background process called LNSn:
Asynchronous redo transmission using the log writer process (LGWR ASYNC) has been improved to reduce the performance impact on the primary database. During asynchronous redo transmission, the network
server (LNSn) process transmits redo data out of the online redo log files on the primary database and no longer interacts directly with the log writer process.
This change in behavior allows the log writer process to write redo data to the current online redo log file and continue processing the next request without waiting for inter-process communication or network I/O to complete.
相关文章推荐
- 配置standby redo log
- Data Guard 配置 Standby Redo Log
- 配置standby redo log
- Data Guard 环境下 主备库Redo log 的添加与删除
- Data Guard 环境下 主备库Redo log 的添加与删除
- Oracle Data Guard 单实例到单实例配置(物理standby)
- Oracle 10g 单实例数据库 Data Guard 之 Physical Standby 配置详解(根据官方文档总结)
- 关于Online Redo Log(ORL)和Standby Redo Log(SRL)的个人理解
- 配置RAC到单节点standby的data guard
- DataGuard standby redo log 管理
- Standby Redo Log 的设定原则、创建、删除、查看、归档位置
- 配置并使用Redo Log Buffer
- Standby Redo Log 的设定原则、创建、删除、查看、归档位置
- Data Guard学习物理standby REDO传输服务
- ORACLE Redo Log 及LOGMNR配置使用
- Data Guard 环境下 主备库Redo log 的添加与删除
- 主库配置关于Dataguard Online redo log 和 Standby redo log
- 关于Online Redo Log(ORL)和Standby Redo Log(SRL)的个人理解
- 高可用,高性能,线程安全,自动数据恢复 redo log 类
- Data Guard 环境下主备库Redo log 的添加与删除