C/C++教程

Oracle-管理Data Guard Standby Database

本文主要是介绍Oracle-管理Data Guard Standby Database,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

监视DG状态

物理备库(Physical Standby)

检查进程状态

SELECT CLIENT_PROCESS, PROCESS, THREAD#, SEQUENCE#, STATUS 
FROM V$MANAGED_STANDBY 
WHERE CLIENT_PROCESS='LGWR' OR PROCESS='MRP0';

-- oracle 12.2+
select name,pid,role,action,group#,thread#,sequence#,delay_mins from v$dataguard_process;
V$DATAGUARD_PROCESS视图

显示正在运行的Data Guard 进程,从12.2.0.1开始使用,不建议使用V$MANAGED_STANDBY视图。

name: 进程名称
  • ARCn - Archiver process
  • DTS - Data transport process
  • FAL - File/announce process
  • LGWR - Log Writer Process
  • MRP0 - Detached recovery server process
  • NSSn - SYNC Redo Transport process
  • ORA - Foreground process
  • RFS - Remote file server
  • RMI - Remote message process
  • TMON - Redo Transport Process monitor
  • TTnn - Redo Transport Slave Process
ROLE:进程对应的角色
  • async ORL multi
  • async ORL single
  • async SRL multi
  • async SRL single
  • log writer
  • sync
  • archive redo
  • archive local
  • archive gap
  • RFS async
  • RFS sync
  • RFS archive
  • RFS gap
  • RFS SMON
  • data transport
  • data receive
  • redo transport monitor
  • heartbeat redo informer
  • process kill
  • post role transition
  • gap manager
  • update TMI
  • RFS ping
  • FAL GAP
  • FAL announce
  • failover
  • switchover
  • remote failover
  • remote switchover
  • redo transport timer
  • announce request
  • managed recovery
  • recovery
  • controlfile update
  • UNKNOWN
ACTION:当前进程执行的操作
  • UNUSED
  • STARTING
  • CONNECTED
  • ATTACHED
  • IDLE
  • ERROR
  • OPENING
  • CLOSING
  • WRITING
  • RECEIVING
  • ANNOUNCING
  • REGISTERING
  • WAIT_FOR_LOG
  • WAIT_FOR_GAP
  • APPLYING_LOG
  • TERMINATING
  • PROCESSING
  • UNKNOWN
CLIENT_ROLE:和备库上RFS或DTS进程通信的进程角色
  • none
  • async ORL multi
  • async ORL single
  • async SRL multi
  • async SRL single
  • log writer
  • sync
  • archive redo
  • archive gap
  • data transport
  • gap manager
  • failover
  • switchover
  • announce request
  • managed recovery
  • recovery
  • UNKNOWN
DELAY_MINS:已分钟为单位归档日志延迟时间间隔

延迟检查

监控adg延迟时间(单位/s)
select inst_id, NAME,(substr(value,5,2)*3600+substr(value,8,2)*60+substr(value,11,2)) lag from GV$DATAGUARD_STATS where name like '%lag';

select gap.inst_id, gap.thread#, gap.low_sequence#, gap.high_sequence# from gv$archive_gap gap;
监视v$database.switchover_status值是否为UNRESOLVABLE GAP
select SWITCHOVER_STATUS from v$database;

日志传输不到备库

set lines 168 pages 99
col dest_name for a32
col destination for a18
col error for a32
SELECT inst_id, dest_name, destination, status, error 
FROM gV$ARCHIVE_DEST WHERE TARGET='STANDBY';

检查同步状态

select sequence#, first_time, next_time, applied from v$archived_log;
select archived_thread#, archived_seq#, applied_thread#, applied_seq# from v$archive_dest_status;
select thread#, max (sequence#) from v$log_history group by thread#;
select thread#, max (sequence#) from v$archived_log where APPLIED='YES' group by thread#;

col name for a13
col value for a13
col unit for a30
set lines 132
select name, value, unit, time_computed
from v$dataguard_stats where name in ('transport lag', 'apply lag');

set linesize 300
col start_time format a20
col item format a20
select to_char(start_time, 'yyyy-mm-dd hh24:mi:ss') start_time, item , sofar, units
from v$recovery_progress
where item in ('Active Apply Rate', 'Average Apply Rate', 'Redo Applied');

健康检查

sqlplus -S "/ as sysdba"<<EOF
-- STATUS: 进程状态值
-- ### ALLOCATED   : 正准备连接Primary数据库
-- ### ATTACHED    : 正在连接Primary数据库
-- ### CONNECTED   : 已连接至Primary数据库
-- ### IDLE        : 空闲中
-- ### RECEIVING   : 归档文件接收中
-- ### OPENING     : 归档文件处理中
-- ### CLOSING     : 归档文件处理完,收尾中
-- ### WRITING     : REDO数据库写向归档文件中
-- ### WAIT_FOR_LOG: 等待新的REDO数据中
-- ### WAIT_FOR_GAP: 归档有中断,正等待中断的那部分REDO数据
-- ### APPLYING_LOG: 应用REDO数据中

set feedback off;
set lines 200 pages 99
ttitle 'dg process info'
select inst_id, process, status, client_process, sequence# from gv\$managed_standby;

ttitle 'dg event info'
select inst_id, to_char(timestamp, 'yyyy-mm-dd hh24:mi:ss') ctime, message
  from gv\$dataguard_status
 where timestamp > sysdate - 2
;

col value for a15
col ctime for a20
col NAME for a18
col datum_time for a20
ttitle 'standby: archive log lag info'
select inst_id,
       to_char(sysdate, 'yyyy-mm-dd hh24:mi:ss') ctime,
       name,
       value,
       datum_time,
       (substr(value, 5, 2) * 3600 + substr(value, 8, 2) * 60 +
       substr(value, 11, 2)) lag_sec
  from gv\$dataguard_stats
 where 1 = 1
  -- and name like '%lag'
;

ttitle 'archive dest status'
col dest_name format a20
col error format a32
col db_unique_name format a15
col status for a8
col process for a8
col type for a8
col valid_type for a12
col valid_role for a12
col compression for a10
select inst_id,
       dest_id,
       dest_name,
       status,
       delay_mins,
       process,
       error,
       type,
       valid_type,
       valid_role,
       compression,
       db_unique_name
from gv\$archive_dest
where status <> 'INACTIVE';

col database_mode for a16
col recovery_mode for a16
col protection_mode for a20
col synchronization_status for a24
col gap_status for a12
select inst_id,
       dest_id,
       dest_name,
       status,
       type,
       database_mode,
       recovery_mode,
       protection_mode,
       standby_logfile_count srl_cnt,
       standby_logfile_active srl_id#,
       -- archived_thread#,
       archived_seq#,
       -- applied_thread#,
       applied_seq#,
       error,
       db_unique_name,
       synchronization_status,
       -- synchronized,
       gap_status
  from gv\$archive_dest_status
 where status <> 'INACTIVE';

ttitle 'apply logfile info'
col name for a64
select 
       name,
       registrar,
       creator,
       thread#,
       sequence#,
       standby_dest,
       archived,
       applied,
       deleted,
       status,
       first_time,
       next_time
  from v\$archived_log;

ttitle off;
quit;
EOF

对比ARCH和LGWR进程同步redo数据

ARCH进程传输

主库仅看到ARCH进程
set lines 168 pages 99
col client_process for a16
select process, client_process, thread#, sequence#, status from v$managed_standby;
备库
set lines 168 pages 99
col client_process for a16
select process, client_process, thread#, sequence#, status from v$managed_standby;
select group#, thread#, SEQUENCE#, bytes, blocksize, used, archived, status  from v$standby_log;

与RFS进程通信的进程只有ARCH进程,SRLs也没有使用。

LGWR进程传输

主库
set lines 168 pages 99
col client_process for a16
select process, client_process, thread#, sequence#, status from v$managed_standby;

可以看到比之前ARCH传输多个一个LGWR的子进程LNS。

img

备库
set lines 168 pages 99
col client_process for a16
select process, client_process, thread#, sequence#, status from v$managed_standby;
select group#, dbid, thread#, SEQUENCE#, bytes, blocksize, used, archived, status  from v$standby_log;

使用LGWR进程传输时,对比之前ARCH进程传输,与RFS进程通信进程(client_process)中不仅仅有ARCH,也有LGWR进程;SRLs也被正常使用。

逻辑备库(Logical Standby)

查看逻辑备库当前配置参数

SELECT * FROM DBA_LOGSTDBY_PARAMETERS;

逻辑Standby操作日志(DBA_LOGSTDBY_EVENTS)

默认只保留最近100条事件的记录

SELECT EVENT_TIME,STATUS,EVENT FROM DBA_LOGSTDBY_EVENTS 
ORDER BY EVENT_TIMESTAMP;

记录当前的重做日志的应用情况(DBA_LOGSTDBY_LOG)

SELECT SEQUENCE#,FIRST_CHANGE#,NEXT_CHANGE#,
TIMESTAMP,APPLIED FROM DBA_LOGSTDBY_LOG;

显示LogMiner的状态等相关信息(V$LOGSTDBY_STATS)

SELECT *FROM V$LOGSTDBY_STATS;  

显示当前日志应用服务的相关信息(V$LOGSTDBY_PROCESS)

显示当前日志应用服务的相关信息。常用于诊断归档日志逻辑应用的性能问题

SELECT SID,SERIAL#,SPID,TYPE,STATUS,HIGH_SCN FROM  V$LOGSTDBY_PROCESS;  

TYPE列表示SQL应用进程信息,其值有:

  • COORDINATOR
  • READER
  • BUILDER
  • PREPARER
  • ANALYZER
  • APPLIER

显示SQL应用的大致状态(V$LOGSTDBY_STATE)


STATE列的状态信息
  • INITIALIZING 初始化状态:ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; 执行后,启用SQL应用时,首先进入初始状态,该状态存在时间非常短暂。

    SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE;
    
  • WAITING FOR DICTIONARY LOGS等待数据字典日志:指第一次初始化时的状态,如刚从物理Standby转换成逻辑Standby,需要首先应用来自Primary端生成的数据字典,在等待Primary数据字典信息时,就会处于这一状态

  • LOADING DICTIONARY 加载并分析:说明处于加载数据字典的状态

    • 查询V$lOGMNR_DICTIONARY_LOAD视图获取关于加载的更详细的信息

      SELECT PERCENT_DONE, COMMAND FROM V$LOGMNR_DICTIONARY_LOAD
       WHERE SESSION_ID =(SELECT SESSION_ID FROM V$LOGSTDBY_STATE); 
      
  • WAITING ON GAP中断等待状态:SQL应用挖掘并应用了所有可用的REDO数据,正等待新的日志文件,也有可能是由于归档文件有中断造成的。

    • 如果查询V$LOGSTDBY_STATE视图时发现处于这一状态,应该同时查询V$ARCHIVE_GAP视图,检查是否有中断的归档。
  • IDLE空闲状态:处于这一状态也有可能不是好现象,一方面可能是逻辑Standby处理能力优秀,所有活都干完了;也可能是Primary数据库发送日志或逻辑Standby日志出现了问题,导致SQL应用无活可干,因此处于空闲状态。

    • 如果你发现你的逻辑Standby数据库长期处于这一状态,建议查询DBA_LOGSTDBY_LOG视图,确认Primary端产生的日志文件能被逻辑Standby数据库正常接收
  • SQL APPLY NOT ON:说明逻辑Standby数据库根本没启动SQL应用

管理

物理备库(Physical Standby)

重启进程

primary端(LNS进程)
alter system set log_archive_dest_state_2='defer' scope=both;
alter system set log_archive_dest_state_2='enable' scope=both;
standby端(MRP进程)
alter database recover managed standby database cancel;
-- 11g
alter database recover managed standby database using current logfile disconnect from session;
-- 12c 默认实时应用
alter database recover managed standby database disconnect from session;

归档日志管理

归档删除策略
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # 默认归档删除策略
  • NONE:表示不启用归档文件的删除策略,默认值
  • APPLIED ON STANDBY:表示强制检查待删除的log 是否已经在备库apply,只有apply后的log才能删除
    • 当通过附加的 DELETE INPUT 子句删除Standby数据库仍需要的日志时,会提示RMAN-08137错误而无法删除。 不过仍然可以手动地通过 DELETE ARCHIVELOG 方式删除,但由于网络问题导致没有传给standby时,DELETE ARCHIVELOG 方式也无法删除。
  • SHIPPED TO ALL STANDBY:当归档传送到备库就可以删除
备库配置归档删除策略
rman target / <<EOF
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;
EOF

备库上rman配置:当应用完的日志自动删除

删除归档日志
归档文件已不存在(即更新控制文件中记录信息)
rman target / <<EOF
crosscheck archivelog all;
delete noprompt expired archivelog all;
EOF
删除超过恢复策略的备份文件
delete noprompt obsolete;    #不仅仅删除过期的备份,相关的归档也会删除
删除n天前的归档
delete noprompt archivelog all completed before 'sysdate-N';
使用FRA(fast recovery area)快速恢复区存储归档

在 Oracle 11.2 及以后版本中,当 SPACE_USED 达到 SPACE_LIMIT 的 80% 时,Oracle 将开始清除 FRA 中的文件。使用FRA可以方便管理维护归档日志。

查看FRA空间使用情况
-- 10g
select * from V$FLASH_RECOVERY_AREA_USAGE;
-- 11g+
select * from V$RECOVERY_AREA_USAGE;

SELECT  substr(name, 1, 30) name
      , space_limit/(1073741824) AS Quota_GB
      , space_used/(1073741824)  AS Used_GB
      , space_reclaimable/(1073741824) AS Reclaimable_GB
      , number_of_files AS files
  FROM V$RECOVERY_FILE_DEST ;
调整FRA中归档日志删除占比

通过事件来设置,事件号为: 19823 。如下图

image-20210816123857192

  • 创建测试数据

    create table t1 ( id number, name char(1000)) tablespace TBS_USERS;  
    insert into t1 values (1,'a');
    
    begin  
      for i in 1..300000 loop  
        update t1 set name=to_char(i);  
      end loop;  
      commit;  
    end;  
    /
    
    -- 监视产生的日志量
    select * from v$sesstat where sid=155 and statistic#=178;
    
  • 调整FRA的使用空间限制占比

    -- 将默认值80%,改成95%
    alter system set event='19823 trace name context forever,level 95' scope=spfile sid='*'; 
    
    -- 调整为50%
    alter system set event='19823 trace name context forever,level 50' scope=spfile sid='*'; 
    

dgmgrl工具

Oracle Data Guard command-line interface (DGMGRL) :用来管理维护Data Guard命令行工具。

语法

image-20210816171631498

逻辑备库(Logical Standby)

指定对象跳过应用

在默认情况下,接收自Primary的REDO数据中,所有能够被逻辑Standby数据库支持的操作都会在逻辑Standby端执行。如果你希望跳过对某些对象的某些操作的话,DBMS_LOGSTDBY.SKIP就能派上用场了

DBMS_LOGSTDBY.SKIP的语法
DBMS_LOGSTDBY.SKIP (  
     stmt                       IN VARCHAR2,  
     schema_name                IN VARCHAR2 DEFAULT NULL,  
     object_name                IN VARCHAR2 DEFAULT NULL,  
     proc_name                  IN VARCHAR2 DEFAULT NULL,  
     use_like                   IN BOOLEAN DEFAULT TRUE,  
     esc                        IN CHAR1 DEFAULT NULL); 
跳过SCOTT用户下对dept表的DML操作
-- 需要先停止REDO应用
ALTER DATABASE STOP LOGICAL STANDBY APPLY;
-- 跳过应用
EXEC DBMS_LOGSTDBY.SKIP('DML', 'SCOTT', 'DEPT');
-- 启动redo应用
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

恢复对象同步

如果逻辑Standby中的某些表取消了与Primary的同步维护,想再恢复同步,可以通过DBMS_LOGSTDBY.UNSKIP实现。

DBMS_LOGSTDBY.UNSKIP的语法
DBMS_LOGSTDBY.UNSKIP (  
     stmt                   IN VARCHAR2,  
     schema_name            IN VARCHAR2,  
     object_name            IN VARCHAR2); 
查看当前逻辑Standby都有哪些对象处于不同步状态
select * from dba_logstdby_skip;  
恢复同步
-- 停止当前的SQL应用状态
ALTER DATABASE STOP LOGICAL STANDBY APPLY;

--恢复前面停止的scott.tmp1表的应用
execute dbms_logstdby.unskip('DML', 'SCOTT', 'DEPT');

-- 启动redo应用
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

添加或重建对象

指定对象跳过应用虽然被取消,但是有可能在此期间由于Primary数据库做过数据修改,两端此时已经不同步,如果Standby端继续应用极有可能导致应用错误的数据

对于这类情况,Oracle也早有预见,DBMS_LOGSTDBY包中还有一个过程叫INSTANTIATE_TABLE,专门用来同步一下跳过的对象,以保持与Primary数据库的一致。

DBMS_LOGSTDBY.INSTANTIATE_TABLE的调用语法
DBMS_LOGSTDBY.INSTANTIATE_TABLE (  
     schema_name            IN VARCHAR2,  
     table_name             IN VARCHAR2,  
     dblink                 IN VARCHAR2); 
-- 在逻辑Standby端创建一个连接Primary数据库dblink
CREATE DATABASE LINK PRE_TBL_DATA CONNECT TO SYSTEM IDENTIFIED BY oracle 
USING 'ORCL_PD';  
重建对象
-- 停止当前的SQL应用状态
ALTER DATABASE STOP LOGICAL STANDBY APPLY;

EXEC DBMS_LOGSTDBY.INSTANTIATE_TABLE('SCOTT', 'DEPT', 'PRE_TBL_DATA'); 

-- 启动redo应用
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

仅在逻辑备库修改数据

应用Redo数据到Standby端

逻辑Standby应用REDO数据

SQL应用的原理是将接收到的REDO数据转换成SQL语句在逻辑Standby数据库端执行,因此逻辑Standby需要启动至OPEN状态

启动SQL应用
ALTER DATABASE START LOGICAL STANDBY APPLY; 
启动实时应用
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
停止SQL应用
ALTER DATABASE STOP LOGICAL STANDBY APPLY;

需要等待当前执行的SQL触发的事务结束,才能真正停止REDO应用的状态

若不考虑事务执行情况,马上停止REDO应用
ALTER DATABASE ABORT LOGICAL STANDBY APPLY;

附录

参考文档

Files being deleted in the flash recovery area, messages in the alert log Deleted Oracle managed file filename (Doc ID 1369341.1)

12.2 v$dataguard_process视图

这篇关于Oracle-管理Data Guard Standby Database的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!