首页 > 数据库> 文章详细

Oracle-管理Data Guard Standby Database

2021-08-22 20:31:07 阅读：336 来源： 互联网

标签：name Database Standby LOGSTDBY process Guard col select

监视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。

备库

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 。如下图

创建测试数据

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命令行工具。

语法

逻辑备库(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);

需先创建dblink

-- 在逻辑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视图

标签：name,Database,Standby,LOGSTDBY,process,Guard,col,select
来源： https://www.cnblogs.com/binliubiao/p/15173383.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9

Oracle-管理Data Guard Standby Database

监视DG状态

物理备库(Physical Standby)

检查进程状态

V$DATAGUARD_PROCESS视图

name: 进程名称

ROLE：进程对应的角色

ACTION：当前进程执行的操作

CLIENT_ROLE：和备库上RFS或DTS进程通信的进程角色

DELAY_MINS：已分钟为单位归档日志延迟时间间隔

延迟检查

监控adg延迟时间（单位/s）

监视v$database.switchover_status值是否为UNRESOLVABLE GAP

日志传输不到备库

检查同步状态

健康检查

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

ARCH进程传输

主库仅看到ARCH进程

备库

LGWR进程传输

主库

备库

逻辑备库(Logical Standby)

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

逻辑Standby操作日志(DBA_LOGSTDBY_EVENTS)

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

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

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

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

STATE列的状态信息

管理

物理备库(Physical Standby)

重启进程

primary端(LNS进程)

standby端(MRP进程)

归档日志管理

归档删除策略

备库配置归档删除策略

删除归档日志

归档文件已不存在（即更新控制文件中记录信息）

删除超过恢复策略的备份文件

删除n天前的归档

使用FRA(fast recovery area)快速恢复区存储归档

查看FRA空间使用情况

调整FRA中归档日志删除占比

dgmgrl工具

语法

逻辑备库(Logical Standby)

指定对象跳过应用

DBMS_LOGSTDBY.SKIP的语法

跳过SCOTT用户下对dept表的DML操作

恢复对象同步

DBMS_LOGSTDBY.UNSKIP的语法

查看当前逻辑Standby都有哪些对象处于不同步状态

恢复同步

添加或重建对象

DBMS_LOGSTDBY.INSTANTIATE_TABLE的调用语法

需先创建dblink

重建对象

仅在逻辑备库修改数据

应用Redo数据到Standby端

逻辑Standby应用REDO数据

启动SQL应用

启动实时应用

停止SQL应用

若不考虑事务执行情况，马上停止REDO应用

附录

参考文档

监视`v$database.switchover_status`值是否为UNRESOLVABLE GAP