|
|
本帖最后由 guoyJoe 于 2013-8-20 23:02 编辑
汇总各楼的精彩讨论：
30楼：wshxgxiaoli
1、Data Guard的核心操作是什么？
redo send, redo transport, redo apply.
2、Data Guard日志的传输模式有几种，分别是什么，可以具体说说它们的工作模式吗？
２.１ 使用ARCH进程：LOGSWITCH->本地归档->rfs传送->STANDBY 写入归档--> redo apply 注： ARCH不写STANDBY REDO
LOG
２.２ 使用LGWR进程：分两种：同步和异步
２.２.１ sync：
主库写REDO的时候，LGWR进程通过LNS进程把日志写到STANDBY，LGWR必须等待写入本地日志文件和STANDBY都写入成功了，主库上
的事务才算提交，STANDBY的RFS进程把接收到的日志写入到STANDBY REDO LOG中， 如果备库开启了实时恢复则当日志传过来时就
会进行REDO APPLY。 如果备库未开启实时应用，则需主库发生归档时，备库才会进行应用。
２.２.２ RSYNC：
主库写REDO的时候，LGWR进程通过LNS进程把日志写到STANDBY，LGWR不必等待日志传输成功，主库上的事务一旦发生提交，则事务
完成，STANDBY的RFS进程把接收到的日志写入到STANDBY REDO LOG中， 如果备库开启了实时恢复则当日志传过来时就会进行REDO
APPLY。 如果备库未开启实时应用，则需主库发生归档时，备库才会进行应用。
3、在部署Data Guard时，遇到最多的问题是什么？
备库服务监听配置。
4、Data Gurad主库备无法切换，存在的问题有可能是哪些？（OCM的考试中大部分人Data Guard做主备切换时，切不过去？）
主要问题是主备库之间产生了GAP， 解决办法， 将主库上的归档传到备库中， 进行手工应用。
5、Data Guard故障排：平时管理维护中碰到的错误及对应的解决方法？
刚开始由于管理上的不当，一些参数的误设置导致了一些问题的发生。
５.１ 磁盘空间没有进有监控。
主库有自动删除的脚本，由于备库空间爆了然后无法写入，主库用自动删除的脚本又把归档给删除了，最后采取在主库上（利用备
库的SCN）进行增量备份的方式重新修复了DG。
５.２ 参数设置：STANDBY_FILE_MANAGEMENT
被人设置成了手动， 在主库增加文件时，备库就会停止应用了。
解决办法：
Errors in file /oracle/diag/rdbms/sgtms02/sgtms/trace/sgtms_mrp0_14938.trc:
ORA-01111: name for data file 12 is unknown - rename to correct file
ORA-01110: data file 12: '/oracle/oracle11g/dbs/UNNAMED00012'
ORA-01157: cannot identify/lock data file 12 - see DBWR trace file
ORA-01111: name for data file 12 is unknown - rename to correct file
ORA-01110: data file 12: '/oracle/oracle11g/dbs/UNNAMED00012'
原因：
因为在创建DG的时候， 参数文件中STANDBY_FILE_MANAGEMENT：
SQL> parameter standby
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
standby_archive_dest string ?/dbs/arch
standby_file_management string MANUAL
为手动管理， 所以在主库创建数据文件的时候，备库无法同步， 所以备库停止了同步业务。
现处理方法如下：
alter database create datafile '/oracle/oracle11g/dbs/UNNAMED00012' as '/oracle/oradata/****/******.dbf'
31楼：guailong
1、Data Guard的核心操作是什么？
核心操作都是利用日志，一个是实时日志，一个是归档日志
2、Data Guard日志的传输模式有几种，分别是什么，可以具体说说它们的工作模式吗？
最大保护：LGWR--LNSn--RFS--STANDBY REDO LOG
最高可用性：online redo---LNSn---RFS--STANDBY REDO LOG
最高性能：ARCH--RFS--STANDBY REDO LOG
3、在部署Data Guard时，遇到最多的问题是什么？
RAC多节点与RAC多节点的的DG配置
4、Data Gurad主库备无法切换，存在的问题有可能是哪些？（OCM的考试中大部分人Data Guard做主备切换时，切不过去？）
OCM考试的时候，是因为采用broker配置的，主库的转换参数convert 缺了备库的配置导致切换不成功。
5、Data Guard故障排：平时管理维护中碰到的错误及对应的解决方法？
按照报错代码进行解决，目前还未遇到解决不了的问题。
60楼：caibird2005
1、Data Guard的核心操作是什么？
核心是通过日志同步。
2、Data Guard日志的传输模式有几种，分别是什么，可以具体说说它们的工作模式吗？
Redo传输LGWR：所有写入主库的online redo被 synchronously 或者 asynchronously 传输到 standby 数据库。
如果 standby 数据库存在standby redo log，standby redo log将被使用。如果没有oracle会自动写到归档日志中，
然而如果归档日志没有写完的情况下如果出现灾难，该没有写满的归档日志是不能被用来做应用恢复的。
所以我们无论在哪种模式下(包括最大性能模式)都建议使用standby redo log。
最大可用和最大保护模式下,需要使用lgwr来传送日志.
最大保护和最大可用模式下,需要设置为SYNC AFFIM模式.
Arch传输：如果主库日志归档，Arch进程把归档日志传输到standby数据库。
3、在部署Data Guard时，遇到最多的问题是什么？
a.备库无法应用日志。
b.主备切换不过去，主库无法切换成备库。
c.新建的表空间，备库无法生成。
4、Data Gurad主库备无法切换，存在的问题有可能是哪些？（OCM的考试中大部分人Data Guard做主备切换时，切不过去？）
a.遗漏了参数 STANDBY_FILE_MANAGEMENT=AUTO
b.虚拟机IO太差，导致新建一个500MB的表空间需要很长时间，结果没有新建完成，主备就切换，导致切换失败。
5、Data Guard故障排：平时管理维护中碰到的错误及对应的解决方法？（错误集锦，相互补充，呵呵这个话题有点大。。。兄弟
们请厮杀起来，奖品多多等你拿！）
a.日志gap缺口问题,解决：一般是fal_client和fal_server设置有问题,不行就找到缺口，手工拷贝日志文件，在备库手工注册日
志并恢复，实在不行只有重建standby。
b.日志异常，例如生成日志很多，或者生成日志很慢 。解决办法 ：首先要找到瓶颈在哪里，然后再去优化，可以加大APPLY的平
行，加大LOGMINNER的CACHE等等N多的优化手段。
c.主备切换后发生的问题，例如切换后，备库无法恢复日志了等等。
d.还有网络导致的日志传输问题,延迟时间太长也会出现问题。
67楼：深圳-小兵
1、Data Guard的核心操作是什么？
physical standby ----Redo Apply-------recovery
logical standby -----SQL Apply -------logminer
2、Data Guard日志的传输模式有几种，分别是什么，可以具体说说它们的工作模式吗？(10g的说法)
在primary database中，oracle data guard 使用ARCn 或者LGWR进程来收集事务的日志信息，并将其传输到standby的目的地址。
虽然你不能同时使用ARCn和LGWR进程将redo信息传输到相同的目的地址，但是你可以选择使用LGWR进程将日志传输到一些地方，于
此同时你可以使用ARCn进程将日志传输到其他的地方。
1.Using Archiver Processes (ARCn) to Archive Redo Data
2.Using the Log Writer Process (LGWR) to Archive Redo Data
2.1 LGWR+SYNC: ----这个是默认值
2.2LGWR+SYNC
3、在部署Data Guard时，遇到最多的问题是什么？
真实搭建的时候木有遇到什么问题，影响比较深刻的是：有一次搭建DG的时候，因为主库的空间不够，我们用NFS挂载备份的，
但是在mount的时候没有加参数限制，导致磁盘速度没有网络传输速度快，把主库搞挂了
4、Data Gurad主库备无法切换，存在的问题有可能是哪些？（OCM的考试中大部分人Data Guard做主备切换时，切不过去？）
没有遇到过
5、Data Guard故障排：平时管理维护中碰到的错误及对应的解决方法？
1.日志断点
2.日志不传输过去
3.主库的操作在备库无法重现
一些其他的案例放到郭大的一群了
68楼：cdbdp
1、Data Guard的核心操作是什么？
主库日志生成-日志传输-日志应用到备库
2、Data Guard日志的传输模式有几种，分别是什么，可以具体说说它们的工作模式吗？
maximize performance/maximize protection/maximize availability
maximize performance:commit不需要等日志应用到备库，日志会在稍后时间应用到备库。
maximize protection：commit需要等日志应用到备库才能完成，并且应用不成功会导致主库宕机。
maximize availability：类似maximize protection，但是日志应用失败的话，自动切换为maximize performance。
3、在部署Data Guard时，遇到最多的问题是什么？
没遇到过啥很难解决问题，主要注意部署平台的一致性，主备库网络带宽足够
4、Data Gurad主库备无法切换，存在的问题有可能是哪些？（OCM的考试中大部分人Data Guard做主备切换时，切不过去？）
有可能是网络配置问题，比如tnsnames中的名称和参数文件中的service不一致，或者密码文件有问题等等
5、Data Guard故障排：平时管理维护中碰到的错误及对应的解决方法？
没怎么遇到过
93楼：z3765295
讨论话题：
1、Data Guard的核心操作是什么？
答：核心操作都是利用日志，一个是实时日志，一个是归档日志。
2、Data Guard日志的传输模式有几种，分别是什么，可以具体说说它们的工作模式吗？
答：one：3种。
two：ARCH、LGWR SYNC、LGWR RSYNC。
three：part 1（ARCH）：使用ARCH进程：LOGSWITCH->本地归档->rfs传送->STANDBY 写入归档--> redo apply （
注： ARCH不写STANDBY REDO LOG）
part 2（LGWR SYNC）：主库写REDO的时候，LGWR进程通过LNS进程把日志写到STANDBY，LGWR必须等待写
入本地日志文件和STANDBY都写入成功了，主库上的事务才算提交，STANDBY的RFS进程把接收到的日志写入到STANDBY REDO LOG中
， 如果备库开启了实时恢复则当日志传过来时就会进行REDO APPLY。 如果备库未开启实时应用，则需主库发生归档时，备库才
会进行应用。
part 3（LGWR RSYNC）：主库写REDO的时候，LGWR进程通过LNS进程把日志写到STANDBY，LGWR不必等待日
志传输成功，主库上的事务一旦发生提交，则事务完成，STANDBY的RFS进程把接收到的日志写入到STANDBY REDO LOG中， 如果备
库开启了实时恢复则当日志传过来时就会进行REDO APPLY。 如果备库未开启
实时应用，则需主库发生归档时，备库才会进行应用。
3、在部署Data Guard时，遇到最多的问题是什么？
答：日志无法传输，多节点问题，设备老旧，无双机冗余。
4、Data Gurad主库备无法切换，存在的问题有可能是哪些？（OCM的考试中大部分人Data Guard做主备切换时，切不过去？）
答：OCM考试的时候，是因为采用broker配置的，主库的转换参数convert 缺了备库的配置导致切换不成功
(STANDBY_FILE_MANAGEMENT=AUTO)。
5、Data Guard故障排：平时管理维护中碰到的错误及对应的解决方法？（错误集锦，相互补充，呵呵这个话题有点大。。。兄弟
们请厮杀起来，奖品多多等你拿！）
答：1.日志。2.归档、备份。
而且有错误，是有错误代码的吧。呵呵
94楼：wfsitpub
学习了，楼主这贴可以加强对DG理解和记忆
现在的生产环境是DG+broker，搭建还是比较容易。在实际应用中物理备份要比逻辑备库用得多吧。
1、Data Guard的核心操作是什么？
主要是日志，发送，传输，应用。
2、Data Guard日志的传输模式有几种，分别是什么，可以具体说说它们的工作模式吗？
ARCH
本地归档后通过NET把归档发送到standby database 的RFS（remote file server）进程，
备库通过FAL(Fetch archive log)提取日志，通过MRP(managed recovery process)进行redo apply或者sql apply恢复
。
LGWR
-async
lgwr将redo写到本地log文件，LNSn进程读取redo,通过RFS传输到备库
但是LGWR进程只需成功写入日志文件就可以，不必等待LNSn进程的网络传送成功。
-sync
产生的Redo 日志要同时写到日志文件和网络
LGWR 必须等待写入本地日志文件操作和通过LNSn进程的网络传送都成功，Primary Database 上的事务才能提交，
这也是SYNC的含义所在
Standby Database的RFS进程把接收到的日志写入到Standby Redo Log日志
中。
Primary Database的日志切换也会触发Standby Database 上的日志切换，即Standby
Database 对Standby Redo Log的归档，然后触发Standby Database 的MRP或者LSP 进程恢复归档日志。
3、在部署Data Guard时，遇到最多的问题是什么？
备库无法应用日志。
在主库上创建temp表空间，备库上没有自动创建。需要手动创建。
另外在配置broker的时候遇到一些问题
4、Data Gurad主库备无法切换，存在的问题有可能是哪些？（OCM的考试中大部分人Data Guard做主备切换时，切不过去？）
STANDBY_FILE_MANAGEMENT=AUTO
5、Data Guard故障排：平时管理维护中碰到的错误及对应的解决方法？（错误集锦，相互补充，呵呵这个话题有点大。。。兄弟
们请厮杀起来，奖品多多等你拿！）
对于日志gap,11g中可以用fal_server解决，
遇到最多的应该是归档的管理了。
使用道具 举报
115楼：monkiu
故障日志：
Sun Feb 03 17:41:21 2013
ORA-00270: error creating archive log D:\APP\ADMINISTRATOR\FLASH_RECOVERY_AREA\ZNVORA\ARCHIVELOG
\ARC0000033079_0783257873.0001
ORA-19504: failed to create file "D:\APP\ADMINISTRATOR\FLASH_RECOVERY_AREA\ZNVORA\ARCHIVELOG
\ARC0000033079_0783257873.0001"
ORA-27044: unable to write the header block of file
OSD-04008: WriteFile() 失败, 无法写入文件
O/S-Error: (OS 112) 磁盘空间不足。
故障原因：很明显这是因为空间不足导致archivelog无法写入导致的。但是关于archivelog已经写了RMAN脚本去定期（每天凌晨1
点执行）删除了。平时测试，该RMAN脚本是没有问题的，可以删除5天前的archivelog。
故障分析：
RMAN脚本如下：
@echo off
cd E:\ora_back
set dircd=E:\ora_back
echo crosscheck archivelog all; > %dircd%\rmandellog.sql
echo delete archivelog all completed before 'sysdate-5; >> %dircd%\rmandellog.sql
echo exit >> %dircd%\rmandellog.sql
echo exit >> %dircd%\rmandellog.sql
rman target sys/***@connect_str cmdfile=%dircd%\rmandellog.sql log=%dircd%\Rman_log\Rman_del%DATE:~0,4%
%DATE:~5,2%%DATE:~8,2%%time:~0,2%.log
exit
该脚本看似没有问题，但是各位请看下文。
Microsoft Windows [版本 6.1.7601]
版权所有 (c) 2009 Microsoft Corporation。保留所有权利。
C:\Users\Administrator>echo Rman_del%DATE:~0,4%%DATE:~5,2%%DATE:~8,2%%time:~0,2%.log
Rman_del20130806 9.log
C:\Users\Administrator>echo Rman_del%DATE:~0,4%%DATE:~5,2%%DATE:~8,2%%time:~0,2%.log
Rman_del2013080611.log
C:\Users\Administrator>
你应该发现了,同一个语句产生了不同的文件名,在执行这个语句的前后操作间我只改了下操作系统的时间(小时), 很明显,前面是
生成9点时的文件名,后面是生成11点时的文件名,
不同的是,前面一个文件名中间不是"09",取而代之的是"空格9" ,恰巧,这个空格在RMAN工具下是作为参数分隔符来识别的,RMAN在
调用其后面的参数时遇到空格就当作另一个输
入参数识别了,所以根本上就没有成功调用RMAN,所以没有生成追踪日志文件.而之前每次测试都是成功的,是因为每次都过了上午10
点后测试的,即取得的系统时间都没有遇到空格这陷阱,
针对这个问题简单处理一下,加个判断或者用引号引起来(RMAN的转义)或改下自动任务执行时间大于10(此时才想起之前有调整过自
动任务执行的时间由23点至零辰2点)等都可以解决...
修改脚本，故障解决，修改后的脚本如下：
@echo off
cd E:\ora_back
set dircd=E:\ora_back
echo crosscheck archivelog all; > %dircd%\rmandellog.sql
echo delete archivelog all completed before 'sysdate-5; >> %dircd%\rmandellog.sql
echo exit >> %dircd%\rmandellog.sql
echo exit >> %dircd%\rmandellog.sql
rman target sys/***@connect_str cmdfile=%dircd%\rmandellog.sql log=%dircd%\Rman_log\Rman_del%DATE:~0,4%
%DATE:~5,2%%DATE:~8,2%0%time:~1,1%%time:~3,2%.log
exit
总结:这是一个很细微的问题,但付出了代价却很大(导致DATAGUARD重搭建),所以在此写一下,小题大作了,希望对大侠们有用!还有
就是如果DG有一个自动删除归档日志的选项就好了，不用这么麻烦，还要自己写脚本删除归档日志。
118楼：lovehewenyu
以下均物理data guard
1、Data Guard的核心操作是什么？
redo send、redo receive、redo apply
redo send==>log_archive_dest_2;log_archive_dest_state_2=enable;LNSn(lgwr network server process)|LGWR
==>log_archive_dest_2;log_archive_dest_state_2=enable;LNS|ARCH
redo receive==>redo buffer write to SRL;RFS(remote file server process)|LGWR
==>archivelog to archivelog;RFS(remote file server process)|ARCH
redo apply==>from SRL or archivelog to read redo data and application;MRP|LGWR
==>from archivelog to read redo data and application;MRP|ARCH
2、Data Guard日志的传输模式有几种，分别是什么，可以具体说说它们的工作模式吗？
2种、LGWR,ARCH、工作模式主库的不考虑了，只考虑与备库有关如下
LGWR==>redo buffer->standby redo logfiles;LNSn->RFS->SRL,MRP从SRL读取redo data并应用
ARCH==>logswitch->archivelog;LNS->RFS->archivelog,MRP从archivelog读取redo data并应用
3、在部署Data Guard时，遇到最多的问题是什么？
细心度不够，参数不正确问题
GAP问题，主库归档存在可以重新注册，如果归档不存在且数据量巨大可以考虑基于SCN的增量备份来恢复data guard
4、Data Gurad主库备无法切换，存在的问题有可能是哪些？（OCM的考试中大部分人Data Guard做主备切换时，切不过去？）
切换次数不多，省略不总结了
5、Data Guard故障排：平时管理维护中碰到的错误及对应的解决方法？
问题
1、GAP
http://space.itpub.net/26442936/viewspace-722309
2、PROTECTION_MODE is UNPROTECTED at standby database
http://space.itpub.net/26442936/viewspace-750323
3、duplicate ora-19505 （controlfile 不可用）
http://space.itpub.net/26442936/viewspace-767942
4、duplicate ORA-01405: fetched column value is NULL
http://space.itpub.net/26442936/viewspace-767943
5、connected to auxiliary database (not started)
解决方法:sqlplus sys/oracle@orcl as sysdba保证能连接到启动的实例即可
6、ORA-19573: cannot obtain exclusive enqueue for datafile
http://space.itpub.net/26442936/viewspace-753432
124楼：mcyeah
1、Data Guard的核心操作是什么？
前面总结的很好了 不重复了
2、Data Guard日志的传输模式有几种，分别是什么，可以具体说说它们的工作模式吗？
同上
3、在部署Data Guard时，遇到最多的问题是什么？
Renaming Datafiles with the ALTER DATABASE Statement
Standby Database Does Not Receive Redo Data from the Primary Database
You Cannot Mount the Physical Standby Database
4、Data Gurad主库备无法切换，存在的问题有可能是哪些？（OCM的考试中大部分人Data Guard做主备切换时，切不过去？）
主切换到备出问题
In most cases, following the steps described in Chapter 8 will result in a successful switchover. However, if the
switchover is unsuccessful, the following sections may help you to resolve the problem:
Switchover Fails Because Redo Data Was Not Transmitted
Switchover Fails Because SQL Sessions Are Still Active
Switchover Fails Because User Sessions Are Still Active
Switchover Fails with the ORA-01102 Error
Redo Data Is Not Applied After Switchover
Roll Back After Unsuccessful Switchover and Start Over
备切换到主 是因为重做数据没有被提交
5、Data Guard故障排：平时管理维护中碰到的错误及对应的解决方法？（错误集锦，相互补充，呵呵这个话题有点大。。。兄弟
们请厮杀起来，奖品多多等你拿！）
暂时没有，不过下面的链接给出了很多问题和解决办法，如果有问题可以参考
参考http://docs.oracle.com/cd/B28359 ... troubleshooting.htm 这里
129楼：gamble_god
刚刚看了《盛哥一点一滴讲解Data Guard前世今生》，自己测试了下DG Broker
Broker可以方便的进行switchover，可以配置自动的Failover，同时在完成failover后，原来的主库仍然可以加入到DG中
具体实验测试步骤如下：
#所有主备库启动Broker功能和Flashback功能
#primary
SQL> show parameter dg_broker_start;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
dg_broker_start boolean FALSE
SQL> alter system set dg_broker_start=true;
System altered.
SQL> select flashback_on from v$database;
FLASHBACK_ON
------------------
NO
#正常shutdown immediate-->startup mount-->alter database flashback on
SQL> alter database flashback on;
Database altered.
SQL> select flashback_on,open_mode from v$database;
FLASHBACK_ON OPEN_MODE
------------------ --------------------
YES READ WRITE
#standby
SQL> show parameter dg_broker_start;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
dg_broker_start boolean FALSE
SQL> alter system set dg_broker_start=true;
System altered.
SQL> alter database recover managed standby database cancel;
Database altered.
SQL> alter database flashback on;
Database altered.
SQL> alter database recover managed standby database disconnect from session;
Database altered.
#使用具有SYSDBA权限的用户登录Broker工具
bash-3.2$ dgmgrl sys/oracle11
DGMGRL for Solaris: Version 11.2.0.3.0 - 64bit Production
Copyright (c) 2000, 2009, Oracle. All rights reserved.
Welcome to DGMGRL, type "help" for information.
Connected.
DGMGRL>
#DG Broker工具必须先Configure才能使用
#primary
DGMGRL> create configuration dgtest as primary database is oradg1 connect identifier is primary;
Configuration "dgtest" created with primary database "oradg1"
Syntax:
CREATE CONFIGURATION <configuration name> AS ------配置名自定义
PRIMARY DATABASE IS <database name> ------数据库实例名
CONNECT IDENTIFIER IS <connect identifier> ------监听连接字符串名
#添加一个备库到Broker工具中
DGMGRL> add database oradg2 as connect identifier is standby maintained as physical;
Database "oradg2" added
Syntax:
ADD DATABASE <database name>
[AS CONNECT IDENTIFIER IS <connect identifier>]
[MAINTAINED AS {PHYSICAL|LOGICAL}]
#查看配置
DGMGRL> show configuration
Configuration - dgtest
Protection Mode: MaxPerformance
Databases:
oradg1 - Primary database
oradg2 - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
DISABLED
#Maximum Protection/Availability 必须满足以下条件：
>Redo Archive Proess: LGWR
>Network Transmission mode: SYNC
>Disk Write Option: Affirm
>Standby Logfile: Yes
>Standby database type: physical only
因为primary database的Redo是实时传递过来的，于是standby database端可以使用两种方式应用日志：
实时应用（Real-time Apply）：只要RFS把日志写入standby logfile就立刻应用
归档应用：在完成对Standby Logfile归档后才触发应用
primary database默认使用ARCH进程，如果使用LGWR进程必须明确指定
#配置主备库为SYNC同步模式
DGMGRL> edit database oradg1 set property logxptmode='sync';
Property "logxptmode" updated
DGMGRL> edit database oradg2 set property logxptmode='sync';
Property "logxptmode" updated
#修改保护模式为最大可用模式
DGMGRL> edit configuration set protection mode as maxavailability;
Succeeded.
#还可以使用alter database set standby database to maximize availability;（数据库在mount下才可以执行） --->主
备库都执行
DGMGRL> show configuration;
Configuration - dgtest
Protection Mode: MaxAvailability
Databases:
oradg1 - Primary database
oradg2 - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
DISABLED
#Broker配置文件
SQL> show parameter dg_broker_config_file;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
dg_broker_config_file1 string /u01/app/oradg1_base/product/11.2.0/oradg1_home/dbs/dr1oradg1.dat
dg_broker_config_file2 string /u01/app/oradg1_base/product/11.2.0/oradg1_home/dbs/dr2oradg1.dat
#配置DGMGRL后会在$ORACLE_HOME/dbs下生成两个配置文件（这两个配置文件是二进制文件，不要手动修改）
#Broker日志文件，这个日志文件会记录DGMGRL操作流程、配置文件的位置、保护模式、主备库信息
bash-3.2$ pwd
/u01/app/oradg1_base/diag/rdbms/oradg1/oradg1/trace
bash-3.2$ ls -l drcoradg1.log
-rw-r----- 1 oradg1 oinstall 8002 Aug 16 10:17 drcoradg1.log
#激活配置
DGMGRL> enable configuration
Enabled.
#激活后会在备库的$ORACLE_HOME/dbs下生成两个配置文件，在激活前是不会生成的。激活前，配置DGMGRL看不到configuration内
容
DGMGRL> show configuration;
ORA-16532: Data Guard broker configuration does not exist
Configuration details cannot be determined by DGMGRL
DGMGRL> show configuration
Configuration - dgtest
Protection Mode: MaxAvailability
Databases:
oradg1 - Primary database
oradg2 - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
#检查primary属性
DGMGRL> show database verbose oradg1
Database - oradg1
Role: PRIMARY
Intended State: TRANSPORT-ON ---可切换
Instance(s):
oradg1
Properties:
DGConnectIdentifier = 'primary'
ObserverConnectIdentifier = ''
LogXptMode = 'sync'
DelayMins = '0'
Binding = 'optional'
MaxFailure = '0'
MaxConnections = '1'
ReopenSecs = '300'
NetTimeout = '30'
RedoCompression = 'DISABLE'
LogShipping = 'ON'
PreferredApplyInstance = ''
ApplyInstanceTimeout = '0'
ApplyParallel = 'AUTO'
StandbyFileManagement = 'auto'
ArchiveLagTarget = '0'
LogArchiveMaxProcesses = '4'
LogArchiveMinSucceedDest = '1'
DbFileNameConvert = 'oradg2, oradg1'
LogFileNameConvert = 'oradg2, oradg1'
FastStartFailoverTarget = ''
InconsistentProperties = '(monitor)'
InconsistentLogXptProps = '(monitor)'
SendQEntries = '(monitor)'
LogXptStatus = '(monitor)'
RecvQEntries = '(monitor)'
SidName = 'oradg1'
StaticConnectIdentifier = '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=backuptest1)(PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=oradg1_DGMGRL)(INSTANCE_NAME=oradg1)(SERVER=DEDICATED)))'
StandbyArchiveLocation = '/data2/oradg1_arch'
AlternateLocation = ''
LogArchiveTrace = '0'
LogArchiveFormat = 'log_%t_%s_%r.arc'
TopWaitEvents = '(monitor)'
Database Status:
SUCCESS
#检查standby属性
DGMGRL> show database verbose oradg2
Database - oradg2
Role: PHYSICAL STANDBY
Intended State: APPLY-ON ----启动应用
Transport Lag: 0 seconds ----传输延迟
Apply Lag: 0 seconds ---- 应用延迟
Real Time Query: OFF
Instance(s):
oradg2
Properties:
DGConnectIdentifier = 'standby'
ObserverConnectIdentifier = ''
LogXptMode = 'sync'
DelayMins = '0'
Binding = 'OPTIONAL'
MaxFailure = '0'
MaxConnections = '1'
ReopenSecs = '300'
NetTimeout = '30'
RedoCompression = 'DISABLE'
LogShipping = 'ON'
PreferredApplyInstance = ''
ApplyInstanceTimeout = '0'
ApplyParallel = 'AUTO'
StandbyFileManagement = 'AUTO'
ArchiveLagTarget = '0'
LogArchiveMaxProcesses = '4'
LogArchiveMinSucceedDest = '1'
DbFileNameConvert = 'oradg1, oradg2'
LogFileNameConvert = 'oradg1, oradg2'
FastStartFailoverTarget = ''
InconsistentProperties = '(monitor)'
InconsistentLogXptProps = '(monitor)'
SendQEntries = '(monitor)'
LogXptStatus = '(monitor)'
RecvQEntries = '(monitor)'
SidName = 'oradg2'
StaticConnectIdentifier = '(DESCRIPTION=(address=(protocol=tcp)(host=10.103.1.143)(port=1522))
(CONNECT_DATA=(SERVICE_NAME=oradg2_DGMGRL)(INSTANCE_NAME=oradg2)(SERVER=DEDICATED)))'
StandbyArchiveLocation = '/data2/oradg2_arch'
AlternateLocation = ''
LogArchiveTrace = '0'
LogArchiveFormat = 'log_%t_%s_%r.arc'
TopWaitEvents = '(monitor)'
Database Status:
SUCCESS
#使用Broker工具进行switchover无损切换
DGMGRL> show configuration
Configuration - dgtest
Protection Mode: MaxAvailability
Databases:
oradg1 - Primary database
oradg2 - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
DGMGRL> switchover to oradg2
Performing switchover NOW, please wait...
New primary database "oradg2" is opening...
Operation requires shutdown of instance "oradg1" on database "oradg1"
Shutting down instance "oradg1"...
ORACLE instance shut down.
Operation requires startup of instance "oradg1" on database "oradg1"
Starting instance "oradg1"...
ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is "oradg2"
DGMGRL> show configuration
Configuration - dgtest
Protection Mode: MaxAvailability
Databases:
oradg2 - Primary database
oradg1 - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
#primary
SQL> select db_unique_name,open_mode,database_role,switchover_status,dataguard_broker,primary_db_unique_name from
v$database;
DB_UNIQUE_NAME OPEN_MODE DATABASE_ROLE SWITCHOVER_STATUS DATAGUAR
PRIMARY_DB_UNIQUE_NAME
------------------------------ -------------------- ---------------- -------------------- --------
------------------------------
oradg1 MOUNTED PHYSICAL STANDBY NOT ALLOWED ENABLED oradg2
#standby
SQL> select db_unique_name,open_mode,database_role,switchover_status,dataguard_broker,primary_db_unique_name from
v$database;
DB_UNIQUE_NAME OPEN_MODE DATABASE_ROLE SWITCHOVER_STATUS DATAGUAR
PRIMARY_DB_UNIQUE_NAME
------------------------------ -------------------- ---------------- -------------------- --------
------------------------------
oradg2 READ WRITE PRIMARY TO STANDBY ENABLED oradg1
#启动fast_start failover（FSFO）
前提条件检查
>主备库都启动flashback
>两端同步模式SYNC
>两端都有standby logfile
DGMGRL> enable fast_start failover
Enabled.
#启动observer
DGMGRL> start observer
Observer started
#否则报错如下：
Databases:
oradg1 - Primary database
Warning: ORA-16819: fast-start failover observer not started
oradg2 - (*) Physical standby database
Warning: ORA-16819: fast-start failover observer not started
#等待120秒failover，默认30秒
DGMGRL> edit configuration set property faststartfailoverthreshold=120;
Property "faststartfailoverthreshold" updated
#primary
SQL> select fs_failover_observer_present,fs_failover_observer_host,fs_failover_threshold from v$database;
FS_FAIL FS_FAILOVER_OBSERVER_HOST FS_FAILOVER_THRESHOLD
------- -------------------------------------------------- ---------------------
YES backuptest1 120
#standby
SQL> select fs_failover_observer_present,fs_failover_observer_host,fs_failover_threshold from v$database;
FS_FAIL FS_FAILOVER_OBSERVER_HOST FS_FAILOVER_THRESHOLD
------- -------------------------------------------------- ---------------------
YES backuptest1 120
#实现自动failover切换
当发生以下情况之一时observer会触发failover切换
>instance failure
>shutdown abort
>offline datafile due to I/O error
>network disconnection
SQL> shutdown abort;
ORACLE instance shut down.
#验证切换后状态
#standby
SQL> select db_unique_name,open_mode,database_role,switchover_status,dataguard_broker,primary_db_unique_name from
v$database;
DB_UNIQUE_NAME OPEN_MODE DATABASE_ROLE SWITCHOVER_STATUS DATAGUAR
PRIMARY_DB_UNIQUE_NAME
------------------------------ -------------------- ---------------- -------------------- --------
------------------------------
oradg2 READ WRITE PRIMARY NOT ALLOWED ENABLED oradg1
SQL> select fs_failover_status from v$database;
FS_FAILOVER_STATUS
----------------------
REINSTATE REQUIRED
#primary
SQL> select open_mode from v$database;
select open_mode from v$database
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 29019
Session ID: 217 Serial number: 53
#将原主库启动到mount状态，Observer会使用Flashback立即恢复primary为mounted状态，使其角色转换为physical standby并应
用服务
DGMGRL> show configuration verbose;
Configuration - dgtest
Protection Mode: MaxAvailability
Databases:
oradg2 - Primary database
Warning: ORA-16817: unsynchronized fast-start failover configuration
oradg1 - (*) Physical standby database (disabled)
ORA-16661: the standby database needs to be reinstated
(*) Fast-Start Failover target
Properties:
FastStartFailoverThreshold = '120'
OperationTimeout = '30'
FastStartFailoverLagLimit = '30'
CommunicationTimeout = '180'
FastStartFailoverAutoReinstate = 'TRUE'
FastStartFailoverPmyShutdown = 'TRUE'
BystandersFollowRoleChange = 'ALL'
Fast-Start Failover: ENABLED
Threshold: 120 seconds
Target: oradg1
Observer: backuptest1
Lag Limit: 30 seconds (not in use)
Shutdown Primary: TRUE
Auto-reinstate: TRUE
Configuration Status:
WARNING
SQL> startup mount;
ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance
ORACLE instance started.
Total System Global Area 2138521600 bytes
Fixed Size 2161024 bytes
Variable Size 838862464 bytes
Database Buffers 1258291200 bytes
Redo Buffers 39206912 bytes
Database mounted.
SQL> select db_unique_name,open_mode,database_role,switchover_status,dataguard_broker,primary_db_unique_name from
v$database;
DB_UNIQUE_NAME OPEN_MODE DATABASE_ROLE SWITCHOVER_STATUS DATAGUAR
PRIMARY_DB_UNIQUE_NAME
------------------------------ -------------------- ---------------- -------------------- --------
------------------------------
oradg1 MOUNTED PHYSICAL STANDBY SESSIONS ACTIVE DISABLED oradg2
#primary
SQL> select db_unique_name,open_mode,database_role,switchover_status,dataguard_broker,primary_db_unique_name from
v$database;
DB_UNIQUE_NAME OPEN_MODE DATABASE_ROLE SWITCHOVER_STATUS DATAGUAR
PRIMARY_DB_UNIQUE_NAME
------------------------------ -------------------- ---------------- -------------------- --------
------------------------------
oradg1 MOUNTED PHYSICAL STANDBY NOT ALLOWED ENABLED oradg2
#standby
SQL> select db_unique_name,open_mode,database_role,switchover_status,dataguard_broker,primary_db_unique_name from
v$database;
DB_UNIQUE_NAME OPEN_MODE DATABASE_ROLE SWITCHOVER_STATUS DATAGUAR
PRIMARY_DB_UNIQUE_NAME
------------------------------ -------------------- ---------------- -------------------- --------
------------------------------
oradg2 READ WRITE PRIMARY TO STANDBY ENABLED oradg1
SQL> select fs_failover_status from v$database;
FS_FAILOVER_STATUS
----------------------
SYNCHRONIZED
|
|
IP卡
狗仔卡
发表于 2013-7-30 00:40
）
收藏
提升卡
置顶卡
变色卡
显身卡
楼主
支持