Loading
1

11gR2 Active Data Guard 、Snapshot Standby Database 的创建及使用

 

Oracle的Data Guard 从11gR2开始,在原先10g版本Physical Standby和Logical Standby的基础上加入了Active Dataguard和Snapshot Standby两个新特性,Active Dataguard使得原先只能处于mount状态apply redo日志的Physical Standby可以以READ ONLY模式打开数据库并且实时的apply redo日志,这种模式提供了Real-Time Query,即用户可以在Physical Standby上实时查询主库上的数据,这有点类似于Logical Standby不只做备份,还可以实时查询生成报表使用。而Snapshot Standby则使得Physical Standby可以以READ WRITE模式打开数据库,在切换到Snapshot Standby时备库会做一个快照,并且会继续接收主库的日志,但是不做apply,此时用户不仅可以对数据库做查询也可以做修改等操作,在Snapshot Standby切换回Physical Standby的时候,之前本地所做的所有操作将会被丢弃,这实际上是通过flashback database技术实现的,数据库回到切换点,然后将之前接收过来但没有被apply的日志进行apply,这种模式通常被用来一些临时性的需求,比如升级测试等。

接下来是具体操作:

我们有一个已在使用的ORACLE数据库,版本为11.2.0.3,和一个已经安装了11.2.0.3数据库软件的服务器,首先我们必须先创建一个physical standby,11gR2创建physical standby的方式其实跟10g没有太大的区别,无非就是设置相应的参数,将主库备份,然后到备库上去恢复,不过在10g中fal_client参数在11gR2中不再使用,11gR2的duplicate可以从一个active database直接复制,而不用先在主库备份然后将备份拷贝到备库恢复。

主备库相关配置如下:

primary database physical database
hostname gc dg
ip 192.168.192.200 192.168.192.201
db_name yxd yxd
db_unique_name yxd yxdst
sid yxd yxdst
instance_name yxd yxdst
数据/日志文件 /oradata/yxd /oradata/yxdst
归档路径 /oradata/arch /oradata/arch

主库listener.ora配置如下:

备库listener.ora配置如下:

主备库tnsnames.ora配置如下:

注意:这里备库的TNS配置里需要加上UR=A,这是因为数据库启动到nomount状态是无法通过TNS来连接的,而通过duplicate来复制数据库是需要auxiliary database是通过net service连接,设置了UR=A就可以在nomount状态下通过net service方式连接到数据库。

 

启动备库的监听:

这时备库是没有数据库的,所以监听提示no services,不用理会,使用tnsping确认主备库能互相ping通:

主库启用force logging:

主库设置如下参数:

db_file_name_convert和log_file_name_convert需要重启数据库才生效 只在库为备库时才有用。

如果两台服务器存放数据文件和日志文件的路径是一样的 可以不用设置这两个参数。

我的主库是已经开启归档的,如果你的主库没有开启归档请将归档开启。

在备库创建密码文件:

主库创建pfile修改相应参数后给备库使用:

创建出的主库的pfile内容如下,已将yxd._打头的参数去掉:

修改相应参数后给备库使用的pfile内容如下:

其中主要修改了audit_file_dest、control_files的路径,添加了db_unique_name='yxdst',修改了fal_server、log_archive_dest_1、log_archive_dest_2以及log_file_name_convert和db_file_name_convert的对应关系,注意audit_file_dest需要手动创建,让然如果你没有开启审计就不需要这个目录。

将修改后的inityxdst.ora文件拷贝至备库$ORACLE_HOME/dbs下,并使用该pfile创建spfile,将备库启动至mount状态:

使用RMAN的duplicate直接复制主库为备库:

使用nofilenamecheck是为了避免RMAN去理解文件名称和路径,它有可能会识别错误而报错,即便你指明了转换。

from active database是11G的新特性,在复制时不必先在主库备份通过备份来恢复,而是直接通过网络将数据复制过来。

在主备库创建standby logfile,根据ORACLE建议standby logfile组数为主库每thread日志组数+1,大小与主库在线日志大小相同,主库可暂时不加standby logfile,standby logfile只在其角色为standby时才会用到,我们主库的redo logfie为3组,所以我们要创建4组standby logfile:

查看备库相关信息:

可以看到SWITCHOVER_STATUS为RECOVERY NEEDED,说明需要进行日志恢复,使用以下语句开始日志同步恢复:

 

USING CURRENT LOGFILE Clause Specify USING CURRENT LOGFILE to invoke real-time apply, which recovers redo from the standby redo log files as soon as they are written, without requiring them to be archived first at the physical standby database.

同时我们可以看到数据库的保护模式为MAXIMUM PERFORMANCE,保护模式有3种,MAXIMIZE PROTECTION、MAXIMIZE AVAILABILITY和MAXIMUM PERFORMANCE,MAXIMUM PERFORMANCE是默认的模式,3种模式的区别如下:

TO MAXIMIZE PROTECTION This setting establishes maximum protection mode and offers the highest level of data protection. A transaction does not commit until all data needed to recover that transaction has been written to at least one physical standby database that is configured to use the SYNC log transport mode. If the primary database is unable to write the redo records to at least one such standby database, then the primary database is shut down. This mode guarantees zero data loss, but it has the greatest potential impact on the performance and availability of the primary database.

TO MAXIMIZE AVAILABILITY This setting establishes maximum availability mode and offers the next highest level of data protection. A transaction does not commit until all data needed to recover that transaction has been written to at least one physical or logical standby database that is configured to use the SYNC log transport mode. Unlike maximum protection mode, the primary database does not shut down if it is unable to write the redo records to at least one such standby database. Instead, the protection is lowered to maximum performance mode until the fault has been corrected and the standby database has caught up with the primary database. This mode guarantees zero data loss unless the primary database fails while in maximum performance mode. Maximum availability mode provides the highest level of data protection that is possible without affecting the availability of the primary database.

TO MAXIMIZE PERFORMANCE This setting establishes maximum performance mode and is the default setting. A transaction commits before the data needed to recover that transaction has been written to a standby database. Therefore, some transactions may be lost if the primary database fails and you are unable to recover the redo records from the primary database. This mode provides the highest level of data protection that is possible without affecting the performance of the primary database.

我们可以在主库通过alter database语句的以下子句对备库的保护模式进行更改:

maximize_standby_db_clause

 

在备库上确认已经存在的归档日志:

在主库强制切换日志使当前日志归档:

在备库上确认新的redo日志数据已在备库被归档:

确认备库上接收的日志已经被apply:

最近接收过来的日志的APPLIED字段的值要么是YES要么是IN-MEMORY就说明日志已经被apply了。

可以通过v$managed_standby视图查看备库进程状态:

ARCH是归档进程,RFS是日志传输进程,MRP是媒体恢复进程,MRP进程的状态为APPLYING_LOG说明正在应用日志,如果为WAIT_FOR_LOG说明有日志没有传输过来,可将主库的log_archive_dest_state_2设置为deffer,然后强制切换日志,再将log_archive_dest_state_2设置为enable,然后再强制切换一次日志,日志就应该会传输到备库了,如果MRP的进程状态为WAIT_FOR_GAP,那么说明有缺失的归档日志,在主库找到相应的归档日志将去拷贝到备库,然后将该日志注册到备库即可。

可以通过查看v$dataguard_stats检查日志apply是否有延迟:

到这里我们的Physical Standby就已经创建完成了,我们可以试着将主备库进行角色切换。

主库的状态如下:

备库的状态如下:

首先我们在主库上将其切换为备库:

切换完后查看原备库状态如下:

原主库状态如下:

我们将原备库切换为主库:

查看其状态如下:

将新的主库打开:

将新的备库关闭,并重启到mount状态:

将新备库与主库进行同步,apply redo log:

可以查看相关视图,v$managed_standby、v$dataguard_stats、v$database、v$archived_log等来确定日志是否有效地被apply和同步。

 

Active Data Guard的使用

现在我们将Physical standby切换到Active Standby,将备库打开并且apply日志,使其实现Real-Time Query,Physical Standby数据库在Redo Apply激活的状态下是无法打开的,所以必须先停止Apply,再将数据库打开,然后再Apply:

如果你要将主库的Real-Time查询压力卸载到备库上去,那么你需要监控apply lag确保其在可接受的范围之内,你可以通过一下SQL查看apply lag的信息:

DATUM_TIME字段表示备库最后一次从主库接收到该数据的时间,TIME_COMPUTED是备库apply lag指标被计算的时间,这两个时间是会有差异的,这表示了备库的数据与主库数据被apply的滞后时间,这两个时间差不应该大于30秒,否则apply lag的指标会不准确。

可以通过V$STANDBY_EVENT_HISTOGRAM视图查询备库自启动来apply lag的历史记录:

在Real-Time Query环境中配置Apply Lag的宽限度,会话级别的参数STANDBY_MAX_DATA_DELAY用来指定具体的非管理用户会话在备库中查询数据的apply lag的限度,单位为妙,它不是实例级别的参数,所以在参数视图中是无法找到这个参数的,这个能力允许查询安全的从主库卸载到备库上,因为备库的数据有可能会被检测到不可接受的过期。

STANDBY_MAX_DATA_DELAY参数如果不设置,它的默认值为NONE,发布到备库上的查询将无视apply lag而被执行。

如果STANDBY_MAX_DATA_DELAY被设置为一个非0的值,那么如果apply lag小于或等于STANDBY_MAX_DATA_DELAY的值,查询就会被执行,如果大于这个值,那么它将返回一个error警告客户端。

如果STANDBY_MAX_DATA_DELAY被设置为0,那么发布到备库的查询将会保证其结果与主库查询出的结果一致,除非备库落后与主库,那么这将返回一个error。

使用以下语句来设置STANDBY_MAX_DATA_DELAY参数:

在Real-Time Query环境中可以通过以下语句强制Redo Apply同步,它可以确保所有从主库接收过来的redo数据被apply到备库上:

注意:要这样强制同步数据库的保护模式必须至少为MAXIMUM AVAILABILITY,日志的传输模式需要为SYNC,否则会报如下错误:

这个语句会一直阻塞,直到在命令发布时接收到备库的redo数据被全部apply到备库。如果备库的日志传输状态不是SYNCHRONIZED,或者Redo  Apply没有被激活,那么它会马上返回ora-03173这个错误。

你可以使用 SYS_CONTEXT('USERENV','DATABASE_ROLE')函数创建一个standby-only trigger来确保在指定的情况下Redo Apply同步的发生,这个trigger在主库上启用,但只会在备库上执行操作,例如,你可以为一个指定用户的登录连接创建以下的trigger来执行‘ALTER SESSION SYNC WITH PRIMARY’语句:

Real-Time Query环境如果 STANDBY_MAX_DATA_DELAY被设置为0,或者使用了ALTER SESSION SYNC WITH PRIMARY语句,有如下限制:

  • The standby database must receive redo data via the SYNC transport.
  • The redo transport status at the standby database must be SYNCHRONIZED and the primary database must be running in either maximum protection mode or maximum availability mode.
  • Real-time apply must be enabled.
  • Active Data Guard achieves high performance of real-time queries in an Oracle RAC environment through the use of cache fusion. This allows the Data Guard apply instance and queries to work out of cache and not be slowed down by disk I/O limitations. A consequence of this is that an unexpected failure of the apply instance leaves buffers in inconsistent states across all the open Oracle RAC instances. To ensure data consistency and integrity, Data Guard closes all the other open instances in the Oracle RAC configuration, and brings them to a mounted state. You must manually reopen the instances - at which time the data is automatically made consistent, followed by restarting redo apply on one of the instances. Note that in a Data Guard broker configuration, the instances are automatically reopened and redo apply is automatically restarted on one of the instances.

 

将备库切换为Snapshot Standby

将physical standby切换到snapshot standby需要做以下操作:

1.  停止Redo Apply,如果它是激活的话:

2.  确保备库是mount状态,而不是open:

3.  确保备库的fast recovery area被配置,flashback database可以不用启用:

4.  执行以下语句将physical standby转换为snapshot standby:

在转换时我们可以注意以下alert.log,有以下信息:

我们可以看到在转换snapshot standby时,数据库创建了一个恢复点,我们可以去flashback recovery area的目录下去看一下,它生成了相关日志,实际上snapshot standby是通过flashback database实现的,虽然我们并不需要开启flashback database。

我们可以查看转换成snapshot standby后备库的相关信息:

我们可以看到DATABASE_ROLE变成了SNAPSHOT STANDBY,MRP进程没有了,也就没有了日志恢复,apply lag有24分多钟的延迟了。

现在我们把备库打开。

我们可以清楚的看到数据库的open_mode为read write可读写。

我们可以在主库切换日志查看备库是否有继续接收日志,备库归档如下:

主库归档如下:

在主库强制切换日志之后归档如下:

在主库切换日志后备库归档如下:

说明归档日志虽然不会被apply但还是会传输到备库上,备库依旧会接收主库的日志,在主库上做的操作很显然现在是不会被应用到备库上的,我们做如下实验:

在主库的scott账户下创建一张test表,并插入一些数据:

很显然备库的scott用户下是不会有这张test表的:

接下来我们在备库的scott用户下创建一张test2的表,并插入一些数据:

我们在备库上切换一次日志:

我们可以看到有一个sequence为2的归档记录,这是我们备库自己的归档。

现在我们将Snapshot Standby切换回Physical Standby,如果是RAC环境需要将所有实例都关闭,只保留一个实例,并且数据库必须为mount状态,不能为open状态,执行如下语句切换回Physical Standby:

查看alert.log有如下相关信息:

我们可以看到数据库有做FLASHBACK的操作,并且在恢复之后会将恢复点和flashback日志删除。

我们将数据库先关闭再打开,并且进行redo apply,查看之前备库的一些修改是否会保留,主库的修改是否会同步:

我们可以看到在还没redo apply时,scott下既没有原先在备库创建的test2表,也没有主库创建的test表,也就是说备库实际是恢复到了切换时的状态,但之前备库的归档序列1和2还是存在的,现在我们激活redo apply:

我们可以看到主库scott下的test表同步到备库了,查看alert.log可以发现一下信息:

数据库对之前接收过来没有被apply的日志进行了恢复,查看相关视图状态都为正常:

Snapshot Standby是无法进行switchover和failover的,它必须切换回Physical Standby才可以主备切换,Snapshot Standby可用做对生产数据临时性的测试使用,在Snapshot Standby期间备库所做的所有更改在切换回Physical Standby后将全部丢弃,没有被apply的日志在启动Redo Apply后将自动被apply。

请尊重我们的辛苦付出,未经允许,请不要转载 Ask600 的文章!