Oracle 11g Dataguard 配置,维护与详解 (ADG)

Posted PigDragon

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Oracle 11g Dataguard 配置,维护与详解 (ADG)相关的知识,希望对你有一定的参考价值。

一、前言:   

    本手册主要记录如何配置,还介绍了配置原因,以及注意要点,已经主备切换,以及故障转移等重要操作步骤,我希望这个文章可以作为进行dataguard配置的一个参考手册。

二、前提

1.主库是归档模式:      

    如果我们不清楚为什么是归档模式,那我们就应该也不会清楚dataguard是用来做什么的。透过很多修饰的官方语言,我们需要明确DG(dataguard简称,后同)实际上的作用就是用来高可用。而实现原理就是从主库获取数据到从库,在主库发生异常的时候,从库接管主库,完成身份的变化。可以一个主库,最多9个从库。同时分为逻辑standby和物理standby这里我们讨论的是物理standby.   一旦创建并配置成 standby 后,dg 负责传输 primary数据库 redo data 到 standby 数据库,standby 数据库通过应用接收到的 redo data 保持与 primary 数据库的事务一致。这下清楚了吧,需要保证主从库一致,需要传输archive log和redo log到从库,如果不是归档模式无法保证主从库的数据一致。本次操作的从库是主库的克隆(在主库导入脚本之前,进行的操作)

步骤:

<1> 在主库上创建归档目录

$ mkdir /oradata/dg

(以Oracle身份进行的创建,若以root身份进行创建需要,修改归档目录的属主属组,让oracle:oinstall,拥有访问的权限)

$sqlplus / as sysdba

$startup mount

$alter system set log_archive_Dest=’/oradata/dg’;

$alter database archivelog

$archive log list;

(此时若主库的归档设置成功,则将出现automatic archival enabled;archive destination /oradata/dg 提示信息)

2.从库只需要安装数据库软件,数据从主库传输后完成。

 备注:(若采用主库的克隆,则无需关心该步骤)

3.ADG备注说明

备注:所谓的ADG,只不过就是在备库,应用redo log 的同事,避免资源的浪费,(10g之前的dg备库必须处于Mount状态,才可以接收应用redo log),11g增加的ADG的功能支持,备库处于open状态(默认为read only模式),同时可以接收并应用redo log

4.主从库硬件最好一致。oracle数据库版本需要一致。  

<1> 内存检查项:

 #grep MemTotal /proc/meminfo      

交换分区检查项:如果内存在1-2G,swap是1.5倍;2-16G,1倍;超过16G,设置为16G即可。     

# grep SwapTotal /proc/meminfo    

查看共享内存大小:    

 # df -h /dev/shm

 <2> 查看系统处理器架构,与oracle安装包一致     

# uname -m

 <3> 空间空间 /tmp必须大于1G     

# df -h /tmp

备注:本次操作过程中对于该目录并未有严格的要求

5.配置环境数据库用户必须有sysdba权限 6.后面的环境:

 主库 10.1.41.81 数据库实例名:ctdb db_unique_name:ctdb  

 从库 10.8.41.81 数据库实例名:ctdb db_unique_name:ctdbdg

三、配置 1.判断DG是否已经安装

  sql>select * from v$option where parameter = ‘Oracle Data Guard‘;   

如果是true表示已经安装可以配置,否则需要安装相应组件。

2.设置主库为强制记录日志  

默认情况下数据库操作会记录redo log,但是在一些特定的情况下可以使用  nologging来不生成redo信息  

<1> 表的批量INSERT(通过/*+APPEND */提示使用“直接路径插入“。或采用SQL*Loader直接路径加载)。表数据不生成redo,但是 所有索引修改会生成redo,但是所有索引修改会生成redo(尽管表不生成日志,但这个表上的索引却会生成redo!)。  

<2> LOB操作(对大对象的更新不必生成日志)。  

<3> 通过CREATE TABLE AS SELECT创建表  

<4> 各种ALTER TABLE操作,如MOVE和SPLIT  

<5> 在一些表迁移和表空间迁移中,可以使用alter table a nologging;或者alter tablespace snk nologging;在操作完成后再修改回logging状态。   这里需要多说一句,如果你使用nologging导入大批量数据,以后对这些数据的修改会在redo或者archive log中,但是基准的数据是没有的,所以一旦介质损坏是无法完全恢复的,必须在使用nologging完成切换回logging后,做一次全备或者0级备份。

  主库步骤如下:

 <1> 强制记录日志:

   sql>alter database force logging;    

<2> 检查状态(YES为强制):

   sql>select name,force_logging from v$database;  

<3> 如果需要在主库添加或者删除数据文件时,这些文件也会在备添加或删除,使用如下:       sql>alter system set standby_file_management=‘AUTO‘;       默认此参数是manual手工方式

sql>show parameter standby  

 3.创建standby log files(备用日志文件)      

从库使用standby log files来保存从主库接收到的重做日志。既然主要是从库在使用,那为什么需要在主库上也建立standby log files?原因主要由两个:一是主库可能转换为备库,而备库是需要有standby log files的 二是如果主库建立了standby log files那备库会自动建立。    

建立standby如要注意以下几点:   

<1> standby log files的大小和redo log files一样,查询redo log files文件大小(默认50M,3个):

Sql>select group#,bytes/1024/1024 as M from v$log     

 <2> 一般而言, standbyredo 日志文件组数要比 primary 数据库的 online redo 日志文件组数至少多一个。推荐 standbyredo 日志组数量基于 primary 数据库的线程数(这里的线程数可以理解为 rac 结构中的 rac节点数)。    有一个推荐的公式可以做参考:(每线程的日志组数+1)*最大线程数

假设现在节点是1个,则=(3+1)*1=4   如果是双节点,=(3+1)*2=8   这里我们创建4个standby logfile:    另:不建议组号group# 紧挨着redo,因为后续redo有可能调整,这里我们从建立从11到14的standby logfile

    sql> alter database add standby logfile group  11 ‘/oradata/dg/standby11.log‘ size 50M;

    sql> alter database add standby logfile group  12 ‘/oradata/dg/standby12.log‘ size 50M;

    sql> alter database add standby logfile group  13 ‘/oradata/dg/standby13.log‘ size 50M;

   sql> alter database add standby logfile group  14 ‘/oradata/dg/standby14.log‘ size 50M;

 4.密码文件和控制文件的创建传输   

<1>一般数据库默认就有密码文件,存放在$ORACLE_HOME/dbs/orapwSID  这里为orapwctdb,如果没有,执行如下操作即可

 sql>orapwd file=$ORACLE_HOME/dbs/orapwctdb password=oracle     

<2> 检查REMOTE_LOGIN_PASSWORDFILE值是否为 EXCLUSIVE        

sql>show parameter REMOTE_LOGIN_PASSWORDFILE      

如果值不是EXCLUSIVE,则:

 Sql>alter system set remote_login_passwordfile=exclusive scope=spfile;   

<3> 密码文件需要scp到从库        

# scp orapwctdb [email protected]:$ORACLE_HOME/db提示输入yes      

<4> 控制文件:        

11g的控制文件一共两份:$ORACLE_BASE/oradata/ctdb/control01.ctl一份在$ORACLE_BASE/flash_recovery_area/ctdb/control02.ctl

 备注:该处的控制文件,我只在$ORACLE_BASE/oradata/ctdb下面找到了两个控制文件,其他地方并未找到

 生成standby控制文件: 

 sql>shutdown immediate

 sql>startup mount

 sql>alter database create standby controlfile as ‘/tmp/standby_control01.ctl‘;

 sql>startup open;  然后在备库建立对应的目录,并授权  $mkdir ctdb

备注:由于我的备库是克隆而来,所以并未执行上述操作

$scp /tmp/standby_control01.ctl [email protected]:/$ORACLE_BASE/oradata/ctdb

$scp /tmp/standby_control01.ctl [email protected]0.8.41.82:/app/oracle/fast_recovery_area/VCDB/controlfile

备注:第二步的复制操作,我执行了,但并不清楚有什么实质性的意义

5.db_name和db_unique_name    

     默认db_name和db_unique_name和实例名是一致的,这里是ctdb需要注意在DG中主库和从库的db_unique_name是不能一致的,需要区分开的。这里我们设置主库的db_unique_name为ctdb,从库为ctdbdg   sql>show parameter db_unique_name   设置:

  Sql>alter system set db_unique_name=ctdb scope=spfile;   

备注:注意虽然默认db_unique_name和db_name是一致的,但是需要显式设置,否则在spfile中没有此参数     

6.闪回数据库:     

强烈建议开启数据库闪回功能。闪回允许你将数据库还原到以前的某一时间点。当发生故障转移时,这个功能非常有用,它能让你将老的主库闪回到故障前,然后将其转换为备库。如果没有启用闪回功能,你就必须重建备库,意味着要再复制一次数据文件。除了这个好处,闪回还能在某些情况下让你避免从备份恢复数据。   

<1> 快速恢复区(Flash/Fast Recovery Area),默认是配置的,但是需要确认这个区域的磁盘够大,至少300G以上(默认3G)   

sql>show parameter db_recovery_file_dest   可以修改位置:

sql>alter system set db_recovery_file_dest=‘新路径‘;     更改大小:

sql>alter system set db_recovery_file_dest_size=400G;

<2> 查看是否启用,默认是不开启的        

sql>select flashback_on from v$database;        开启:

sql>alter database flashback on;       

如果你碰到 ORA-01153 报错,那一定是在备库进行此操作。你需要先取消重做日志应用,启用闪回日志,然后重新启用日志应用。在主库启用闪回日志,不会同步备库也启用。你必须手动在主库和备库上均启用闪回日志。如果不启用闪回日志,当出现故障转移时,你将需要完全重新开始创建一个备库。

备注:本次操作中并未使用闪回区,因为我的服务器上没这么大的空间,可以使用,那也就意味着,如果出failover的现象是,只能对原来主库进行回复之后,只能重新建立ADG关系

7.SQL*NET设置      

<1>配置主库的监听   虽然可以通过netca来进行配置,但是除了这个默认的外,我们还需要一个静态注册SID_LIST_LISTENER,如果没有此从参数而且dataguard启动顺序不正确,主库会报PING[ARC1]:Heartbeat failed to connect to standby‘***‘.Error is 12514导致归档无法完成, 配置如下:

SID_LIST_LISTENER=

     (SID_LIST =

  (SID_DESC =

      (GLOBAL_DBNAME = ctdb)

      (ORACLE_HOME = /app/oracle/product/11.0.4/dbhome_1)

      (SID_NAME = ctdb)

  )

     )

LISTENER =

  (DESCRIPTION_LIST =

    (DESCRIPTION =

      (ADDRESS = (PROTOCOL = TCP)(HOST = CTAuditdb)(PORT = 1521))

      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))

    )

  )

 

ADR_BASE_LISTENER = /app/oracle

#vi $ORACLE_HOME/network/admin/listener.ora 加入上面的内容

<2> 配置tnsnames         

#vi $ORACLE_HOME/network/admin/tnsnames.ora

# tnsnames.ora Network Configuration File: /app/oracle/product/11.0.4/dbhome_1/network/admin/tnsnames.ora

# Generated by Oracle configuration tools.

CTDBDG =

   (DESCRIPTION =

     (ADDRESS_LIST =

       (ADDRESS = (PROTOCOL = TCP)(HOST = 10.8.41.82)(PORT = 1521))

     )

     (CONNECT_DATA =

       (SERVICE_NAME = CTDBDG)

     )

   )

 

 

CTDB =

  (DESCRIPTION =

    (ADDRESS = (PROTOCOL = TCP)(HOST = 10.1.41.82)(PORT = 1521))

    (CONNECT_DATA =

      (SERVER = DEDICATED)

      (SERVICE_NAME = CTDB)

    )

  )

 

<3> 传输到备库并修改listener.ora和tnsnames.ora

scp $ORACLE_HOME/network/admin/listener.ora [email protected]:$ORACLE_HOME/network/admin/

scp $ORACLE_HOME/network/admin/tnsnames.ora [email protected]:$ORACLE_HOME/network/admin/

          

--listener.ora:

  SID_LIST_LISTENER=

     (SID_LIST =

  (SID_DESC =

      (GLOBAL_DBNAME = ctdbdg)

      (ORACLE_HOME = /app/oracle/product/11.0.4/dbhome_1)

      (SID_NAME = ctdb)

  )

     )

LISTENER =

  (DESCRIPTION_LIST =

    (DESCRIPTION =

      (ADDRESS = (PROTOCOL = TCP)(HOST = b_CTAuditdb)(PORT = 1521))

      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))

    )

  )

 

ADR_BASE_LISTENER = /app/oracle    tnsnames.ora:不需要修改

 

  8.重做日志传输配置   

<1>配置归档日志位置:   查询已经设置的归档路径

 sql>archive log list或者show parameter log_archive_dest_1

 sql> alter system set log_archive_dest_1=‘LOCATION=/oradata/dg  valid_for=(all_logfiles,primary_role) db_unique_name=ctdb‘ scope=spfile;  

 还可以使用快速恢复区作为归档目录,LOCATION=use_db_recovery_file_dest,官方文档里说使用 valid_for=(online_logfiles, all_roles),这将导致备库无法归档备用日志文件,因为它们不是在线日志。但如果使用 all_logfiles 选项,主备库将都能归档在线以及备用日志。如果你想在备库进行备份,并同时备份归档日志的话,必须使用 all_logfiles。 

备注:执行该操作之前,需要执行如下操作,否则对主库的归档路径的设置,将会报错

 sql>alter system set log_archive_dest=’’;    

<2>配置重做日志到备份库:

sql>alter system set  log_archive_dest_2=‘SERVICE=ctdbdg lgwr sync valid_for=(online_logfile,primary_role) db_unique_name=ctdbdg ‘ scope=spfile;

<3> 要注意STANDBY_ARCHIVE_DEST 参数不需要,已经被官方弃用。设置此参数后启动数据库,只会报 ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance 错。

 9.配置FAL_SERVER    

 这个参数指定当日志传输出现问题时,备库到哪里去找缺少的归档日志。它用在备库接收的到的重做日志间有缺口的时候。这种情况会发生在日志传输出现中断时,比如你需要对备库进行维护操作。在备库维护期间,没有日志传输过来,这时缺口就出现了。 设置了这个参数,备库就会主动去寻找那些缺少的日志,并要求主库进行传输。你是主库,就填写:fal_server=从库,从库上就反过来:fal_server=主库 注意:FAL_CLIENT在11g中已经废弃,虽然可以配置但是已经不起作用了。

sql>alter system set FAL_SERVER=‘ctdbdg‘;

10.Data Guard 配置里的另外一个库的名字     

sql> alter system set log_archive_config = ‘dg_config=(ctdb,ctdbdg)‘;

备注:以上的办法是我们采用alter system的方式在线修改,还有一种比较方便的办法(但是容易出错,所以方便和安全什么时候都不可兼得)   

sql>create pfile from spfile;    

# 手工修改pfile    

sql>create spfile from pfile;   

然后用pfile生成spfile 同时传输pfile到从库修改后生成spfile注意手工增加:   

*.log_archive_dest_state_1=enable   

*.log_archive_dest_state_2=enable   

#vi initorcl.ora

ctdb.__db_cache_size=1862270976

ctdb.__java_pool_size=16777216

ctdb.__large_pool_size=100663296

ctdb.__oracle_base=‘/app/oracle‘#ORACLE_BASE set from environment

ctdb.__pga_aggregate_target=838860800

ctdb.__sga_target=2516582400

ctdb.__shared_io_pool_size=0

ctdb.__shared_pool_size=503316480

ctdb.__streams_pool_size=0

*.audit_file_dest=‘/app/oracle/admin/ctdb/adump‘

*.audit_trail=‘db‘

*.compatible=‘11.2.0.4.0‘

*.control_files=‘/app/oracle/oradata/ctdb/control01.ctl‘,‘/app/oracle/oradata/ctdb/control02.ctl‘

*.db_block_size=8192

*.db_domain=‘‘

*.db_name=‘ctdb‘

*.db_unique_name=‘CTDB‘

*.diagnostic_dest=‘/app/oracle‘

*.dispatchers=‘(PROTOCOL=TCP) (SERVICE=ctdbXDB)‘

*.fal_server=‘ctdbdg‘

*.log_archive_config=‘dg_config=(ctdb,ctdbdg)‘

*.log_archive_dest=‘‘

*.log_archive_dest_1=‘LOCATION=/oradata/dg valid_for=(all_logfiles,primary_role) db_unique_name=ctdb‘

*.log_archive_dest_2=‘SERVICE=ctdbdg lgwr sync valid_for=(online_logfile,primary_role) db_unique_name=ctdbdg ‘

*.log_archive_dest_state_1=enable

*.log_archive_dest_state_2=enable

*.open_cursors=300

*.pga_aggregate_target=838860800

*.processes=150

*.remote_login_passwordfile=‘EXCLUSIVE‘

*.sga_target=2516582400

*.standby_file_management=‘AUTO‘

*.undo_tablespace=‘UNDOTBS1‘  

 然后sql>create spfile from pfile;   

11.传输主库数据到备库        

<1> 步骤1

scp -l 8192 -rp  /oradata/  [email protected]:/oradata 

scp -l 8192 -rp $ORACLE_BASE/ oradata/ctdb/       [email protected]:$ORACLE_ BASE/oradata/ctdb

-l是limit限制,这样最大是8192/8=1M速度,是为了解决stalled问题, -rp 循环子目录文件

备注:在第二步的操作中注意,首先在备库上把相应目录下的,控制文件进行备库,以免被主库的控制文件覆盖

<2> 建立spfile中需要的目录       

:/opt/oracle/admin/orcl/adump dpdump pfile

备注:本次操作中不需要第二步的操作

12.启用物理备用数据库       

sql>startup nomount       

sql>alter database mount standby database;       

<1> 启动 redo 应用     

sql> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

备注:不需要执行上述步骤      

启动实时应用  

 SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;        这个命令指示备库开始使用备用日志文件进行恢复。它也告诉备库命令完成后回到命令行界面

  SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;     此时只是暂时 redo 应用,并不是停止 Standby 数据库,standby 仍会保持接收只不过不会再应用接收到的归档,直到你再次启动 redo 应用为止

备注:该步骤当需要切换备库的模式时可以使用,比如说从管理模式到,只读模式的转变 

<2> 停止standby         

正常情况下,首先     

 sql> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;    

然后再

sql>shutdown immediate(当然也可以直接shutdown immediate)

 <3> 备用服务器的管理模式与只读模式       

     1> 启动到管理模式

      sql>shutdown immediate;

      sql>startup nomount;

      sql>alter database mount standby database;

      sql>alter database recover managed standby database disconnect from session;

   2> 启动到只读方式    

      sql>shutdown immediate;

      sql>startup nomount;

      sql>alter database mount standby database;

      sql>alter database open read only;

 

   3> 如果在管理恢复模式下到只读模式

      sql>alter system recover managed standby database cancel;

      sql> alter database open read only;

      这个时候,可以给数据库增加临时数据文件(这个在热备份的时候是没有备份过来的)       alter tablespace temp add tempfile ‘/u02/oradata/test/temp01.dbf‘ size 100M;

备注:并未用到该步骤       

  4> 从只读方式到管理恢复方式       

    sql> alter system recover managed standby database disconnect from session;

<4> 在主数据库上设置DataGuard的保护模式.把主数据库启动到mount状态设置好DataGuard的保护模式.

  sql>alter system set log_archive_dest_state_2=ENABLE scope=both;

  sql>shutdown immediate;

  sql>startup mount;

  sql>alter database set standby database to maximize availability;

     sql>alter database open;  

<5> 应用物理备库的几点监控      

 如果上面出了问题或者我们不知道成功了没有,可以用下面的方法检测       

   1> 确认主备库里的归档目的地配置都是有效的         

   sql>select DEST_ID, STATUS, DESTINATION, ERROR from V$ARCHIVE_DEST where DEST_ID<=2;         目的地状态status应该显示为 VALID,注意如果上面没有执行redo应用会有一条error信息   

   2> 确认重做日志是否真的被应用了,在主库执行         

   sql>select SEQUENCE#, FIRST_TIME, NEXT_TIME, APPLIED, ARCHIVED from V$ARCHIVED_LOG where name = ‘JED2‘ order by FIRST_TIME;       如果归档和日志应用均正常,APPLIED 和 ARCHIVED 列都应该是 YES。(如果没有应用redo,applied应该是NO)很多教程里都让这个查询以 SEQUENCE# 列排序,但我不推荐。如果以 SEQUENCE# 列排序,当你做了一次故障转移后,序列号会再从1开始,这时使用这个查询,你将不能在结果最后看到最新的记录。我曾经很奇怪为什么查不到新记录,其实是因为新记录不是出现在最后,我没看到。所以,这个查询都是以 FIRST_TIME 列排序.  

   3> 主库上检查是否有重做日志缺口         

   如果你发现日志没有被应用,那可能是重做日志有了缺口,这种情况下备库无法进行日志应用。但如果你的 FAL_SERVER 参数设置正确,这应该不会有问题         

    sql>select STATUS, GAP_STATUS from V$ARCHIVE_DEST_STATUS where DEST_ID = 2;   如果一切正常,应该返回 VALID 和 NO GAP .切记启用redo应用才能显示No GAP  

   4> 在主备库上执行以下查询查看数据库状态         

    sql>select * from V$DATAGUARD_STATUS order by TIMESTAMP;        

   5> 检查是否成功:         

    主库上查看日志传送情况:        

   sql>select dest_name,status,error from v$archive_dest;         应该log_archive_dest_1和2状态应该是valid    

    切换几次日志:         sql>alter system switch logfile;            查看日志序号:         sql>select sequence# from v$archived_log;             备库验证:         sql>select sequence#,applied from v$archived_log;     

 13.dataguard启动关闭顺序       

<1> 监听    先启从库再起主库        #lsnrctl start          

<2> 启动    

先启从库:     

 sql>startup nomount      

sql>alter database mount standby database;   

sql>alter database recover managed standby database using current logfile disconnect from session;     

 启主库   

sql>startup       

 <3> 关闭:和开启正好相反           

先关主库:       

sql>shutdown immediate       

再关从库:       

sql>alter database recover managed standby database cancel;      

sql>shutdown immediate;

14.Dataguard switchover模式演练

 <1> 操作步骤如下:

  查看主备数据库的状态

 sql>select inst_id,database_role,open_mode from gv$database;

  主库检查switchover 状态如果是to standby或者sessions active表明可以进行切换sessions active意味着主备库有活动sessions关联,在switchover前需要将这些sessions关闭(with session shutdown)。

sql>select switchover_status from v$database;

 主库切换:

 sql>alter database commit to switchover to primary with session shutdown;

备库切换:

sql> alter database commit to switchover to standby with session shutdown ;

原主库mount到standby状态

sql>shutdown abort

sql>startup mount

原主库停止远程归档路径:

sql>alter system set log_archive_dest_state_2=defer;

原主库启用实时查询

sql>alter database revocer managed standby database using current logfile disconnect;

sql>alter database recover managed standby database cancel

sql>alter database open

sql>alter database recover managed standby database using current logfile disconnect

这时新主库状态为to standby,在新备库recovery前,其状态为FAILED DESTINATION,而备库状态为RECOVERY NEEDED。

sql>select switchover_status from v$database;

主库切换几次日志,验证主备库的日志同步情况

主库:

sql>alter system switch logfile

备库:

sql> select sequence#,archived,applied from v$archived_log;

 

15.Dataguard failover模式演练

    Failover的状况有很多,也取决于当时主库的损毁状况以及,当时数据库的搭建方式,这里起其他的方面不再进行演示以及描述如何进行修复,此处仅仅演示了最简单粗暴的一种情形:主库异常宕机,且数据库所在的服务器也异常损毁,该处我们所做的,只针对备库

备库操作:

<1> 查询备库,是否有gap,若有将对应的归档文件copy至备库(前提是主库的归档所在的目录,存在备份,或者不是本地存储,已经完整保存下来了)

sql>select thread#,low_sequence#,hige_sequence# from v$archive_gap;

#若存在gap,copy之后,注册

sql>alter database register physical logfile ‘/oradata/dg/1_38_925143214.dbf’ 

<2> 取消和停止应用

sql> alter database recover managed standby database cancel;

sql> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

#如果主库和备库之间的网络中断了,那么备库的RFS进程就会等待网络的连接,直到TCP超时。此时需要加上force关键字

sql>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH force;

此时standby状态

sql> select open_mode, switchover_status from v$database;

进行切换

sql> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;

<3> 重启数据库

 重启新主库,对外提供服务

sql> shutdown immediate;

ORA-01109: database not open

Database dismounted.

sql> startup

ORACLE instance started.

Total System Global Area  835104768 bytes

Fixed Size                  2257840 bytes

Variable Size             746589264 bytes

Database Buffers           79691776 bytes

Redo Buffers                6565888 bytes

Database mounted.

Database opened.

 

 

<4> Failover后的还原

    由于Failover后主备关系消失,是迫不得已的操作,当主库fix完后,需要重启还原,如果开启了flashback功能,则flashback至Failover时的SCN,再重新应用备库日志。或者重新创建standby,然后再switchover。

使用闪回还原主库:

sql> SELECT to_char(STANDBY_BECAME_PRIMARY_SCN) from V$DATABASE;

sql> SHUTDOWN IMMEDIATE;

sql> STARTUP MOUNT;

sql> FLASHBACK DATABASE TO SCN &standby_became_primary_scn;

#将原主库转换成物理备库,并启动日志应用进程

sql> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

sql> SHUTDOWN IMMEDIATE;

sql> STARTUP MOUNT;

sql> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

备注:本次操作并未启用闪回功能,所以只能重新新建主库,然后才依据上面的ADG搭建的步骤重建主备关系

 

 

 

以上是关于Oracle 11g Dataguard 配置,维护与详解 (ADG)的主要内容,如果未能解决你的问题,请参考以下文章

oracle11g dataguard 完全手册

Oracle 11g Dataguard 配置,维护与详解 (ADG)

在oracle11g中配置多个DataGuard物理备机

Oracle11g搭建DataGuard及主备切换方法总结亲测可用

oracle 11g dataguard之dgmgrl

ORACLE 11G 搭建dataguard详细步骤(所有操作总结)