正在播放：dataguard failover and logical standby
下载学院APP缓存视频离线看
购买本课程后即可享受以下服务:
24小时讲师答疑
所有课时永久观看
专属课件资料下载
购买课程返学分
价格：?199
购买本课程后，就可以记笔记了~~
开始记笔记……
记录时间点
我的笔记同学的笔记
购买本课程后，就可以提问题了~~
向老师提问……
记录时间点
我的问题同学的问题&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
] 　　它有无数个名字，有人叫它dg，有人叫它数据卫士，有人叫它data guard，在oracle的各项特性中它有着举足轻理的地位，它就是(掌声)......................Oracle Data Guard。而对于我而言，我一定要亲切的叫它：DG(注：主要是因为打着方便)。&&&[
] 　　同一个Data Guard配置包含一个Primary数据库和最多九个Standby数据库。Primary的创建就不说了，Standby数据库初始可以通过primary数据库的备份创建。一旦创建并配置成standby后，dg负责传输primary数据库redo data到standby数据库，standby数据库通过应用接收到的redo data保持与primary数据库的事务一致。&&&[
] 　　不管物理standby还是逻辑standby，其初始创建都是要依赖primary数据库，因为这个准备工作中最重要的一部分，就是对primary数据库的配置。&&&[
] 　　为了最大的降低硬件需求，此处创建的data guard处于同一台机器，但其创建过程与多机并无区别。做为演示用的示例足够了，我们分两阶段配置，分别是配置primary数据库和配置standby数据库，详见正文~&&&[
] 　　第1节的时候我们就提到了角色切换，我们也听说了其操作简单但用途广泛，同时我们也猜测其属于primary与standby之间的互动，那么在primary和standby数据库(之一)上都需要有操作，并且切换又分了：switchover和failover，前者是无损切换，不会丢失数据，而后者则有可能会丢失数据，并且切换后原primary数据库也不再是该data guard配置的一部分了.针对不同standby(逻辑或物理)的处理方式也不尽相同&&&[
] 　　世上没有永恒的主角，能够留住永恒的反是那些默默无闻的小角色，这一节出场的都是重量级选手，它们虽然不是主角，但他们比主角更重要(有时候)。&&&[
] 　　为预防可能的错误，你必须知道primary数据库的某些事件可能影响standby数据库，并且了解如何处理。某些情况下，primary数据库的某些改动会自动通过redo数据传播到standby数据库，因此不需要在standby数据库做额外的操作，而某些情况，则需要你手工调整。&&&[
] 　　本节主要主要介绍一些监控DATAGUARD-Physical standby配置和优化的方式。&&&[
] 　　本节描述DATAGUARD-logical standby的创建步骤和一些注意事项。正如我们打小就被叮嘱饭前一定要洗手，在创建逻辑standby之前，准备工作同样必不可少。&&&[
] 　　本节通过实际操作全面演示了如何创建dataguard-logical standby数据库，以及日志切换和应用。
本站文章均为原创，转载请注明出处
站点设计：　我们的口号：前进就是在发展DG()是目前比较常见的HA配置策略。通过实现PhysicalStandby和Logical Standby，可以实现数据冗余容错机制。防止在主库出现严重故障，不能支持服务的时候，没有快速的后备支持环境。在DG中，switchover和是两个重要的概念，也是DG实现的核心。两者共同点都是Primary和Standby角色切 换，差异在于Planned和UnPlanned之分。Switchover关键点在于Planned，这个切换动作是在运维机构规划范围内的动作。比 如，进行定期系统软硬件升级、设备维修等动作。而Failover是真正出现严重系统故障，如数据库宕机、软硬件故障导致的Primary不能支持服务，从而进行的切换动作。根据不同的DG配置，switchover和failover也是有差异的。理论上，Switchover是不会造成数据丢失的，Primary在 切换之后也是在DG配置环境中，作为Standby存在的。但是Failover则不同，除了运行在最大保护(Maximum Protection)模式下，Primary突发的故障可能引起一部分Redo Log不能及时的传递到Standby端，切换之后很可能有数据损失的情况。更重要的是，Primary端在发生Failover之后，是不能够直接加入 回DG配置的!也就是说，Failover之后，Primary实际上就是被“抛出”了DG环境。那么，有什么方法实现Primary回到原有的环境呢?这个问题的困难在于保持Primary和Standby一致。在正常情况下，Primary 和Standby之间是关联同步的，即使发生了Switchover，也在可控情况下。Failover过程中有数据的缺失，还有Primary修复问 题。在目前流行版本(11g)中，有三个方法：环境重建：一种最简单的方法就是直接删除原来的Primary库，引用DG重建方法，重新搭建Standby端;备份恢复：如果Primary端保留过一份Failover之前的备份，则可以强制原来的Primary端恢复到进行Failover的时间点，之后作为Standby接收当前Primary的redo log传递，应用后可以跟上进度; Database恢复：Flashback技术是作为传统备份还原技术的补充，提供了更加便捷的恢复策略。使用，可以将数据库恢复到failover之前的时间点。之后的过程和备份恢复策略相同;案例分析：一、在主库端模拟数据库意外宕机1.7scott@bjdb&conn /as sysdba2.Connected.3.sys@bjdb& s4.System altered.5.sys@bjdb&shutdown abort6.ORACLE instance shut down.二、在备库端1、查看切换信息1.5sys@shdb&select name,database_role,switchover_status from v$2.NAME DATABASE_ROLE SWITCHOVER_STATUS3.--------- 4. PHYSICAL STANDBY NOT ALLOWED5.可以看到此时备库处于无法切换状态2、直接切换1.sys@shdb&alter database commit to s2.alert_log:(告警日志)3.Fatal NI connect error 12514, connecting to:4.(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HT=shsrv)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=shdb)(CID=(PROGRAM=oracle)(HOST=bjsrv)(USER=oracle))))5.VERSION INFORMATION:6.TNS for : Version 11.2.0.3.0 - Production7.TCP/IP NT Protocol Adapter for : Version 11.2.0.3.0 - Production8.Time: 04-MAR-:139.Tracing not turned on.10.Tns error struct:11.ns main err code: 1256412.TNS-12564: TNS:connection refused13.ns secondary err code: 014.nt main err code: 015.nt secondary err code: 016.nt OS err code: 017.Error 12514 received logging on to the standby18.FAL[client, MRP0]: Error 12514 connecting to shdb for fetching gap sequence19.Wed Mar 04 21:26:00 201520.alter database commit to switchover to primary21.ALTER DATABASE SWITCHOVER TO PRIMARY (TestDB12)22.Maximum wait for role transition is 15 minutes.23.Switchover: Media recovery is still active24.Database not available for switchover25.End-Of-REDO archived log file has not been recovered26.27.28.3、关闭standby MPR进程1.35sys@shdb&ALTER DATABASE RECOVER managed sta2.ALTER DATABASE RECOVER managed standby database finish3.Terminal Recovery: request posted (TestDB12)4.Wed Mar 04 21:34:34 20155.Begin: Standby Redo Logfile archival6.End: Standby Redo Logfile archival7.Terminal Recovery timestamp is '03/04/:34'8.Terminal Recovery: lying standby redo logs.9.Terminal Recovery: thread 1 seq# 34 redo required10.Media Recovery Waiting for thread 1 sequence 3411.Terminal Recovery: End-Of-Redo log allocation12.Terminal Recovery: standby redo logfile 4 created '/dsk4/arch_bj/arch_1_0_.log'13.This standby redo logfile is being created as part of the14.failover operation. This standby redo logfile should be15.deleted after the switchover to primary operation completes.16.Media Recovery Log /dsk4/arch_bj/arch_1_0_.log17.Terminal Recovery: log 4 reserved for thread 1 sequence 3418.Recovery of Online Redo Log: Thread 1 Group 4 Seq 34 Reading mem 019.Mem# 0: /dsk4/arch_bj/arch_1_0_.log20.Identified End-Of-Redo () for thread 1 sequence 34 at SCN 0xffff.ffffffff21.Incomplete Recovery applied until change 1234252 time 03/04/:4322.MRP0: Media Recovery Complete (TestDB12)23.Terminal Recovery: successful completion24.Wed Mar 04 21:34:35 201525.ARCH: Archival stopped, error occurred. Will continue retrying26.ORACLE Instance TestDB12 - Archival Error27.ORA-16014: log 4 sequence# 34 not archived, no available destinations28.ORA-00312: online log 4 thread 1: '/dsk4/arch_bj/arch_1_0_.log'29.Forcing ARSCN to IRSCN for TR 0:123425230.Attempt to set limbo arscn 0:1234252 irscn 0:123425231.Resetting standby activation ID
(0xaac836ee)32.MRP0: Background Media Recovery process shutdown (TestDB12)33.Terminal Recovery: completion detected (TestDB12)34.Completed: ALTER DATABASE RECOVER managed standby database finish4、切换数据库到Primary1.sys@shdb&select status from v$2.STATUS3.4.OPEN5.sys@shdb&select name,database_role,switchover_status from v$6.NAME DATABASE_ROLE SWITCHOVER_STATUS7.--------- 8.TESTDB12 PHYSICAL STANDBY TO PRIMARY9.sys@shdb&alter database commit to s10.Database altered.11.sys@shdb&12.Database altered.13.告警日志：14.alter database commit to switchover to primary15.ALTER DATABASE SWITCHOVER TO PRIMARY (TestDB12)16.Maximum wait for role transition is 15 minutes.17.All dispatchers and shared servers shutdown18.CLOSE: killing server sessions.19.CLE: all sessions shutdown successfully.20.Wed Mar 04 21:35:47 201521.SMON: disabling cache recovery22.Backup controlfile written to trace file /u01//oracle/diag/rdbms/bjdb/TestDB12/trace/TestDB12_ora_3146.trc23.Standby terminal recovery start SCN: 123425124.RESETLOGS after incomplete recovery UNTIL CHANGE 123425225.Online log /dsk2/oradata/bjdb/redo01b.log: Thread 1 Group 1 was previously cleared26.Online log /dsk1/oradata/bjdb/redo01a.log: Thread 1 Group 1 was previously cleared27.Online log /dsk2/oradata/bjdb/redo02b.log: Thread 1 Group 2 was previously cleared28.Online log /dsk1/oradata/bjdb/redo02a.log: Thread 1 Group 2 was previously cleared29.Online log /dsk2/oradata/bjdb/redo03b.log: Thread 1 Group 3 was previously cleared30.Online log /dsk1/oradata/bjdb/redo03a.log: Thread 1 Group 3 was previously cleared31.Standby became primary SCN: 123425032.33.Setting recovery target incarnation to 334.AUDIT_TRAIL initialization parameter is changed back to its original value as specified in the parameter file.35.Switchover: Complete - Database mounted as primary36.Completed:
database commit to switchover to primary三、原主库修复后，开机1.sys@bjdb&startup2. instance started.3.Total System Global Area
bytes4.Fixed Size 2229184 bytes5.Variable Size
bytes6.Database Buffers
bytes7.Redo Buffers 4161536 bytes8.Database mounted.9.Database opened.10.sys@bjdb&select name,database_role,switchover_status from v$11.NAME DATABASE_ROLE SWITCHOVER_STATUS12.--------- 13.TESTDB12 PRIMARY FAILED DESTINATION现在原来的主库被修复后，整个DataGuara架构已经被破坏了，所以必须把原来的主库构建成新的备库，重新恢复DataGuard的环境。四、重新构建1.1sys@bjdb&select name,database_role from v$NAME DATABASE_ROLE
PHYSICAL STANDBYOready即为“One Technology Ready”！Oready不仅仅是数据库领域的专家，同时也是一个社区，我们汇集百位数据库领域资深顾问、讲师，服务于的技术支持与技能传授，注重对客户的关键运营支撑，强调经验的分享-Skill Transfer，聚焦的完美结合.将为您减少类似内容我要收藏116个赞不感兴趣分享到分享到：相关文章还可以输入140字热门频道17万人订阅15.5万人订阅224.6万人订阅14.4万人订阅53.7万人订阅你还可用第三方账号来登录请输入你注册的电子邮件地址绑定密保手机*您可用使用此密保手机找回密码及登录*请勿随意泄露手机号，以防被不法分子利用，骗取帐号信息手机号码发送验证码确定电子邮件请输入您的意见和建议请您输入正确的邮箱地址，以便我们和您联系，帮您解决问题。扫描下载手机客户端热门搜词如何利用闪回数据库特性恢复failover后的dataguard环境？
11g dataguard standby 切成主库，测试完成后恢复为原standby 环境
11204 单机对单机实施dg，因局方要求需要（读写模式）打开standby ；而这时原生产环境不能有任何影响
11g dataguard standby 切成主库，测试完成后恢复为原standby 环境
#######################
11204 单机对单机实施dg，因局方要求需要（读写模式）打开standby ；而这时原生产环境不能有任何影响动，依然对外服务；
采用的思路是：standby 直接failover 为primary db；这时原有dg关系被破坏，互不影响；
#######################
思路概要：
1.确认主库归档日志存放空间是否足够？（需考虑归档保留删除策略？）；关闭主库到备库的日志传输
2.备库确认是否开启flashback database，以及闪回日志存放空间是否充足？
3.备库failover to primary （切换前确认是否日志延迟传输？手工注册）
4.业务测试
5.恢复failover 备库
6.确认dg 环境恢复是否正常（日志自动传输和应用？）？
#######################
具体实施步骤：
------主库defer 日志传输
alter system set log_archive_dest_2=
---enable 日志传输：
alter system set log_archive_dest_2=enable；
-----备库(mount)配置 flashback database：
STANDBY DATABASE: Stop redo apply, configure flashback retention,
start flashback database, open the database and start redo apply (Is active DG).
---检查备库是否启用flashback database:
select flashback_on from v$
注意这里需要确认下备库打开模式： mount？readonly with apply？
在11g 环境下备库可能启用了 ADG 特性 备库日志处于实时应用，模式为 readonly with apply
这时需要重启数据库到mount状态修改flashback database 模式；
如果备库处于mount 状态，可以先取消日志apply ，直接打开闪回数据库特性；
---取消备库日志应用：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
---需要配置一下两个参数来打开flashback database 特性：
ALTER SYSTEM SET db_recover_file_dest='/lixora/lixora/lixora/';
ALTER SYSTEM SET db_recover_file_dest_size=100G;
ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=240; ---4hours
ALTER DATABASE FLASHBACK ON;
--手工创建还原点（该步骤没有测试过）：
Creating Restore point in Physical Standby：
CREATE RESTORE POINT before_damage GUARANTEE FLASHBACK DATABASE
-------备库failover to primary db 应急切换步骤：
（注：模拟主库由于故障无法正常switchover，需要执行failover，强制备库-&pridb并接管业务）
由于是failover，所以理解主库这时候已经无法正常使用，只需备库切换至pridb
【前提主库还是可用的：可选】查询没有应用的日志：
SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
select distinct thread#,max(sequence#) over(partition by thread#) a from v$archived_
该语句取得当前数据库各线程已归档文件最大序号，如果primary 与standby 最大序号不相同，
必须将多出的序号对应的归档文件复制到待转换的standby服务器。
Cp过来并register
ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1'
停止应用恢复模式
alter database recover managed sta
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE;
转换standbydb为primary db
alter database commit to s
重启数据库，恢复正常业务
alter database open；
数据库角色查看：
select open_mode,database_role from v$
OPEN_MODE DATABASE_ROLE
---------- ----------------
OPEN PRIMARY
------恢复failover 的备库：
C. Using SQL*PLUS
Step 1 Determine the Standby Became Primary SCN.
Step 2 Flashback the Failed Primary Database.
Step 3 Convert to physical standby database.
Step 4 Restart Redo Transport.
Step 5 Start Redo Apply.
Step 1 Determine the SCN at which the old standby database became the primary database.
SQL& SELECT TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) FROM V$DATABASE;
Step 2 Flashback the Failed Primary Database to SCN standby_became_primary_scn.
SQL& SHUTDOWN IMMEDIATE;
SQL& startup mount
SQL& FLASHBACK DATABASE TO SCN ;
Step 3 Convert the database to a physical standby database and Restart database in mount stage.
SQL& ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
SQL& SHUTDOWN IMMEDIATE;
SQL& STARTUP MOUNT;
Step 4 Restart Redo Transport to the New Physical Standby Database.
1. If you have not set the remote archive destination on current primary then set remote archive destination:
SQL&ALTER SYSTEM SET LOG_ARCHIVE_DEST_2 = 'SERVICE=lixora VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=lixora' SCOPE=BOTH;
2. Enable the destination
SQL&ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;
3. Perform a log switch to ensure that standby database begins receiving redo data from the new primary database
SQL& ALTER SYSTEM SWITCH LOGFILE;
SQL& SELECT DEST_ID, STATUS, ERROR FROM V$ARCHIVE_DEST WHERE DEST_ID=2;
--确认日志是否都apply了？
select applied from v$archived_
select message from v$dataguard_
Step 5 Start Redo Apply.
SQL& ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
Please see also fallowing docu:
? Data Guard Concepts and Administration
11g Release 2 (11.2)
13.2 Converting a Failed Primary Into a Standby Database Using Flashback Database2013年5月 Oracle大版内专家分月排行榜第三
2017年1月 总版技术专家分月排行榜第二
2016年12月 总版技术专家分月排行榜第三
匿名用户不能发表回复！|
每天回帖即可获得10分可用分！小技巧：
你还可以输入10000个字符
(Ctrl+Enter)
请遵守CSDN，不得违反国家法律法规。
转载文章请注明出自“CSDN（www.csdn.net）”。如是商业用途请联系原作者。