精华内容
参与话题
问答
  • data guard

    2010-08-03 09:19:12
    data guard 之前,原本已经尝试过配置oracle实例的逻辑和物理standby结构,并且做个一些role交换操作,可是由于昨天学习rman的部分命令时没留意,误删掉了primary DB上的所有归档日...

    data guard

            之前,原本已经尝试过配置oracle实例的逻辑和物理standby结构,并且做个一些role交换操作,可是由于昨天学习rman的部分命令时没留意,误删掉了primary DB上的所有归档日志,因为原来是在maximum protection模式下,standby DB上还存在archivel gap,结果之前搭建的standby实验环境彻底挂了,primary DB也自动停了。我只好把primary DB在nomount模式下改为maximum performance模式,并将控制standby redo log传输的log_archive_dest_state_n设置为defer,才把primary DB启动起来。现在,除了重建standby,还没找到其他的弥补方法,看来对data guard的理解还是停留在照猫画虎的操作上,根本米有理解它的原理啊。所以重新来过,从基础开始好了。

            首先,data guard的主要原理主要是primary DB将所有操作产生的redo log 传输到standby DB上,在由standby DB对此进行应用的。从而产生一个一致的standby DB。在data guard中,存在两类SYNC和ASYNC,下面分别描述两类的工作方法,从而进一步认识它的原理。

             下图是SYNC模式的流程图。
            1、当user 发出 commit命令后,将产生一条 redo record (也称作redo entry)放入SGA中的 redo buffer 中,后台进程LGWR将读取此redo record,将其写入online redo log file。并等待从LNS进程传来的确认信息。
            2、LNS(Log Network Server) 进程同样从redo log buffer读取redo record,并将其通过Oracle Net Services传输给standby DB。在standby DB上的RFS后台进程将接收到的redo record写入standby database中。
            3、当RFS确定写入所有的redo record到磁盘后,向primary DB的LNS发送确认信息。当LGWR收到LNS转发的确认信息后,才返回commit成功的消息给user。
    sync

            接下来来看ASYNC:类似于SYNC,只是primary DB上的LGWR可以不必等待LNS的确认信息,而且LNS可以读取online redo log中的redo record。对于ASYNC,就可以考虑使用压缩方式传输redo record,从而节省带宽,但是这会使CPU的利用升高。此外,如果LNS在读取online redo log中记录时刚好遇到online switch,则可能造成standby的archivelog gap。LNS的不同步记录,在提高性能的同时也可能会产生数据的丢失。

    async

            对于redo log的gap的处理,oracle的data guard有自己的自动处理方法。log file gap主要出现在primary DB上不断有事务被提交,同时,LNS可能由于网络或是standby DB的问题,不能及时同步造成的。此时,primary DB会继续运行,循环使用redo logs,并进行归档。Data Guard会在primary DB上使用一个ARCH进程不断的ping standby DB。当与standby DB可以进行通信时,ARCH的ping进程会通过RFS查询standby的控制文件,获得上一次完成log同步的SCN从而确定从哪一个归档log开始进行同步,从而填补gap。当完成这一步,会自动过度到从当前的日志文件中同步。具体的流程图如下:
    autogap

     

            对于物理standby来说,它应用接受到的redo record是按下图的方式的:
    psdby

            redo apply维持一个standby database是通过精确的物理块来进行primary DB的备份的。RFS进程从primary DB接收到redo record,并将其写入standby redo log(后面将被简称为SRL)。redo apply通过介质恢复,将SRL中的redo record读入内存中,介质恢复协调器(MRP0)管理恢复session,iang具有相同SCN的redo进行合并(这多是在RAC环境中),并分析redo映射到不同的 apply 进程。不同的 apply 进程读取映射的数据块,并将其写入相应改变的数据块。redo apply 会自动设置与cpu数目相等的 apply 进程。

            对于使用 sql apply 的逻辑standby,其具体使用 redo 如下图
    lstdb

            SQL apply使用的是逻辑 standby 进程进行协调应用相应的redo log中的改变。sql apply进程读取SRL,并将其转化为逻辑的记录改变,并建立SQL事务,并应用这些SQL到standby DB上。显然相对于redo apply,sql apply 更耗费cpu、io和内存等资源。

    来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/22123669/viewspace-670046/,如需转载,请注明出处,否则将追究法律责任。

    转载于:http://blog.itpub.net/22123669/viewspace-670046/

    展开全文
  • Data Guard

    2017-04-05 21:50:39
    1:DB_NAME 数据库名字,需要保持同一个Data Guard中所有数据库DB_NAME相同 库和备库相同 DB_NAME='DS' DB_NAME='DS' 2:DB_UNIQUE_NAME ...
    1:DB_NAME
      数据库名字,需要保持同一个Data Guard中所有数据库DB_NAME相同
      库和备库相同
       DB_NAME='DS'
       DB_NAME='DS'
    2:DB_UNIQUE_NAME
      DB_UNIQUE_NAME=unique_service_provider_name_for_this_database
      为每一个数据库指定一个唯一的名称
      主库:
      DB_UNIQUE_NAME=ZH
      备库:
      DB_UNIQUE_NAME=DS
    3:LOG_ARCHIVE_CONFIG
      LOG_ARCHIVE_CONFIG='DG_CONFIG=(db_unique_name,db_unique_name,...)'
      :该参数通过DG_CONFIG属性罗列同一个Data Guard 中所有DB_UNIQUE_NAME
       (含primary db及standby db),以逗号分开
      :主库和备库相同
       LOG_ARCHIVE_CONFIG='DG_CONFIG=(ZH,DS)'
       LOG_ARCHIVE_CONFIG='DG_CONFIG=(ZH,DS)'
    4:CONTROL_FILES
       CONTROL_FILES='control_file_name','control_file_name','...')
       控制文件位置说明,注意要修改到具体的控制文件位置
       主库:
       control_files='/u01/app/oracle/oradata/ORA11GR2/control01.ctl',
       '/u01/app/oracle/oradata/ORA11GR2/control02.ctl'
       备库:
       control_files='/u01/app/oracle/oradata/DS/control01.ctl',
       '/u01/app/oracle/oradata/DS/control02.ctl'
    5:LOG_ARCHIVE_DEST_n
      LOG_ARCHIVE_DEST_n={LOCATION=path_name|SERVICE=service_name,attribute,attribute,...}
      :归档文件的生成路径,location代表本机上,service指明在另一台机器上
       ASYNC:异步,非同步
     主库:
      LOG_ARCHIVE_DEST_1=
       'LOCATION=/u01/arch1/ORA11GR2/
        VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
        DB_UNIQUE_NAME=ORA11GR2'
      LOG_ARCHIVE_DEST_2=
       'SERVICE=DS ASYNC
        VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
        DB_UNIQUE_NAME=DS'
     备库:
      LOG_ARCHIVE_DEST_1=
       'LOCATION=/u01/arch1/DS/
        VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
        DB_UNIQUE_NAME=DS'
      LOG_ARCHIVE_DEST_2=
       'SERVICE=ORA11GR2 ASYNC
        VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
        DB_UNIQUE_NAME=ORA11GR2'
    6:LOG_ARCHIVE_DEST_STATE_n
       LOG_ARCHIVE_DEST_STATE_n={ENABLE|DEFER|ALTERNATE|RESET}
       :指定参数值为ENABLE,激活定义的归档日志目录,允许redo传输服务传输redo数据到指定路径
       ENABLE:启用
       DEFER:推迟 延期
       ALTERNATE:交替 轮换
       RESET:重置
       主库:
       LOG_ARCHIVE_DEST_STATE_1=ENABLE
       LOG_ARCHIVE_DEST_STATE_2=ENABLE
       备库:
       LOG_ARCHIVE_DEST_STATE_1=ENABLE
       LOG_ARCHIVE_DEST_STATE_2=ENABLE
    7:REMOTE_LOGIN_PASSWORDFILE
       REMOTE_LOGIN_RASSWORDFILE={EXCLUSIVE|SHARED|NONE}
       :Whether oracle checks for a password file
        推荐设置参数为EXCLUSIVE或者SHARED,注意保证相同Data Guard配置中所有DB服务器SYS用户密码相同
        主库:
        REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
        备库:
        REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
    8:LOG_ARCHIVE_FORMAT
       LOG_ARCHIVE_FORMAT=log%t_%s_%r.ora
       :指定归档文件格式,这里在主备端应保持一样的格式
       -%t-thread number- 线程数量
       -%s-log sepuence number-日志序列号
       -%r-resetlogs ID-
      主库:
       LOG_ARCHIVE_FORMAT=log%t_%s_%r.ora
      备库: 
       LOG_ARCHIVE_FORMAT=log%t_%s_%r.ora
    9:LOG_ARCHIVE_MAX_PROCESSES
       LOG_ARCHIVE_MAX_PROCESSES=integer 
       :指定归档进程的数量(1-30),默认值通常是4.


    10:COMPATIBLE
       COMPATIBLE=release_number
       :主数据库和备用数据库的Oracle兼容版信息,主备设备必须保持一致
        主库:
        COMPATIBLE='10.2.0.1.0'
        备库:
        COMPATIBLE='10.2.0.1.0'
    11:FAL_SERVER
        FAL_SERVER=oracle_net_service_name
        :备库端的参数,指定一个数据库SID,通常该库为primary角色,
        (FAL 是Fetch Archived Log 的缩写)
        主库:
        主库进行设置,是为了在切换后主备角色互换使用
        FAL_SERVER=DS
        备库:
        FAL_SERVER=ZH
    12:FAL_CLIENT
        FAL_CLIENT=oracle_net_service_name
        :备库端的参数,指定一个数据库的SID,通常该库为standby角色
        主库:
        主库进行设置,是为了在切换之后主备角色互换之后使用
        FAL_CLIENT=ZH
        备库:
        FAL_CLIENT=DS
    13:DB_FILE_NAME_CONVERT
     DB_FILE_NAME_CONVERT=('location_of_primary_database_datafile',
     'location_of_standby_database_datafile','')
     :主数据库和备数据库的数据文件转换目录对映(如果两数据库的目录结构不一样)
     如果有多个对应关系,需要逐一给出。
     主库:
     主库进行设置,是为了在切换后主备角色互换后使用
     DB_FILE_NAME_CONVERT='/u01/app/oraclee/oradata/DS','/u01/app/oracle/oradata/ZH'
     备库:
     DB_FILE_NAME_CONVERT='/u01/app/oracle/oradata/ZH','/u01/app/oracle/oradata/DS'


    14:LOG_FILE_NAME_CONVERT
       LOG_FILE_NAME_CONVERT='location_of_primary_redo_logs','location_of_standby_redo_logs'
       :指明主数据库和备用数据库的log文件转换目录对应关系
       主库:
       主库进行设置,是为了在切换后主备角色互换后的使用
       LOG_FILE_NAME_CONVERT='/u01/app/oracle/oradata/DS','/u01/app/oracle/oradata/ZH'
       备库:
       LOG_FILE_NAME_CONVERT='/u01/app/oracle/oradata/ZH','/u01/app/oracle/oradata/DS'
    15:STANDBY_FILE_MANAGMENT
       STANDBY_FILE_MANAGMENT={AUTO|MANUAL}
       :如果主数据库数据文件发生修改(如新建,重命名等)
       则按照本参数的设置在备库中做相应修改,设为auto表示自动管理
       设为manual表示需要手工管理
       主库:
       主库进行设置,是为了在切换后主备角色互换后使用
       STANDBY_FILE_MANAGMENT=AUTO
       备库:
       STANDBY_FILE_MANAGMENT_AUTO
    16:STANDBY_ARCHIVE_DEST
      STANDBY_ARCHIVE_DEST=filespec
      :备用数据库的归档日志归档目录
      (*该参数从10gR2开始已经可有可无,在11g中,已经弃用--不支持)
      主库:
      STANDBY_ARCHIVE_DEST='/home/oracle/arch/ZH'
      备库:
      STANDBY_ARCHIVE_DEST='/home/oracle/arch/DS'
      

    来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31399171/viewspace-2136669/,如需转载,请注明出处,否则将追究法律责任。

    转载于:http://blog.itpub.net/31399171/viewspace-2136669/

    展开全文
  • 《Oracle Data Guard 11g完全参考手册》由多位顶尖Oracle专家联袂撰写。这本精品指南全面介绍Data Guard无与伦比的数据保护、可用性和灾难恢复功能,详细讲解Data Guard基础知识,列出最佳的配置、监视、维护和故障...
  • 这本精品指南全面介绍data guard无与伦比的数据保护、可用性和灾难恢复功能,详细讲解data guard基础知识,列出最佳的配置、监视、维护和故障排除实践,并指导您部署完美架构以满足灾难恢复目标和其他要求。...
  • 大牛出手,全是干货,Oracle 11gR2使用Active Data Guard 搭建物理 Data Guard。 注:文档打开密码见压缩包注释 看不到注释的 文档打开密码 tianlesoftware
  • DATA GUARD进程体系结构:主要的技术组件Data Guard配置,Data Guard 配置,保护模式,最大保护,最高可用性,最高性能,自动解析差异_处理通信故降,应用服务一重做应用和SQL应用,物理备用数据库一重做应用,将敢...
  • Oracle Data Guard是Oracle数据库主流的高可用与容灾工具,通过Data Guard的主备库模式,可以保护主库数据的数据安全、降低主库负载,是Oracle企业级生产库进行同城容灾、远程容灾、数据保护的有效方案。 本...
  • oracle Data guard 都安装好了,启动顺序是 先启动备库 SQL> startup nomount; SQL>alter database mount standby database ; [color=blue]SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; ...
  • 注:本文为原著(其内容来自 腾科教育培训课堂)。阅读本文注意事项如下: 1:所有文章的转载请标注本文出处。 2:本文非本人不得用于商业用途。违者将承当相应法律责任。 3:该系列文章目录列表:一:《OCM 基本班...




    注:本文为原著(其内容来自 腾科教育培训课堂)。阅读本文注意事项如下:

    1:所有文章的转载请标注本文出处。

    2:本文非本人不得用于商业用途。违者将承当相应法律责任。

    3:该系列文章目录列表:

      一:《OCM 基本班课程表

           二:《OCM_第一天课程:OCM课程环境搭建

           三:《OCM_第二天课程:Section1 —》配置 Oracle 网络环境 

           四:《OCM_第三天课程:Section1 —》表空间的操作和管理、服务配置 

           五:《OCM_第四天课程:Section2 —》GC 的安装和配置

           六: 《OCM_第五天课程:Section2 —》AGENT 的安装 、GC 的使用

          七: 《OCM_第六天课程:Section3 —》数据库可用性

          八:《OCM_第七天课程:Section3 —》数据库可用性

          九:《OCM_第八天课程:Section4 —》数据管理  》

          十: 《OCM_第九天课程:Section4—》OCM课程环境搭建

          十一: 《OCM_第十天课程:Section5—》数据仓库

          十二: 《OCM_第十一天课程:Section5 —》数据仓库

          十三:  《OCM_第十二天课程:Section6 —》数据库性能调优_ 资源管理器/执行计划

          十四:  《OCM_第十三天课程:Section6 —》数据库性能调优 _结果缓存 /多列数据信息采集统计/采集数据信息保持游标有效

           十五:  《OCM_第十四天课程:Section6 —》数据库性能调优_各类索引 /调优工具使用/SQL 优化建议

          十六:   《OCM_第十五天课程:Section6 —》数据库性能调优 _SQL 访问建议 /SQL 性能分析器/配置基线模板/SQL  执行计划管理/实例限制

          十七:   《OCM_第十六天课程:Section7 —》GI 及 ASM 安装配置 _安装 GRID 软件/创建和管理 ASM  磁盘组/创建和管理 ASM 实例

          十八:  《OCM_第十七天课程:Section7 —》GI 及 ASM 安装配置 _管理和配置 GRID /实施 ASM 故障组 /创建 ACFS  文件系统

          十九:   《OCM_第十八天课程:Section8 —》RAC 数据库 _ RAC DB 搭建/RAC DB 配置使用

         二十:   《OCM_第十九天课程:Section9 —》Data Guard _ DATA GUARD 原理/DATA GUARD  应用/DATA GUARD 搭建

         二十一:   《OCM_第二十天课程:Section9 —》Data Guard _ DATA GUARD 搭建/DATA GUARD 管理

         二十二:  《OCM_第二十一天课程:考前辅导 》

          二十三:  《OCM_第  二十二天课程:考前辅导 》

         二十四:   《OCM_第二十三天课程:模拟考试》

         二十五:   《OCM_第二十四天课程:模拟考试》




    Data Guard


     DATA GUARD 原理


     DATA GUARD 应用 


    DATA GUARD 搭建

    转载于:https://www.cnblogs.com/ios9/p/7578711.html

    展开全文
  • 10.2 Data Guard Physical Standby Switchover [ID 751600.1] 修改时间 15-DEC-2009 类型 REFERENCE 状态 PUBLISHED In t...
    10.2 Data Guard Physical Standby Switchover [ID 751600.1]

    修改时间 15-DEC-2009 类型 REFERENCE 状态 PUBLISHED

    In this Document
    Purpose
    10.2 Data Guard Physical Standby Switchover
    1.0 Prerequisites / Preparation
    2.0 Pre-Switchover Checks
    3.0 Switchover
    4.0 Post-Switchover Steps
    5.0 Create a Guaranteed Restore Point on Each Switchover Database
    6. References


    Applies to:

    Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 10.2.0.4
    Information in this document applies to any platform.

    Purpose

    This note is intended as an accessory to the following resources:

    The goal of this document is be used as a basis to in developing your own robust switchover procedure.

    Oracle strongly recommends you apply the latest patchset/bundle patch for your version prior to proceeding.

    10.2 Data Guard Physical Standby Switchover

    1.0 Prerequisites / Preparation

    These are items that should only have to be done once during configuration and setup.

    1.1. Apply Latest Patch Bundle

    • Review the Document 466181.1 "10g Upgrade Companion", and make sure to check the “Patches Recommended” tab.
    • See Document 756671.1 for the latest available patches or patchset updates.
    1.2. Setup Service Relocation for a Local Standby (optional)

    See Data Guard Switchover and Failover MAA paper.

    1.3. Review the MAA Best Practice Papers

    See the References section.

    1.4. Review MAA Data Guard Best Practices

    In the 10g High Availability Best Practices 10g Release 2 (10.2) guide see 2.4 Configuring Oracle Database 10g with Data Guard

    1.5. Verify the Setup
    1.5.1. With Broker

    1. Review Prerequisites for First Use
    2. Enable Broker to restart instances

    To enable DGMGRL to restart instances during the course of broker operations, a service with a specific name must be statically registered with the listener of each instance. The value for the GLOBAL_DBNAME attribute must be set to a concatenation of db_unique_name_DGMGRL.db_domain. For example, in the LISTENER.ORA file:
    LISTENER = (DESCRIPTION =
    (ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST=)
    (PORT=))))
    SID_LIST_LISTENER=(SID_LIST=(SID_DESC=
    (SID_NAME=)
    (GLOBAL_DBNAME=_DGMGRL.db_domain)
    (ORACLE_HOME=)))

    1.5.2. Without Broker

    Follow the steps at Verify the Physical Standby Database Is Performing Properly
    1.6. Understand and test fallback options

    See 11.1 guide, Failed Switchovers to Physical Standby Databases. Still applies to 10.2 as well.

    Check DG Admin troubleshooting guide, Problems Switching Over to a Standby Database.

    2.0 Pre-Switchover Checks

    These steps should be completed before the switchover planned maintenance window begins. Recommendation is that these are done a couple days in advance.

    2.1. Verify Configuration Health
    2.1.1 With Broker
    2.1.1.1 Verify Data Guard Environment Health

    CLI - see Monitoring a Data Guard Configuration

    GUI - see "Verifying a Broker Configuration" The broker health check performs the following:

    Shows the current data protection mode setting, including the current redo transport service settings for each database and whether or not the standby redo log files are configured properly. If standby redo log files are needed for any database, the Verify results will allow you to automatically configure them.
    • Validates each database for the current status.
    • Performs a log switch on the primary database and then verifies that the log file was applied on each standby database.
    • Shows the results of the Verify operation, including errors, if any. The Verify operation completes successfully if there are no errors and an online redo log file was successfully applied to at least one standby database.
    • Shows any databases or RAC instances that are not discovered. Undiscovered databases and instances could prevent a failover or switchover from completing successfully.
    • Detects inconsistencies between database properties and their corresponding values in the database itself. It also provides a mechanism for resolving these inconsistencies.
    2.1.1.2. Cancel apply delay for the target standby using CLI or GUI

    Note: if flashback database is not enabled as part of normal operations then canceling any apply delay should be done just prior to a switchover to maintain standby delay protection for any possible primary database issues.

    On the standby Capture the current value

    DGMGRL> SHOW DATABASE DELAYMINS;

    On the standby turn off any delay

    CLI – DGMGRL> EDIT DATABASE ‘’ SET PROPERTY 'DELAYMINS'='0';

    GUI – See Changing the Properties of a Database
    2.1.2. Without Broker
    2.1.2.1. Verify Managed Recovery is Running (non-broker) on the standby

    SQL> SELECT PROCESS
    FROM V$MANAGED_STANDBY
    WHERE PROCESS LIKE 'MRP%';

    2.1.2.2. Cancel apply delay for the target standby using SQL

    On the target physical standby database capture the current delay value

    SQL> SELECT DELAY_MINS
    FROM V$MANAGED_STANDBY
    WHERE PROCESS = 'MRP0';

    On the target physical standby database turn off delay if > 0

    SQL> RECOVER MANAGED STANDBY DATABASE CANCEL

    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY USING CURRENT LOGFILE DISCONNECT FROM SESSION;
    2.2. Ensure Online Redo Log Files on the Target Physical Standby have been cleared

    Online redo logs on the target physical standby need to be cleared before that standby database can become a primary database. Although this will automatically happen as part of the SWITCHOVER TO PRIMARY command, it is recommended that the logs are cleared prior to the switchover. If you have set the LOG_FILE_NAME_CONVERT parameter in the spfile, online redo logs will be automatically cleared the first time managed recovery is started on the standby.

    Oracle recommends setting LOG_FILE_NAME_CONVERT to automatically clear online redo logs on the physical standby database. In the event the primary database and the physical standby database have the exact same directory path to the online redo logs, it is acceptable to set LOG_FILE_NAME_CONVERT such that the entry pairs have the same value.

    As an example, if the online redo logs are stored in /oradata/order_db/redo for both the primary and physical standby databases on their respective servers, you can set the parameter value as

    LOG_FILE_NAME_CONVERT=’/oradata/order_db/redo/’,’/oradata/order_db/redo/’

    This will initiate automatic clearing of the online redo logs on the physical standby database when managed recovery is started.

    Clearing online redo logs as part of the SWITCHOVER TO PRIMARY command can make the switchover command susceptible to termination by another process that is waiting on access to the CONTROLFILE. The CONTROLFILE waiter will attempt to kill the switchover after a timeout is 15 minutes.

    If you have not set your environment to automatically clear the online redo logs you should manually clear them at some point prior to the switchover. This can be done at any time.

    On the target physical standby run the following query to determine if the online redo logs have not been cleared:

    SQL> SELECT DISTINCT L.GROUP#
    FROM V$LOG L, V$LOGFILE LF
    WHERE L.GROUP# = LF.GROUP#
    AND L.STATUS NOT IN (‘UNUSED’, ‘CLEARING’,’CLEARING_CURRENT’);

    If the above query returns rows, on the target physical standby issue the following statement for each GROUP# returned:

    SQL> ALTER DATABASE CLEAR LOGFILE GROUP ;

    If the switchover is performed using SQL*Plus is terminated by a CONTROLFILE waiter timeout, just re-issue the SWITCHOVER TO PRIMARY command until it completes successfully. If you encounter the timeout while attempting a switchover using Data Guard Broker, you must go into SQL*Plus, attaching to the target physical standby database and re-issue the SWITCHOVER TO PRIMARY command until it completes successfully. You must then drop and recreate your Broker configuration.

    In both cases, you should monitor your alert log to ensure your online redo logs are being cleared and you are not experiencing some other issue.

    2.3. Check for Previously Disabled Redo Threads

    This check is to evaluate if you are vulnerable to Bug 6266023 (fixed in 10.2.0.4.2 patchset) which will cause a switchover to fail..

    To determine if this situation exists, on your primary database, first run the following query to determine if there are any threads with a SEQUENCE# greater than 0:

    SQL> SELECT THREAD#
    FROM V$THREAD
    WHERE SEQUENCE# > 0;

    On the primary database, determine the current database redo branch:

    SQL> SELECT TO_CHAR(RESETLOGS_CHANGE#)
    FROM V$DATABASE_INCARNATION
    WHERE STATUS = ‘CURRENT’;

    Any of the threads identified by the first query are disabled provided there are no archive log or log history records in the control file of the target physical standby database on the current branch of redo on the primary.

    To determine this, substitute the resetlogs_change# from the primary database (found in the second query) into the query below and execute it on the target physical standby database for each thread reported from the first query above.

    SQL> SELECT ‘CONDITION MET’
    FROM SYS.DUAL
    WHERE NOT EXISTS (SELECT 1
    FROM V$ARCHIVED_LOG
    WHERE THREAD# =
    AND RESETLOGS_CHANGE# = )
    AND NOT EXISTS (SELECT 1
    FROM V$LOG_HISTORY
    WHERE THREAD# =
    AND RESETLOGS_CHANGE# = );

    If this query returns a row for any of the threads, you have a disabled thread with a non-zero SEQUENCE# that can prevent a switchover from the primary database to the physical standby database. In this case, you must apply the latest patchset or use one of the following workarounds:

    Workaround 1 – Does not require primary database downtime

    Briefly enable the previously disabled thread(s) and switch logs on the primary database to send logs and populate entries into V$ARCHIVED_LOG and V$LOG_HISTORY on the physical standby database. This workaround does not require downtime on the primary database, but it is not a permanent workaround. Until either the 10.2.0.4.2 or higher patchset is applied or the second workaround listed is performed, you would need to perform these steps prior to every switchover. Log shipping and managed recovery should remain on during this process.

    1. At primary enable the disabled threads and switch logs. The multiple disable/enable and switch logfile commands are required to ensure all manner of disabled threads (internally disabled and externally disabled) are handled correctly.

    On the primary database, enable each of the disabled threads;
    SQL> ALTER DATABASE DISABLE THREAD ;
    SQL> ALTER DATABASE ENABLE THREAD ;
    SQL> ALTER DATABASE DISABLE THREAD ;
    SQL> ALTER DATABASE ENABLE THREAD ;

    Perform the following 4 times on the primary database:

    SQL> ALTER SYSTEM SWITCH LOGFILE;

    Do the following 1 time on the primary database:

    SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

    2. Verify that the primary has archived a log for the thread(s);

    On the primary database issue the following;
    SQL> SELECT THREAD#, MAX(SEQUENCE#)
    FROM V$LOG_HISTORY
    WHERE RESETLOGS_CHANGE# =
    (SELECT RESETLOGS_CHANGE#
    FROM V$DATABASE_INCARNATION
    WHERE STATUS = ‘CURRENT’)
    GROUP BY THREAD#;

    SQL> SELECT THREAD#, MAX(SEQUENCE#)
    FROM V$ARCHIVED_LOG
    WHERE RESETLOGS_CHANGE# =
    (SELECT RESETLOGS_CHANGE#
    FROM V$DATABASE_INCARNATION
    WHERE STATUS = ‘CURRENT’)
    GROUP BY THREAD#;

    3. Ensure that redo apply has progressed through the enabled thread logs:

    Connect to the primary database and issue;
    SQL> SELECT TO_CHAR(RESETLOGS_CHANGE#)
    FROM V$DATABASE_INCARNATION
    WHERE STATUS = ‘CURRENT’;

    Connect to target physical standby database and issue;
    SQL> SELECT THREAD#,MAX(SEQUENCE#)
    FROM V$LOG_HISTORY
    WHERE RESETLOGS_CHANGE# =
    GROUP BY THREAD#;

    SQL> SELECT THREAD#, MAX(SEQUENCE#)
    FROM V$ARCHIVED_LOG
    WHERE RESETLOGS_CHANGE# =
    GROUP BY THREAD#;

    NOTE: Both these queries should return values for the threads enabled in step 1.

    4. On the primary database, disable the threads enabled in step 1 (run the DISABLE for each thread);
    SQL> ALTER DATABASE DISABLE THREAD ;

    SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;

    5. Verify, by repeating step 2, the primary has archived the logs of the disabled thread(s). The last query may need to be run a few times to give time for the final archival to complete. The output from the two queries should match once the archiving is caught up.

    6. Repeat step 3 to ensure that the standby has received and applied through all the logs from the disabled threads.

    7. Repeat Section 2.1, "Verify Configuration Health" and proceed to Section 2.4, "Check if the standby has ever been open read-only"

    Workaround 2 – Requires primary database downtime

    Reset the SEQUENCE# to 0 for the disabled threads by opening the primary database with the RESETLOGS option. This workaround is a permanent fix, however it requires downtime on the primary database. Log shipping should remain on during this process.
    1. If using the Data Guard Broker, use dgmgrl to connect to the primary database and disable the configuration
      DGMGRL> DISABLE CONFIGURATION;
    2. At each physical standby database, stop the managed recovery process
      SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

      Ensure managed recovery has been stopped.
      SQL> SELECT *
      FROM GV$MANAGED_STANDBY
      WHERE PROCESS = ‘MRP0’;
    3. At the primary database, switch logfiles 2 times to ensure the primary database has advanced beyond the point managed recovery has recovered to on the physical standby database(s).
      SQL> ALTER SYSTEM SWITCH LOGFILE;
      SQL> ALTER SYSTEM SWITCH LOGFILE;
    4. This process requires a clean shutdown of the primary database.
      Shutdown each instance of the primary database normal
      SQL> SHUTDOWN IMMEDIATE
    5. Start one instance of the primary database in mount mode
      SQL> STARTUP MOUNT
    6. Start recovery on this primary database instance. No actual recovery will be performed, this is to prepare for opening the database with RESETLOGS.
      SQL> RECOVER DATABASE UNTIL CANCEL;

      Media recovery complete.
    7. Open the primary database with RESETLOGS option.
      SQL> ALTER DATABASE OPEN RESETLOGS;
    8. Generate an archive log file from the primary database:
      SQL> ALTER DATABASE ARCHIVE LOG CURRENT;
    When the standby database recognizes the new redo branch, media recovery will return an ORA-19906 error, this is expected. The alert log for the standby database will show something similar to:

    MRP0: Incarnation has changed! Retry recovery...
    Wed Dec 2 06:47:52 2009
    Errors in file /ade/mgirkar_103/oracle/rdbms/log/x1032_mrp0_13389.trc:
    ORA-19906: recovery target incarnation changed during recovery

    Managed Standby Recovery not using Real Time Apply
    Recovery interrupted!
    Wed Dec 2 06:47:54 2009
    Errors in file /ade/mgirkar_103/oracle/rdbms/log/x1032_mrp0_13389.trc:
    ORA-19906: recovery target incarnation changed during recovery

    Wed Dec 2 06:48:14 2009
    Managed Standby Recovery starting Real Time Apply
    Media Recovery apply resetlogs offline range for datafile 1, incarnation : 0
    Media Recovery apply resetlogs offline range for datafile 2, incarnation : 0
    Media Recovery apply resetlogs offline range for datafile 3, incarnation : 0
    Media Recovery apply resetlogs offline range for datafile 4, incarnation : 0
    Media Recovery apply resetlogs offline range for datafile 5, incarnation : 0
    parallel recovery started with 2 processes
    Media Recovery Log /ade/mgirkar_103/oracle/work/arc_save/db2r_602567e5_1_1_704530059.arc
    Media Recovery Waiting for thread 1 sequence 2 (in transit)
    9. Ensure both the primary and the physical standby database are on the same redo branch.
    On both the primary and physical standby database, issue the following query:

    SQL> SELECT TO_CHAR(RESETLOGS_CHANGE#), RESETLOGS_TIME
    FROM V$DATABASE_INCARNATION
    WHERE STATUS = ‘CURRENT’;

    The new branch of redo should be clearly identified by the RESETLOGS_TIME. If the new branch does not appear on the physical standby, do not continue, instead investigate why the new redo branch has not registered at the physical standby database.

    NOTE: It may take a few moments for the physical standby to receive the logs from the primary database and recognize the change in branch.
    10. Restart the managed recovery process.
    a. If using Data Guard Broker, use dgmgrl to connect to the primary database and re-enable the configuration disabled as part of the first step of this workaround. Enabling the configuration will also start the managed recovery process.
    DGMGRL> ENABLE CONFIGURATION;
    a. If managing the configuration using SQL*Plus, connect to the physical standby database(s) and restart the managed recovery process.
    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY USING CURRENT LOGFILE DISCONNECT FROM SESSION;
    11. Repeat Section 2.1, "Verify Configuration Health" and proceed to Section 2.4, "Check if the standby has ever been open read-only"

    2.4. Check if the standby has ever been open read-only

    On the target physical standby database run this query:

    SQL> SELECT VALUE
    FROM V$DATAGUARD_STATS
    WHERE NAME='standby has been open';

    If the target physical standby was open read-only then restart the standby

    SQL> SHUTDOWN IMMEDIATE

    SQL> STARTUP MOUNT

    2.5. Verify there are no large GAPS.

    Identify the current sequence number for each thread on the primary database

    SQL> SELECT THREAD#, SEQUENCE#

    FROM V$THREAD;

    Verify the target physical standby database has applied up to, but not including the logs from the primary query. On the standby the following query should be no more than 1-2 less than the primary query result.

    SQL> SELECT THREAD#, MAX(SEQUENCE#)
    FROM V$ARCHIVED_LOG
    WHERE APPLIED = 'YES'
    AND RESETLOGS_CHANGE# = (SELECT RESETLOGS_CHANGE#
    FROM V$DATABASE_INCARNATION
    WHERE STATUS = ‘CURRENT’)
    GROUP BY THREAD#;

    If large gaps exist (more than 3 logs) then consult the Oracle® Data Guard Concepts and Administration, 10g Release 2 (10.2) guide: Section 5.8 Section 12.11 “Resolving Archive Gaps Manually”. If the gap is not resolved by Data Guard automatically then consult, “Manually Determining and Resolving Archive Gaps”.

    If a large redo apply lag (greater than 2 logs) persists then review the MAA best practice paper, “Data Guard Redo Apply & Media Recovery” and also consult the Oracle® Data Guard Concepts and Administration 11g Release 1 (11.1) guide to monitor in more detail, 9.5 Monitoring Primary, Physical Standby.

    2.6. Use “THROUGH ALL SWITCHOVER” on Bystander Standbys

    Redo apply should be started with the “THROUGH ALL SWITCHOVER ” clause at each standby database in the configuration. The Broker starts managed recovery with the “THROUGH ALL SWITCHOVER” clause.
    See Managing Data Guard Configurations Having Multiple Standby Databases - Best Practices for details.

    2.7. Verify Primary and Standby TEMP Files Match

    On the standby for each temporary tablespace, verify that temporary files associated with that tablespace on the primary database also exist on the standby database. Temp files added after initial standby creation are not propagated to the standby. Run this query on both the primary and target physical standby databases and verify that they match.

    SQL> SELECT TMP.NAME FILENAME, BYTES, TS.NAME TABLESPACE
    FROM V$TEMPFILE TMP, V$TABLESPACE TS
    WHERE TMP.TS#=TS.TS#;

    If the queries do not match then you can correct the mismatch now or immediately after the open of the new primary.

    To correct now: add or delete a tempfile now requires managed recovery to be stopped and the standby to be open read only. Opening the standby read-only will require a database close and open before becoming the new primary, see “Open the new primary database”.

    To correct post-primary-open: see “Correct any tempfile mismatch” step of Switchover

    2.8. Verify that there is no issue with V$LOG_HISTORY on the Standby

    (Bug 6010833, 10.2.0.3 patch available on Linux 32-bit, this is included in the 6081547 patch bundle (Document 6081547.8) listed above under “Apply Latest Patch Bundle”. It is assumed any potential issues with “Check for Previously Disabled Redo Threads” have already been resolved.)

    Determine threads that have been active at some point on the primary database:

    SQL> SELECT THREAD#, SEQUENCE#
    FROM V$THREAD
    WHERE SEQUENCE# > 0;

    Get the RESETLOGS_CHANGE# from the primary database:
    SQL> SELECT RESETLOGS_CHANGE#
    FROM V$DATABASE_INCARNATION
    WHERE STATUS = ‘CURRENT’;

    On the target physical standby database, get the maximum sequence numbers for each thread from V$LOG_HISTORY:
    SQL> SELECT THREAD#, MAX(SEQUENCE#)
    FROM V$LOG_HISTORY
    WHERE RESETLOGS_CHANGE#=< resetlogs_change# from the primary V$DATABASE_INCARNATION.RESETLOGS_CHANGE# >
    GROUP BY THREAD#;

    The last SEQUENCE# for each THREAD# from V$LOG_HISTORY on the target physical standby database should be close (the difference in log sequences < 3) to the SEQUENCE# for each THREAD# from V$THREAD on the primary database. If the difference in log sequences is greater than 3 or no row is returned for the thread, you have encountered this problem and should recreate the standby controlfile. See Note 459411.1. If backups are being done on the standby without an RMAN Catalog then backup history will be lost. It is highly recommended to use an RMAN Catalog for all backups.

    2.9.Verify no old partial Standby Redo Logs on the Standby

    (Bug 7159505, fixed in 10.2.0.5 and 11.1.0.7; 10.2.0.3 patch available on Solaris Sparc64 and can be requested for other platforms. This patch conflicts with the 6081547 patch bundle (Document 6081547.8) and would require a patch merge request if you want to apply this on top of the 6081547 patch bundle (Document 6081547.8) .)

    Get the RESETLOGS_CHANGE# from the primary database:
    SQL> SELECT RESETLOGS_CHANGE#
    FROM V$DATABASE_INCARNATION
    WHERE STATUS = ‘CURRENT’;

    On the target physical standby database, identify any active standby redo logs (SRL’s)
    SQL> SELECT GROUP#, THREAD#, SEQUENCE#
    FROM V$STANDBY_LOG
    WHERE STATUS = 'ACTIVE'
    ORDER BY THREAD#,SEQUENCE#;

    On the target physical standby database, identify maximum applied sequence number(s).
    SQL> SELECT THREAD#, MAX(SEQUENCE#)
    FROM V$LOG_HISTORY
    WHERE RESETLOGS_CHANGE#=< resetlogs_change# from the primary V$DATABASE_INCARNATION.RESETLOGS_CHANGE# >
    GROUP BY THREAD#;

    If there are any active SRL's that have a thread#/sequence# less than the thread#/sequence# returned from the V$LOG_HISTORY (meaning the recovery has progressed beyond the active SRL) query, clear them on the target physical standby.

    SQL> RECOVER MANAGED STANDBY DATABASE CANCEL

    SQL> ALTER DATABASE CLEAR LOGFILE GROUP ;

    3.0 Switchover

    3.1. Clear Potential Blocking Parameters & Jobs

    Capture current job state on the primary

    SQL> SELECT *
    FROM DBA_JOBS_RUNNING; [depending on what the running job is, be ready to terminate]

    SQL> SELECT OWNER, JOB_NAME, START_DATE, END_DATE, ENABLED
    FROM DBA_SCHEDULER_JOBS
    WHERE ENABLED=’TRUE’
    AND OWNER <> ‘SYS”;

    SQL> SHOW PARAMETER job_queue_processes

    Note: cron job candidates to be disabled among others: oracle text sync and optimizer, RMAN backups, application garbage collectors, application background agents.

    Block further job submission

    SQL> ALTER SYSTEM SET job_queue_processes=0 SCOPE=BOTH SID=’*’;

    SQL> EXECUTE DBMS_SCHEDULER.DISABLE( );

    Disable any cron jobs that may interfere.

    3.2. Shutdown all mid-tiers (optional)

    This can be done in parallel to the switchover.

    $ opmnctl stopall

    Note: If using a local standby with an application that is following the “Client Failover in Data Guard Configurations for Highly Available Oracle Databases” paper recommendations to utilize a database startup trigger that ensures the application database service is only active on the primary, this step can be skipped.

    3.3. Monitor Switchover
    3.3.1. With Broker
    3.3.1.1. Turn on Data Guard tracing on primary and standby

    Capture the current value for each instance

    DGMGRL> SHOW INSTANCE LogArchiveTrace;

    Set Data Guard trace level to 8191 for each instance

    DGMGRL> EDIT INSTANCE SET PROPERTY LogArchiveTrace=8191;

    Trace output will appear under the destination pointed to by the database parameter BACKGROUND_DUMP_DEST with “mrp” in the file name.

    3.3.1.2. Tail Broker Logs (optional) on all instances

    Locate Broker logs by showing database parameter background_dump_dest

    SQL> SHOW PARAMETER background_dump_dest

    Tail the broker logs

    > tail –f /dr*
    3.3.2. Without Broker
    3.3.2.1. Turn on Data Guard tracing on primary and standby

    Tracing is turned on to have diagnostic information available in case any issues arise. Turning on tracing does not have any noticeable impact on switchover time but does require space for the trace output.

    Capture the current value on both the primary and the target physical standby databases

    SQL> SHOW PARAMETER log_archive_trace

    Set Data Guard trace level to 8191 on both the primary and the target physical standby databases

    SQL> ALTER SYSTEM SET log_archive_trace=8191;

    Trace output will appear under the destination pointed to by the database parameter BACKGROUND_DUMP_DEST with “mrp” in the file name.
    3.3.3. Tail Primary and Standby alert logs on all instances

    Locate alert logs by showing database parameter background_dump_dest on both the primary and the target physical standby databases

    SQL> SHOW PARAMETER background_dump_dest

    Tail the alert log on both the primary and the target physical standby databases

    > tail –f /al*
    3.4. Create Guaranteed Restore Points (optional)

    The standard switchover fallback options should suffice for successfully backing out of a switchover. However, if you want an additional fallback option then you can create a guaranteed restore point on the primary and standby database participating in the switchover. If you want to do this see “Create a Guaranteed Restore Point on Each Switchover Database” for details. If a guaranteed restore point is created, make sure it is dropped post-switchover.

    3.5. Switchover
    3.5.1. With Broker
    3.5.1.1. Data Guard Broker command line utility

    See Performing a Switchover Operation

    Connect to the primary database using the DGMGRL command line utility as sys using the same password as the sys user on the primary and standby databases

    Issue the switchover to command:

    DGMGRL> SWITCHOVER TO ;

    3.5.1.2. EM switchover

    To start a switchover using Enterprise Manager, select the standby database that you want to change to the primary role and click Switchover.

    Note: Following the open of the new primary there will be an increase in I/O while the new primary’s standby redo logs are cleared.
    3.5.2. Without Broker
    3.5.2.0. Verify that the primary database can be switched to the standby role

    Query the SWITCHOVER_STATUS column of the V$DATABASE view on the primary database. For example:
    SQL> SELECT SWITCHOVER_STATUS
    FROM V$DATABASE;

    SWITCHOVER_STATUS
    -----------------
    TO STANDBY

    A value of TO STANDBY or SESSIONS ACTIVE (requires the WITH SESSION SHUTDOWN clause on the switchover command) indicates that the primary database can be switched to the standby role. If neither of these values is returned, a switchover is not possible because redo transport is either mis-configured or is not functioning properly. See Chapter 5 of the "Oracle® Data Guard Concepts and Administration, 10g Release 1 (10.2)" guide for information about configuring and monitoring redo transport.

    3.5.2.1. If RAC, then shutdown all secondary primary instances

    A normal shutdown can be done, but to expedite the shutdown issue a SHUTDOWN ABORT on secondary RAC instances on the primary only

    3.5.2.2. Switchover the primary to a standby database

    SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY WITH SESSION SHUTDOWN;

    If an ORA-16139 is encountered, as long as V$DATABASE.DATABASE_ROLE=’PHYSICAL STANDBY’, then you can proceed. A common case where this can occur is when there are a large number of data files, greater than 1,000, the apply of the EOR log will timeout.. Once managed recovery is started on the new standby it will recover.

    If the role was not changed then you need to cancel the switchover and review the alert logs and trace files further.

    3.5.2.3. Verify the standby has received the end-of-redo (EOR) log(s)

    In the primary alert log you should see messages like this:

    Mon Nov 3 06:53:13 2008
    ARCH: Noswitch archival of thread 1, sequence 21
    ARCH: End-Of-Redo Branch archival of thread 1 sequence 21
    ARCH: Archiving is disabled due to current logfile archival
    Clearing standby activation ID 2821924805 (0xa83327c5)
    The primary database controlfile was created using the
    'MAXLOGFILES 192' clause.
    There is space for up to 188 standby redo logfiles
    Use the following SQL commands on the standby database to create
    standby redo logfiles that match the primary database:
    ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 524288000;

    Archivelog for thread 1 sequence 21 required for standby recovery
    Switchover: Primary controlfile converted to standby controlfile succesfully.
    MRP0 started with pid=18, OS id=32583
    Mon Nov 3 06:53:15 2008
    MRP0: Background Managed Standby Recovery process started (sfs_stby1)
    Mon Nov 3 06:53:20 2008
    Managed Standby Recovery not using Real Time Apply
    Mon Nov 3 06:53:20 2008
    parallel recovery started with 3 processes
    Online logfile pre-clearing operation disabled by switchover
    Media Recovery Log +REGR/sfs_stby/archivelog/2008_11_03/thread_1_seq_21.258.669
    97593
    Identified End-Of-Redo for thread 1 sequence 21
    Mon Nov 3 06:53:21 2008
    Media Recovery End-Of-Redo indicator encountered
    Mon Nov 3 06:53:21 2008
    Media Recovery Applied until change 8338654
    Mon Nov 3 06:53:21 2008
    MRP0: Media Recovery Complete: End-Of-REDO (sfs_stby1)
    Resetting standby activation ID 2821924805 (0xa83327c5)
    Mon Nov 3 06:53:21 2008
    MRP0: Background Media Recovery process shutdown (sfs_stby1)
    Mon Nov 3 06:53:22 2008
    SUCCESS: diskgroup REGR was dismounted
    Mon Nov 3 06:53:22 2008
    Switchover: Complete - Database shutdown required (sfs_stby1)
    Mon Nov 3 06:53:22 2008
    Completed: ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY WITH SESSION SHUTDOWN

    And correspondingly in the standby alert log file you should see messages like this:

    Mon Nov 3 06:53:17 2008
    Media Recovery Log +REGR2/sfs/archivelog/2008_11_03/thread_1_seq_21.3819.669797593
    Identified End-Of-Redo for thread 1 sequence 21
    Mon Nov 3 06:53:17 2008
    Media Recovery End-Of-Redo indicator encountered
    Mon Nov 3 06:53:17 2008
    Media Recovery Applied until change 8338654
    Mon Nov 3 06:53:17 2008
    MRP0: Media Recovery Complete: End-Of-REDO (sfs1)
    Resetting standby activation ID 2821924805 (0xa83327c5)
    Mon Nov 3 06:53:19 2008
    MRP0: Background Media Recovery process shutdown (sfs1)

    3.5.2.4. If the standby is a RAC configuration, then shutdown all secondary standby instances

    A normal shutdown can be done, but to expedite this operation, issue a SHUTDOWN ABORT on the secondary non-apply RAC instances.

    3.5.2.5. Verify that the standby database can be switched to the primary role

    Query the SWITCHOVER_STATUS column of the V$DATABASE view on the standby database. For example:
    SQL> SELECT SWITCHOVER_STATUS
    FROM V$DATABASE;

    SWITCHOVER_STATUS
    -----------------
    TO PRIMARY

    A value of TO PRIMARY or SESSIONS ACTIVE indicates that the standby database is ready to be switched to the primary role. If neither of these values is returned, verify that redo apply is active and that redo transport is configured and working properly. Continue to query this column until the value returned is either TO PRIMARY or SESSIONS ACTIVE.

    3.5.2.6. Check if the standby has ever been open read-only

    If the target physical standby has been open read-only (found in Pre-Switchover check 2.5) and you have not bounced the target physical standby, do so now.

    3.5.2.7. Switchover the standby database to a primary

    SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

    3.5.2.8. Open the new primary database:

    SQL> ALTER DATABASE OPEN;

    Note: Beginning with Oracle Database 10g Release 2, you can open the new production database directly from the mount state if the standby database was not opened read-only since the last time the database was started. If the database has been opened read-only, it will need to be restarted.

    Note: There will be an increase in I/O while the new primary’s standby redo logs are cleared.

    3.5.2.9. Correct any tempfile mismatch

    If there was a tempfile mismatch in Pre-switchover check, “Verify Primary and Standby TEMP Files Match” that was not corrected then correct it now on the new primary.

    3.5.2.10. Restart the new standby

    On the the new standby database (old production database), bring it to the mount state and start managed recovery. This can be done in parallel to the new primary open.

    SQL> SHUTDOWN IMMEDIATE;

    SQL> STARTUP MOUNT;

    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

    3.5.2.11. If the production and standby databases are configured in a RAC, then start all instances on primary and standby
    3.6. Contingency or Fallback

    See 11.1 guide, Failed Switchovers to Physical Standby Databases. Still applies to 10.2 as well.

    Check DG Admin troubleshooting guide, Problems Switching Over to a Standby Database

    4.0 Post-Switchover Steps

    4.1. Set Trace to Prior Value
    4.1.1. With Broker

    For every instance: DGMGRL> EDIT INSTANCE SET PROPERTY LogArchiveTrace=3.3.1.1>;

    4.1.2. Without Broker

    For each database:

    SQL> ALTER SYSTEM SET log_archive_trace=;
    4.2. Reset Jobs

    SQL> ALTER SYSTEM SET job_queue_processes= scope=both sid=’*’

    SQL> EXECUTE DBMS_SCHEDULER.ENABLE();

    Enable any cron jobs that were diabled in 3.1

    4.3. Schedule and conduct the incremental backup, roll-forward, and tape backups for 10.2

    Retain/move backup schedule to the standby

    4.4. Reset apply delay for the target standby

    Reverse steps in 2.1.1.2 or 2.1.2.2

    4.5. Drop any Switchover Guaranteed Restore Points

    SQL> DROP RESTORE POINT SWITCHOVER_START_GRP ;

    5.0 Create a Guaranteed Restore Point on Each Switchover Database

    5.1. Review Prerequisites & Best Practices
    About Flashback Database
    Guaranteed Restore Points and Flash Recovery Area Space Usage
    Logging for Flashback Database With Guaranteed Restore Points Defined
    Flashback Database Best Practices & Performance Document 565535.1.
    5.2. Create a guaranteed restore point on the primary
    5.2.1. Verify if flashback database is on or a guaranteed restore point already exists

    SQL> SELECT FLASHBACK_ON FROM V$DATABASE;

    If this query returns “YES” (flashback database is on) or “RESTORE POINT ONLY” (Flashback is on but one can only flashback to an existing guaranteed restore point) then proceed to creating the guaranteed restore point.

    NOTE: Unless you have a backport for Bug 7568556, “ACTIVE APPLY RATE SEEN FROM 63MB/S TO 544KB/S AFTER RESTORE POINT ENABLED”, you should not have just a guaranteed restore point only (V$DATABASE.FLASHBACK_ON=”RESTORE POINT ONLY”) and ensure that flashback database is also on (V$DATABASE.FLASHBACK_ON=”YES”) when creating a guaranteed restore point.

    If this query returns “NO” then you need to turn on flashback database before creating the guaranteed restore point. This requires the database to be mounted.

    See Enabling Logging for Flashback Database for those steps.

    5.2.2. Create the guaranteed restore point

    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
    SQL> CREATE RESTORE POINT SWITCHOVER_START_GRP GUARANTEE FLASHBACK DATABASE;

    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
    5.3. Create a guaranteed restore point on the standby
    5.3.1. Verify if flashback database is on or a guaranteed restore point already exists

    SQL> SELECT FLASHBACK_ON FROM V$DATABASE;

    If this query returns “YES” (flashback database is on) or “RESTORE POINT ONLY” (Flashback is on but one can only flashback to an existing guaranteed restore point) then proceed to creating the guaranteed restore point.

    If this query returns “NO” then you need to turn on flashback database before creating the guaranteed restore point. This requires being in the MOUNT state.

    See Enabling Logging for Flashback Database for those steps.

    5.3.2. Create the guaranteed restore point

    SQL> CREATE RESTORE POINT SWITCHOVER_START_GRP GUARANTEE FLASHBACK DATABASE;
    [@more@]

    来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/9225895/viewspace-1030926/,如需转载,请注明出处,否则将追究法律责任。

    转载于:http://blog.itpub.net/9225895/viewspace-1030926/

    展开全文
  • DATA GUARD的最主要的功能是冗灾。当然根据配置的不同,DATA GUARD还可以具备以下特点:高可用、性能提升、数据保护以及故障恢复等。 DATA GUARD可以分为物理STANDBY和逻辑STANDBY两种。二者的最大差别在于,物理...
  • Oracle 11g Data Guard Enabling Active Data Guard 开启ADG需要standby database instance redo-only mode ...
  • DG确保企业数据高可用,数据保护,和灾难恢复。提供了一套创建,控制,管理和监控一个或多个备库去确保主生产库数据的安全可用的服务。DG控制这些备库像事务的一致性一样,是生产库的一个副本。...
  • 第一章主要是对DATA GUARD进行了一个全面的介绍,使得读者可以对DATA GUARD有一个初步的认识。 DATA GUARD的最主要的功能是冗灾。当然根据配置的不同,DATA GUARD还可以具备以下特点:高可用、性能提...
  • 这章介绍了在使用DATA GUARD之前应该首先考虑的问题。 首先介绍的是如何选择STANDBY数据库的类型。分别介绍了物理STANDBY和逻辑STANDBY的特点、优点。接着介绍了建立和管理DATA GUARD的工具。然后介...
  • 注:本文为原著(其内容来自 腾科教育培训课堂)。阅读本文注意事项如下: 1:所有文章的转载请标注本文出处。 2:本文非本人不得用于商业用途。违者将承当相应法律责任。 3:该系列文章目录列表: 一:《OCM 基本班...
  • 测试环境不管是数据真实性、环境配置和正式环境都有所差异,这时必须用线上的数据进行测试。将物理DG临时转换成snapshot DG进行测试,测试完成之后再转换成物理DG,这个方法是比较实用的。 下面实际操作一下: ...
  • 构建RAC架构Data Guard及异地单机Data Guard 实施方案 目录文档控制3修改记录3文档分发3概述4实施过程5一、RAC架构Data Guard5(一)、配置standby库rac环境。5(二)...
  • 这一章介绍了ORACLE DATA GUARD部署中常见的几种情况。 文章主要讨论了一下几个方面的内容:选择可用性最高的STANDBY数据库进行切换。其中包括物理STANDBY的选择和逻辑STANDBY的选择。物理STANDB...
  • Data Guard broker是建立在Data Guard基础上的一个对Data Guard配置,集中管理操作的一个平台,因此在学习Data Guard broker之前必须对Data Guard要有充分的了解。 Data Guard为我们提供了一套高可用的解决方案,...
  • <p>when DBA switch Data Guard to standby node connection starts giving me: <pre><code>ORA-01033: ORACLE initialization or shutdown in progress</code></pre> <p>it stop trying to connect at first ...

空空如也

1 2 3 4 5 ... 20
收藏数 4,118
精华内容 1,647
关键字:

data guard