zoukankan      html  css  js  c++  java
  • Oracle 12C 物理Standby 主备切换switchover

    Oracle 12C 物理Standby 主备切换switchover

    Oracle 12C 物理Standby 主备切换switchover

    1 简述

    Oracle 12C 为DG 的运维提供了很多的改进。这里提到的就是其中之一的:物理DG 主备的一键切换。 所谓的一键就是一条命令。该命令会执行相关的检查,并将11g 的切换步骤进行封装执行。如果不符合 切换条件,会在命令行窗口及日志中给出相应的提示。

    2 切换检查

    Oracle 为DG 切换提供了的专门的检查命令:

    alter database switchover to <target standby db_unique_name> verify;
    
    

    以上命令会验证如下信息:

    • 验证数据库的版本至少为 12.1
    • 主库 REDO 传输正常。
    • 备库 MRP 进程正常运行并且与主库同步。

    如果一切正常,数据库会反馈以下消息

    SQL> alter database switchover to chicago verify;
    
    Database altered.
    

    主库日志:

    SWITCHOVER VERIFY: Send VERIFY request to switchover target CHICAGO
    
    SWITCHOVER VERIFY COMPLETE
    
    Completed: alter database switchover to chicago verify
    

    如果不正常,会有报错信息,一般是 ORA-16470 或者 ORA-16475.

    3 问题及解决方法

    由于某些原因,可能我们的dataguard配置并不支持切换。这里列出对常见两个错误的 解决思路。

    3.1 ORA-16470

    示例:

    SQL>alter database switchover to chicago verify;
    
    ORA-16470: Redo Apply is not running on switchover target
    

    这种情况说明数据没有正常同步,需要同步完成后,再进行切换。 在备库执行以下命令:

    alter database recover managed standby  database disconnect;
    

    3.2 ORA-16475

    ORA-16475 错误是一个入口性质的错误,只反馈给我们检查成功,但是可能还会存在问题。 具体问题, 在primary 或者 standby 的alert日志中会有提示。命令行窗口的错误如下:

    SQL> alter database switchover to chicago verify;
    
    ERROR at line 1:
    
    ORA-16475: succeeded with warnings, check alert log for more details
    

    3.2.1 dirty redo log

    如果redo log 中存在脏数据,需要清除,会遇到如下错误: 主库日志:

    -----Primary Alert log-----------
    
    SWITCHOVER VERIFY WARNING: switchover target has dirty online redo logfiles that require clearing.
    
    It takes time to clear online redo logfiles. This may slow down switchover process.
    
    检查 redo 日志路径转换设置
    show parameter logfile_name_convert
    
    

    如果没有设置使用如下命令进行设置:

    alter system set LOG_FILE_NAME_CONVERT='本地路径','目标端路径' scope=spfile;
    
    
    注意
    重启备库并且启动 MRP。当重启备库并且启动 MRP,将清除所有备库的 log_file_name_convert 参数设置的日志。
    检查临时文件

    确认主库和备库的临时数据文件匹配
    临时数据文件在创建备库之后,不会同时创建临时数据文件,用如下的命令查询临时数据文件,并且在备库进行创建。

    col name for a45
    select ts#,name,ts#,status  from v$tempfile;
    
    注意
    对于多个备库的环境,确保每个备库与主库同步。

    3.2.2 log_archive_dest_n

    standby 端*log_archive_dest_n* 参数配置不正确或者没有配置时也会出现 ORA-16475 错误,alert日志如下:

    SWITCHOVER VERIFY: Send VERIFY request to switchover target S1202
    SWITCHOVER VERIFY COMPLETE
    SWITCHOVER VERIFY WARNING: switchover target has no standby database definedin LOG_ARCHIVE_DEST_n parameter. If the switchover target is converted to
    a primary database, the new primary database will not be protected.ORA-16475 signalled during: ALTER DATABASE SWITCHOVER TO S1202 VERIFY...
    
    • 检查log_archive_dest_n 是否设置 对于一个standby的情况下,我们一般设置的是 log_archive_dest_2.

      show parameter log_archive_dest
      

      检查除了log_archive_dest_1 外是否有配置其他参数。如果没有配置,使用如下命令进行配置:

      alter system set log_archive_dest_2='SERVICE=&tnsname ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=&standby_db_unique_name;
      
    • 检查switchover_status

      select switchover_status from v$database;
      
      

      switchover_status 的值为 UNRESOLVABLE GAP(RAC 或者非 RAC),通过以下方法解决:

      • 检查是否有些线程已关闭但是仍存在

        col instance for a10
        set lines 32767
        select thread#,instance,status from v$thread;
        

        结果示例如下:

           THREAD# INSTANCE   STATUS
        ---------- ---------- ------
                 1 gsboss     OPEN
                 2 gsboss2    OPEN
        

        将存在的线程disable:

        ALTER DATABASE DISABLE THREAD &thread#;
        
      • 检查 log_archive_destination 是否是否可用

        select status,DEST_ID,TYPE,ERROR,GAP_STATUS,SYNCHRONIZED,SYNCHRONIZATION_STATUS,RECOVERY_MODE from V$ARCHIVE_DEST_STATUS where STatus <> 'INACTIVE';
        

        如果存在路径不可用的情况,修改为可用路径。或者解决路径权限等问题。

    4 切换角色

    在主库和备库同时开启 trace,用于发生问题时候的诊断。

    alter system set log_archive_trace=8191 sid=’*’;
    

    4.1 切换备库角色为主库

    主库 - Boston, 备库为chicago.

    alter database switchover to chicago;
    

    以下是主库(BOSTON)和备库(CHICAGO)的 alert 输出:

    • 主库日志:

      Fri Aug 23 11:05:23 2013
      
      ALTER SYSTEM SET log_archive_trace=8191 SCOPE=BOTH;
      
       alter database switchover to chicago
      
      Fri Aug 23 11:05:43 2013
      
      Starting switchover [Process ID: 3340]
      
      Fri Aug 23 11:05:43 2013
      
      ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY [Process Id: 3340] (boston)
      
      .
      
      Fri Aug 23 11:05:44 2013
      
      Active, synchronized Physical Standby switchover target has been identified
      
      Preventing updates and queries at the Primary
      
      Generating and shipping final logs to target standby
      
      Switchover End-Of-Redo Log thread 1 sequence 11 has been fixed   <--------- 序列号 11 是日志的终止序号
      
      Switchover: Primary highest seen SCN set to 0x0.0x229306
      
      ARCH: Noswitch archival of thread 1, sequence 11
      
      .
      
      Switchover: Primary controlfile converted to standby controlfile succesfully.
      
      Switchover: Complete - Database shutdown required
      
      Sending request (convert to primary database) to switchover target CHICAGO
      
      OCISessionBegin with PasswordVerifier succeeded
      
      Switchover complete. Database shutdown required
      
      USER (ospid: 3340): terminating the instance
      
      Fri Aug 23 11:05:51 2013
      
      Instance terminated by USER, pid = 3340
      
      Completed:  alter database switchover to chicago
      
      
    • 备库日志:

      Fri Aug 23 11:05:47 2013
      
      SWITCHOVER: received request 'ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY' from primary database.
      
      Fri Aug 23 11:05:47 2013
      
      ALTER DATABASE SWITCHOVER TO PRIMARY (chicago)
      
      Maximum wait for role transition is 15 minutes.
      
      .
      
      Standby became primary SCN: 2265860
      
      Switchover: Complete - Database mounted as primary
      
      SWITCHOVER: completed request from primary database.
      
      
      注意
      备库一端只最多只等待15分钟,实现备库与主库的同步。

    4.2 打开新的主库

    alter database open;
    

    4.3 重启新的备库

    shutdown abort
    startup
    -- 开启数据同步
    alter database recover managed standby database disconnect;
    

    5 切换后的后续步骤

    • 关闭 trace
    alter system set log_archive_trace=0;
    
    • 确认DG同步
      • 在主库侧执行

        alter system switch logfile;
        select dest_id,error,status from v$archive_dest where dest_id=<your remote log_archive_dest_<n>>;
        select max(sequence#),thread# from v$log_history group by thread#;
        
      • 在备库侧

        select thread#,sequence#,process,status from gv$managed_standby;
        select max(sequence#),thread# from v$archived_log group by thread#;
        
    • 在 12.2 中使用 v$dataguard_process 替代 v$managed_standby
    select name,role,instance,thread#,sequence#,action from gv$dataguard_process;
    

    Author: halberd.lee

    Created: 2019-06-19 Wed 14:19

    Validate

  • 相关阅读:
    ehcache如何判断缓存数据是否存在--isKeyInCache
    ehcache 缓存监控
    XSS跨站脚本攻击
    java根据文件头判断文件类型
    Spring Security使用Authentication获取当前用户信息
    HttpSessionListener的用法
    ehcache缓存配置与参数说明
    [CERC2017]Buffalo Barricades
    [POI2001]Gra绿色游戏
    移动游戏By HYJ
  • 原文地址:https://www.cnblogs.com/halberd-lee/p/11051027.html
Copyright © 2011-2022 走看看