【DB笔试面试764】在Oracle中，逻辑DG维护中经常使用到的SQL语句有哪些？

♣          题目         部分

在Oracle中，逻辑DG维护中经常使用到的SQL语句有哪些？

     
♣          答案部分          

1.日志应用的启动和关闭

1ALTER DATABASE STOP LOGICAL STANDBY APPLY; ---中止应用，等待事务完成
2ALTER DATABASE ABORT LOGICAL STANDBY APPLY;--不等待事务完成就中止
3ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; ---实时
4ALTER DATABASE START LOGICAL STANDBY APPLY; --非实时
5ALTER DATABASE START LOGICAL STANDBY APPLY  IMMEDIATE SKIP FAILED TRANSACTION; --实时应用并跳过失败的事务

     

如何知道是否开启了实时应用呢？能够查询V$LOGSTDBY_STATE视图或查询是否有lsp进程。

1SQL> SELECT * FROM V$LOGSTDBY_STATE;
2PRIMARY_DBID SESSION_ID REALTIME_APPLY      STATE
3------------ ---------- ------------------  -----------------------------------------
4  1480747539          1 Y                   APPLYING
5[oracle@rhel6_lhr oraljdg]$ ps -ef|grep -i ora_lsp
6oracle   20450     1  0 15:22 ?        00:00:00 ora_lsp0_oraljdg

     

2.查看日志文件的应用状况

 1COLUMN DICT_BEGIN FORMAT A15;
 2COLUMN FILE_NAME FORMAT A50;
 3SET NUMF 9999999;
 4COL FCHANGE# FORMAT 9999999999999;
 5COL NCHANGE# FOR 999999999999999999999;
 6SET LINE 200
 7SELECT  FILE_NAME, SEQUENCE# AS SEQ#, FIRST_CHANGE# AS FCHANGE#,
 8        NEXT_CHANGE# AS NCHANGE#, TIMESTAMP, DICT_BEGIN AS BEG,
 9        DICT_END AS END, THREAD# AS THR#, APPLIED
10    FROM DBA_LOGSTDBY_LOG
11ORDER BY THREAD#,SEQUENCE#;
12
13SET LINE 9999 PAGESIZE 9999
14COL FILE_NAME FORMAT A120
15SELECT THREAD#,SEQUENCE#, FILE_NAME, APPLIED, TIMESTAMP 
16FROM DBA_LOGSTDBY_LOG D 
17WHERE D.SEQUENCE# >=(SELECT MAX(SEQUENCE#)-3 FROM  DBA_LOGSTDBY_LOG NB WHERE  NB.THREAD#=D.THREAD# AND NB.APPLIED='YES' ) 
18ORDER BY THREAD#,D.SEQUENCE#;

     

3.查看备库SQL Apply的进度

1SQL> SELECT LATEST_SCN,MINING_SCN,APPLIED_SCN,LATEST_TIME,MINING_TIME,APPLIED_TIME FROM V$LOGSTDBY_PROGRESS;
2LATEST_SCN MINING_SCN APPLIED_SCN LATEST_TIME         MINING_TIME         APPLIED_TIME
3---------- ---------- ----------- ------------------- ------------------- -------------------
48895794846 8895316681  8895316680 2010-05-18 16:27:08 2010-05-18 16:03:54 2010-05-18 16:03:54

     

4.查看备库是否有任何DDL/DML语句未成功应用

 1COL EVENT_TIMESTAMP FORMAT A30
 2COL EVENT FORMAT A40
 3COL EVENT_STATUS FORMAT A80
 4SELECT A.EVENT_TIME,
 5       A.CURRENT_SCN,
 6       A.COMMIT_SCN,
 7       XIDUSN,
 8       XIDSLT,
 9       XIDSQN,
10       TO_CHAR(EVENT) EVENT,
11       A.STATUS_CODE,
12       STATUS EVENT_STATUS
13  FROM DBA_LOGSTDBY_EVENTS A
14 WHERE A.EVENT_TIME >= SYSDATE - 10 / 1660
15 ORDER BY A.EVENT_TIME ;

     

5.查看备库SQL Apply的状态

1COL REALTIME_APPLY FORMAT A15
2COL STATE FORMAT A20
3SELECT * FROM V$LOGSTDBY_STATE;
4PRIMARY_DBID SESSION_ID REALTIME_APPLY       STATE
5------------ ---------- --------------- ---------------
6262089084          1                 Y         APPLYING

     

注意STATE列，该列可能有下述的几种状态：

l INITIALIZING：LogMiner SESSION已建立并初始化

l LOADING DICTIONARY：SQL应用调用LogMiner字典

l WAITING ON GAP：SQL应用正在等待日志文件，可能有中断

l APPLYING：SQL应用正在工做

l WAITING FOR DICTIONARY LOGS：SQL应用正在等待LogMiner字典信息

l IDLE：SQL应用工做很是出色，处于空闲状态

l SQL APPLY NOT ON：没有开启应用

6.取消部分对象或事务的同步

能够利用DBMS_LOGSTDBY.SKIP存储过程跳过特定表或特定用户的DML事务或部分DDL语句。这些跳过的对象或事务能够经过视图DBA_LOGSTDBY_SKIP和DBA_LOGSTDBY_SKIP_TRANSACTION查看。

 1EXECUTE DBMS_LOGSTDBY.SKIP(STMT => 'VIEW');
 2EXECUTE DBMS_LOGSTDBY.SKIP(STMT => 'PROFILE');
 3EXECUTE DBMS_LOGSTDBY.SKIP(STMT => 'DATABASE LINK');
 4EXECUTE DBMS_LOGSTDBY.SKIP(STMT => 'CREATE VIEW');
 5EXECUTE DBMS_LOGSTDBY.SKIP(STMT => 'DROP VIEW');
 6EXECUTE DBMS_LOGSTDBY.SKIP(STMT=>'SCHEMA_DDL', SCHEMA_NAME=>'%', OBJECT_NAME=>'%', PROC_NAME=>NULL);
 7EXECUTE DBMS_LOGSTDBY.SKIP(STMT=>'SCHEMA_DDL', SCHEMA_NAME=>'LHR', OBJECT_NAME=>'%', PROC_NAME=>NULL);
 8EXECUTE DBMS_LOGSTDBY.SKIP(STMT=>'SCHEMA_DDL', SCHEMA_NAME=>'MDSYS', OBJECT_NAME=>'%', PROC_NAME=>NULL);
 9
10EXEC DBMS_LOGSTDBY.SKIP_TRANSACTION (3, 3, 827); --(XIDUSN = 3, XIDSLT = 3, XIDSQN = 827)
11SELECT EVENT, STATUS,'EXEC DBMS_LOGSTDBY.SKIP_TRANSACTION ('||XIDUSN||', '||XIDSLT||', '||XIDSQN||');' FROM DBA_LOGSTDBY_EVENTS A WHERE XIDUSN IS NOT NULL AND   A.EVENT_TIME >= SYSDATE - 60 / 1660;
12SELECT 'EXEC DBMS_LOGSTDBY.SKIP_TRANSACTION ('||XIDUSN||', '||XIDSLT||', '||XIDSQN||');' FROM DBA_LOGSTDBY_EVENTS A WHERE XIDUSN IS NOT NULL AND   A.EVENT_TIME >= SYSDATE - 10 / 1660;
13
14SELECT * FROM DBA_LOGSTDBY_SKIP;
15SELECT * FROM DBA_LOGSTDBY_SKIP_TRANSACTION;

     

7.增长apply进程个数

若是Apply进程过于繁忙，那么能够增长Apply进程个数。如下命令调整为20，默认为5个:

1SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
2SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('APPLY_SERVERS',20);
3SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

     

8.处理从主库接收到的归档文件

逻辑DG在应用完归档日志后会自动删除该归档文件，这一特性是由逻辑DG中的2个参数控制的，它们分别为LOG_AUTO_DELETE和LOG_AUTO_DEL_RETENTION_TARGET。

LOG_AUTO_DELETE的值默认为TRUE，表示逻辑DG在应用完归档日志后会自动删除该归档文件，默认24小时以后删除（由参数LOG_AUTO_DEL_RETENTION_TARGET控制）。若是但愿禁用自动删除的功能，那么能够执行下列语句：

1EXECUTE DBMS_LOGSTDBY.APPLY_SET('LOG_AUTO_DELETE', FALSE);

     

在告警日志中会有相似以下的记录：

1Fri Jul 27 13:48:53 2018
2LOGMINER: Log Auto Delete - deleting: /u01/app/oracle/flash_recovery_area/ORADGLG/1_202_886695024.dbf
3Deleted file /u01/app/oracle/flash_recovery_area/ORADGLG/1_202_886695024.dbf

     

在某些状况下确实须要禁用归档文件的自动删除功能，例如逻辑DG须要执行Flashback Database操做，若是你想恢复到以前的某个时间点，而后再接着应用，那么就必需要有该时间点后对应的归档。假如LOG_AUTO_DELETE为TRUE的话，应用过的归档已经被删除，想回都回不去。

参数LOG_AUTO_DEL_RETENTION_TARGET表示逻辑DG在应用完归档日志后的多长时间以后再自动删除该归档文件。该参数仅在LOG_AUTO_DELETE设置为TRUE以后才起做用，默认值为1440分钟，即24小时，能够经过如下命令修改该值的大小：

1exec DBMS_LOGSTDBY.APPLY_SET('LOG_AUTO_DEL_RETENTION_TARGET', 1);

     

以上命令表示归档日志被应用完以后，再过1分钟才会自动删除该归档日志。须要注意的是，这些设置仅适用于从主库传递过来的归档文件归档到的位置不是闪回恢复区。若是正在使用闪回恢复区，那么这些从主库传递过来的归档文件将再也不根据参数LOG_AUTO_DELETE和LOG_AUTO_DEL_RETENTION_TARGET的值作处理。

若是禁止了逻辑DG归档文件的自动删除功能，那么必定要有相应的其余解决方案，不能说取消了自动删除功能，以后逻辑Standby数据库接收到的Standby归档文件就再也不管它，这确定会产生问题，最起码要考虑到逻辑Standby数据库的存储空间是有限的。

逻辑Standby数据库接收到的归档文件并不会显示在V$ARCHIVED_LOG视图中，所以觉得经过RMAN中的配置自动删除这些文件的但愿也是会落空的。对于这类文件的删除，正确的删除方法一般会按照以下步骤操做：

首先执行DBMS_LOGSTDBY.PURGE_SESSION，该过程会检查当前全部接收到的归档日志文件，对于那些已经应用过，再也不须要（这里是当前再也不需求，将来是否有可能须要就得由DBA来决定了）的文件进行标记，例如：

1EXECUTE DBMS_LOGSTDBY.PURGE_SESSION;

     

而后，查询数据字典DBA_LOGMNR_PURGED_LOG，全部被DBMS_LOGSTDBY. PURGE_SESSION标记再也不须要的日志都会记录在这里，例如：

1SELECT * FROM DBA_LOGMNR_PURGED_LOG;

     

该字典只有一列，即归档文件的实际路径。最后根据显示的路径找到这些文件，而后在操做系统中删除便可。

9.调整PREPARER（调制机）的进程数

若是备库上有不少事务在等待Apply，可是还有空闲的Applier进程，且已经没有idle状态的PREPARER（调制机）进程，这时须要增长PREPARER的进程数。如下命令调整为4个，默认为1个:

1SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
2SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('PREPARE_SERVERS',4);
3SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

     

10.调整MAX_SGA，防止Paged out

经过如下SQL能够查询到是否发生了Paged out：

1SQL>select value bytes from v$logstdby_stats where name='bytes paged out';

     

若是以上查询结果在增加，那么查看当前MAX_SGA的大小:

1SQL>select value from v$logstdby_stats where name like 'maximum SGA for LCR cache%';
2VALUE
3---------------------------------------------------------------
430

     

能够增大MAX_SGA:

1SQL>alter database stop logical standby apply;
2SQL>execute dbms_logstdby.apply_set('MAX_SGA',1000);
3SQL>alter database start logical standby apply immediate;

     

逻辑备库须要将Redo记录解析成LCR（Logical Change Records），会在Shared Pool里分配一部分空间来做为LCR Cache，若是Cache过小，就会像OS的虚拟内存管理同样，须要作page out，这会严重影响应用日志的性能。在默认状况下，LCR Cache为Shared Pool的四分之一，最少很多于30M（默认为30M，最大能够设置到4096M），不然SQL Apply不能启动。若是机器的内存足够，建议将LCR Cache尽可能设大一点，固然，同时Share Pool也要足够大。若是机器内存有限，那么能够考虑将Buffer Cache减小一点来给LCR Cache腾出空间。

11.调整事务应用方式

默认状况下逻辑Standby端事务应用顺序与Primary端提交顺序相同。若是但愿逻辑Standby端的事务应用不要按照顺序的话，那么能够按照下列的步骤操做：

①中止SQL应用:

1SQL>ALTER DATABASE STOP LOGICAL STANDBYAPPLY;

     

②容许事务不按照Primary的提交顺序应用：

1SQL>EXECUTE DBMS_LOGSTDBY.APPLY_SET('PRESERVE_COMMIT_ORDER','FALSE');

     

③从新启动SQL应用

1SQL>ALTER DATABASE START LOGICAL STANDBYAPPLY IMMEDIATE;

     

恢复逻辑Standby按照事务提交顺序应用的话，按照下列步骤：

①仍是先中止SQL应用：

1SQL>ALTER DATABASE STOP LOGICAL STANDBYAPPLY;

     

②重置参数PRESERVE_COMMIT_ORDER的初始值：

1SQL>EXECUTE DBMS_LOGSTDBY.APPLY_UNSET('PRESERVE_COMMIT_ORDER');

     

③从新启动SQL应用：

1SQL>ALTER DATABASE START LOGICAL STANDBYAPPLY IMMEDIATE;

     

逻辑备库还有不少其它很是实用的SQL语句，这里就不列举了，读者能够关注做者的微信公众号，做者天天会推送一个很是实用的SQL语句。