分类 IT运维 下的文章

在数据库运维过程中，我们时常会关注数据库的链接情况，比如总共有多少链接、有多少活跃链接、有没有执行时间过长的链接等。数据库的各种异常也能通过链接情况间接反应出来，特别是数据库出现死锁或严重卡顿的时候，我们首先应该查看数据库是否有异常链接，并杀掉这些异常链接。本篇文章将主要介绍如何查看数据库链接及如何杀掉异常链接的方法。

1.查看数据库链接

查看数据库链接最常用的语句就是 show processlist 了，这条语句可以查看数据库中存在的线程状态。普通用户只可以查看当前用户发起的链接，具有 PROCESS 全局权限的用户则可以查看所有用户的链接。

show processlist 结果中的 Info 字段仅显示每个语句的前 100 个字符，如果需要显示更多信息，可以使用 show full processlist 。同样的，查看 information_schema.processlist 表也可以看到数据库链接状态信息。

普通用户只能看到当前用户发起的链接

mysql> select user();

| user() |

| testuser@localhost |

1 row in set (0.00 sec)

mysql> show grants;

| Grants for testuser@% |

| GRANT USAGE ON . TO 'testuser'@'%' |

| GRANT SELECT, INSERT, UPDATE, DELETE ON testdb.* TO 'testuser'@'%' |

2 rows in set (0.00 sec)

mysql> show processlist;

| Id | User | Host | db | Command | Time | State | Info |

| 769386 | testuser | localhost | NULL | Sleep | 201 | | NULL |

| 769390 | testuser | localhost | testdb | Query | 0 | starting | show processlist |

2 rows in set (0.00 sec)

mysql> select * from information_schema.processlist;

| ID | USER | HOST | DB | COMMAND | TIME | STATE | INFO |

| 769386 | testuser | localhost | NULL | Sleep | 210 | | NULL |

| 769390 | testuser | localhost | testdb | Query | 0 | executing | select * from information_schema.processlist |

2 rows in set (0.00 sec)

授予了PROCESS权限后，可以看到所有用户的链接

mysql> grant process on . to 'testuser'@'%';

Query OK, 0 rows affected (0.01 sec)

mysql> flush privileges;

Query OK, 0 rows affected (0.00 sec)

mysql> show grants;

| Grants for testuser@% |

| GRANT PROCESS ON . TO 'testuser'@'%' |

| GRANT SELECT, INSERT, UPDATE, DELETE ON testdb.* TO 'testuser'@'%' |

2 rows in set (0.00 sec)

mysql> show processlist;

| Id | User | Host | db | Command | Time | State | Info |

| 769347 | root | localhost | testdb | Sleep | 53 | | NULL |

| 769357 | root | 192.168.85.0:61709 | NULL | Sleep | 521 | | NULL |

| 769386 | testuser | localhost | NULL | Sleep | 406 | | NULL |

| 769473 | testuser | localhost | testdb | Query | 0 | starting | show processlist |

4 rows in set (0.00 sec)

通过 show processlist 所得结果，我们可以清晰了解各线程链接的详细信息。具体字段含义还是比较容易理解的，下面具体来解释下各个字段代表的意思：

Id：就是这个链接的唯一标识，可通过 kill 命令，加上这个Id值将此链接杀掉。

User：就是指发起这个链接的用户名。

Host：记录了发送请求的客户端的 IP 和 端口号，可以定位到是哪个客户端的哪个进程发送的请求。

db：当前执行的命令是在哪一个数据库上。如果没有指定数据库，则该值为 NULL 。

Command：是指此刻该线程链接正在执行的命令。

Time：表示该线程链接处于当前状态的时间。

State：线程的状态，和 Command 对应。

Info：记录的是线程执行的具体语句。

当数据库链接数过多时，筛选有用信息又成了一件麻烦事，比如我们只想查某个用户或某个状态的链接。这个时候用 show processlist 则会查找出一些我们不需要的信息，此时使用 information_schema.processlist 进行筛选会变得容易许多，下面展示几个常见筛选需求：

只查看某个ID的链接信息

select * from information_schema.processlist where id = 705207;

筛选出某个用户的链接

select * from information_schema.processlist where user = 'testuser';

筛选出所有非空闲的链接

select * from information_schema.processlist where command != 'Sleep';

筛选出空闲时间在600秒以上的链接

select * from information_schema.processlist where command = 'Sleep' and time > 600;

筛选出处于某个状态的链接

select * from information_schema.processlist where state = 'Sending data';

筛选某个客户端IP的链接

select * from information_schema.processlist where host like '192.168.85.0%';

2.杀掉数据库链接

如果某个数据库链接异常，我们可以通过 kill 语句来杀掉该链接，kill 标准语法是：KILL [CONNECTION | QUERY] processlist_id;

KILL 允许使用可选的 CONNECTION 或 QUERY 修饰符：

KILL CONNECTION 与不含修改符的 KILL 一样，它会终止该 process 相关链接。

KILL QUERY 终止链接当前正在执行的语句，但保持链接本身不变。

杀掉链接的能力取决于 SUPER 权限：

如果没有 SUPER 权限，则只能杀掉当前用户发起的链接。

具有 SUPER 权限的用户，可以杀掉所有链接。

遇到突发情况，需要批量杀链接时，可以通过拼接 SQL 得到 kill 语句，然后再执行，这样会方便很多，分享几个可能用到的杀链接的 SQL ：

杀掉空闲时间在600秒以上的链接，拼接得到kill语句

select concat('KILL ',id,';') from information_schema.processlist

where command = 'Sleep' and time > 600;

杀掉处于某个状态的链接，拼接得到kill语句

select concat('KILL ',id,';') from information_schema.processlist

where state = 'Sending data';

select concat('KILL ',id,';') from information_schema.processlist

where state = 'Waiting for table metadata lock';

杀掉某个用户发起的链接，拼接得到kill语句

select concat('KILL ',id,';') from information_schema.processlist

user = 'testuser';

这里提醒下，kill 语句一定要慎用！特别是此链接执行的是更新语句或表结构变动语句时，杀掉链接可能需要比较长时间的回滚操作。

总结：

本篇文章讲解了查看及杀掉数据库链接的方法，以后怀疑数据库有问题，可以第一时间看下数据库链接情况。
————————————————
版权声明：本文为CSDN博主「y咯p秒杀软」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_35990581/article/details/113952377

mysql> select concat('KILL ',id,';') from information_schema.processlist where user='root';
concat('KILL ',id,';')
KILL 2476;
KILL 2447;

2 rows in set (0.00 sec)

1、环境清理，删除测试数据，用于测试的环境配置
2、权限回收，检查不合理的用户权限，不需要的dba权限，非必要的数据库连接
3、压力测试总结
4、参数优化报告
5、基础信息统计
6、备份恢复测试报告
7、性能基线报告

  1. 查看mysql版本
    输入如下命令，回车，再输入mysql密码，即可查看mysql的版本。

    mysql -uroot -p

mysql的版本为：5.7.20-log

  1. 查看服务器版本
    通过如下命令：

    cat /etc/redhat-release

服务器版本为：CentOS Linux release 7.4.1708 (Core)

  1. 下载percona-xtrabackup
    通过如下命令下载：

官网路径：https://www.percona.com/downloads/Percona-XtraBackup-LATEST/

wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.4/\
binary/redhat/7/x86_64/percona-xtrabackup-24-2.4.4-1.el7.x86_64.rpm

注意：
percona-xtrabackup在官网最新版本是8.0，8.0版本只支持mysql8.0和percona8.0
早于mysql8.0的版本需要使用xtrabackup 2.4版本备份和恢复，因此我们上次选择的是2.4.4版本。
2.4版本的官网文档地址：https://www.percona.com/doc/percona-xtrabackup/2.4/index.html

通过如下命令安

yum localinstall -y percona-xtrabackup-80-8.0.5-1.el7.x86_64.rpm

  1. 全量备份

    innobackupex --defaults-file=${my.cnf} --user=${user} --password=${password} /opt

其中my.cnf为配置文件地址，user和password变量为数据库账号和密码，/opt为备份存储目录。

  1. 预处理

    innobackupex --user=${user} --password=${password} --apply-log /opt/2019-07-16_16-38-13

其中user和password变量为，数据库账号和密码，/opt/2019-07-16_16-38-13为备份存储目录。

  1. scp到从库

    scp -r /opt/2019-07-16_16-38-13 root@192.192.2.26:/opt

  2. 关闭从库并清空从库数据和日志信息

    systemctl stop mysqld

rm -rf ${dataPath}

dataPath为数据库数据所在目录的文件

  1. 在从库上恢复数据

    innobackupex --user=${user} --password=${password} --copy-back /opt/2019-07-16_16-38-13

其中user和password变量为，数据库账号和密码，/opt/2019-07-16_16-38-13为备份存储目录。

  1. 修改权限

    chmod -R 777 ${dataPath}

dataPath为数据库数据所在目录的文件

  1. 查看master位置

    cat /opt/2019-07-16_16-38-13/xtrabackup_binlog_info

结果如下：

mysql-bin.000468 742632435

  1. 从库执行同步
    打开mysql命令客户端，执行如下sql语句

    change master to master_host=${host}, master_user=${user}, master_password=${password}, master_log_file='mysql-bin.000468',master_log_pos=742632435

其中host为主库ip，user和password为主库账号密码，master_log_file和master_log_pos取第10步，获取到的值。

启动从库复制，执行如下sql语句

start slave;

经过以上步骤，即恢复mysql主从同步
————————————————
版权声明：本文为CSDN博主「chuxiongzouzhihui」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/u013294608/article/details/96114174

客户单位部署了2套logic dg ，考虑到可能会查询，转载备用。

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

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

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

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

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

 COLUMN DICT_BEGIN FORMAT A15;
 COLUMN FILE_NAME FORMAT A50;
 SET NUMF 9999999;
 COL FCHANGE# FORMAT 9999999999999;
 COL NCHANGE# FOR 999999999999999999999;
 SET LINE 200
 SELECT  FILE_NAME, SEQUENCE# AS SEQ#, FIRST_CHANGE# AS FCHANGE#,
         NEXT_CHANGE# AS NCHANGE#, TIMESTAMP, DICT_BEGIN AS BEG,
         DICT_END AS END, THREAD# AS THR#, APPLIED
    FROM DBA_LOGSTDBY_LOG
ORDER BY THREAD#,SEQUENCE#;

SET LINE 9999 PAGESIZE 9999
COL FILE_NAME FORMAT A120
SELECT THREAD#,SEQUENCE#, FILE_NAME, APPLIED, TIMESTAMP 
FROM DBA_LOGSTDBY_LOG D 
WHERE D.SEQUENCE# >=(SELECT MAX(SEQUENCE#)-3 FROM  DBA_LOGSTDBY_LOG NB WHERE  NB.THREAD#=D.THREAD# AND NB.APPLIED='YES' ) 
ORDER BY THREAD#,D.SEQUENCE#;

3.查看备库SQL Apply的进度

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

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

 COL EVENT_TIMESTAMP FORMAT A30
 COL EVENT FORMAT A40
 COL EVENT_STATUS FORMAT A80
 SELECT A.EVENT_TIME,
        A.CURRENT_SCN,
        A.COMMIT_SCN,
        XIDUSN,
        XIDSLT,
        XIDSQN,
       TO_CHAR(EVENT) EVENT,
       A.STATUS_CODE,
       STATUS EVENT_STATUS
  FROM DBA_LOGSTDBY_EVENTS A
 WHERE A.EVENT_TIME >= SYSDATE - 10 / 1660
 ORDER BY A.EVENT_TIME ;

5.查看备库SQL Apply的状态

COL REALTIME_APPLY FORMAT A15
COL STATE FORMAT A20
SELECT * FROM V$LOGSTDBY_STATE;
PRIMARY_DBID SESSION_ID REALTIME_APPLY       STATE
------------ ---------- --------------- ---------------
262089084          1                 Y         APPLYING

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

 INITIALIZING：LogMiner SESSION已创建并初始化

 LOADING DICTIONARY：SQL应用调用LogMiner字典

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

 APPLYING：SQL应用正在工作

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

 IDLE：SQL应用工作非常出色，处于空闲状态

 SQL APPLY NOT ON：没有开启应用

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

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

 EXECUTE DBMS_LOGSTDBY.SKIP(STMT => 'VIEW');
 EXECUTE DBMS_LOGSTDBY.SKIP(STMT => 'PROFILE');
 EXECUTE DBMS_LOGSTDBY.SKIP(STMT => 'DATABASE LINK');
 EXECUTE DBMS_LOGSTDBY.SKIP(STMT => 'CREATE VIEW');
 EXECUTE DBMS_LOGSTDBY.SKIP(STMT => 'DROP VIEW');
 EXECUTE DBMS_LOGSTDBY.SKIP(STMT=>'SCHEMA_DDL', SCHEMA_NAME=>'%', OBJECT_NAME=>'%', PROC_NAME=>NULL);
 EXECUTE DBMS_LOGSTDBY.SKIP(STMT=>'SCHEMA_DDL', SCHEMA_NAME=>'LHR', OBJECT_NAME=>'%', PROC_NAME=>NULL);
 EXECUTE DBMS_LOGSTDBY.SKIP(STMT=>'SCHEMA_DDL', SCHEMA_NAME=>'MDSYS', OBJECT_NAME=>'%', PROC_NAME=>NULL);



EXEC DBMS_LOGSTDBY.SKIP_TRANSACTION (3, 3, 827); --(XIDUSN = 3, XIDSLT = 3, XIDSQN = 827)
SELECT 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;
SELECT '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;

SELECT * FROM DBA_LOGSTDBY_SKIP;
SELECT * FROM DBA_LOGSTDBY_SKIP_TRANSACTION;

7.增加apply进程个数

如果Apply进程过于繁忙，那么可以增加Apply进程个数。以下命令调整为20，默认为5个:

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('APPLY_SERVERS',20);
SQL> 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控制）。如果希望禁用自动删除的功能，那么可以执行下列语句：

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

在告警日志中会有类似如下的记录：

Fri Jul 27 13:48:53 2018
LOGMINER: Log Auto Delete - deleting: /u01/app/oracle/flash_recovery_area/ORADGLG/1_202_886695024.dbf
Deleted 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来决定了）的文件进行标记，例如：

EXECUTE DBMS_LOGSTDBY.PURGE_SESSION;

然后，查询数据字典DBA_LOGMNR_PURGED_LOG，所有被DBMS_LOGSTDBY. PURGE_SESSION标记不再需要的日志都会记录在这里，例如：

SELECT * FROM DBA_LOGMNR_PURGED_LOG;

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

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

如果备库上有很多事务在等待Apply，但是还有空闲的Applier进程，且已经没有idle状态的PREPARER（调制机）进程，这时需要增加PREPARER的进程数。以下命令调整为4个，默认为1个:

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

10.调整MAX_SGA，防止Paged out

通过以下SQL可以查询到是否发生了Paged out：

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

如果以上查询结果在增长，那么查看当前MAX_SGA的大小:

SQL>select value from v$logstdby_stats where name like 'maximum SGA for LCR cache%';

VALUE
---------------------------------------------------------------
30

可以增大MAX_SGA:

SQL>alter database stop logical standby apply;
SQL>execute dbms_logstdby.apply_set('MAX_SGA',1000);
SQL>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应用:

SQL>ALTER DATABASE STOP LOGICAL STANDBYAPPLY;

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

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

③重新启动SQL应用

SQL>ALTER DATABASE START LOGICAL STANDBYAPPLY IMMEDIATE;

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

①还是先停止SQL应用：

SQL>ALTER DATABASE STOP LOGICAL STANDBYAPPLY;

②重置参数PRESERVE_COMMIT_ORDER的初始值：

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

③重新启动SQL应用：

SQL>ALTER DATABASE START LOGICAL STANDBYAPPLY IMMEDIATE;

————————————————
版权声明：本文为CSDN博主「小麦苗DBA宝典」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/lihuarongaini/article/details/104586179

execute dbms_logstdby.skip(stmt => 'DML',schema_name => '%', object_name => '%');

stmt的取值可以是：
http://download-west.oracle.com/docs/cd/B14117_01/appdev.101/b10802/d_lsbydb.htm#997290
// 跳过的内容记载在下面

select * from dba_logstdby_skip

// 停止apply

alter database stop logical standby apply;
alter database abort logical standby apply;

// 执行apply

alter database start logical standby apply;

// 实时apply

alter database start logical standby apply immediate;

// 跳过错误，在dba_logstdby_skip表中，ERROR列为Y

execute dbms_logstdby.skip_error('NON_SCHEMA_DDL');

// 执行apply，跳过失败的事务

alter database start logical standby apply skip failed transaction;

// 设置参数，是否记录跳过错误

exec dbms_logstdby.apply_set('RECORD_SKIP_ERRORS','FALSE');

// 设置参数，是否记录跳过DDL

exec dbms_logstdby.apply_set('RECORD_SKIP_DDL','FALSE');

// 在备库上关掉dataguard，备库可写

alter database guard none;

// 在备库上启用dataguard，备库不可写

alter database guard all;

// 官方文档
http://download-west.oracle.com/docs/cd/B14117_01/server.101/b10823/toc.htm

//执行某个表不通过，手工同步表

alter database stop logical standby apply;

// 创建DBLINK指向主库，然后同步创建表

exec dbms_logstdby.instantiate_table('EYGLE','SALES','dblink_name');

alter database start logical standby apply;

// 手工添加备库的日志

$ cp /u01/arch/WENDING/1_22751_666200636.arc /u04/arch/WDSTD/log_1_22751_666200636.arc

SQL> alter database register logical logfile '/u04/arch/WDSTD/log_1_22751_666200636.arc';
or
SQL> alter database register or replace logical logfile '/u04/arch/WDSTD/log_1_22751_666200636.arc';

//查看最后的进度

select LATEST_SCN,MINING_SCN,APPLIED_SCN,LATEST_TIME,MINING_TIME,APPLIED_TIME from V$LOGSTDBY_PROGRESS;

// 监控同步进度的脚本

SELECT * FROM dba_logstdby_log;
select * from dba_logstdby_events order by event_time desc;
select LATEST_SCN,MINING_SCN,APPLIED_SCN,LATEST_TIME,MINING_TIME,APPLIED_TIME from V$LOGSTDBY_PROGRESS;
select LOGSTDBY_ID,type,status process_status from v$logstdby_process;
select * from v$logstdby_state;
select * from v$dataguard_status order by timestamp desc;

// 增加apply的进程数

ALTER DATABASE STOP LOGICAL STANDBY APPLY; --- Stop SQL Apply
EXECUTE DBMS_LOGSTDBY.APPLY_SET('APPLY_SERVERS', 20); --- 调整apply进程数为20，默认为5个
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; --- Start real-time Apply

// 停止apply时，如果当前正在应用，会等待执行后才停止
// 下面的命令可以重复执行，如果执行提示stop，则意味着正在apply还没有结束，等结束后重新执行即可
ALTER DATABASE START LOGICAL STANDBY APPLY;
————————————————
版权声明：本文为CSDN博主「wonder4」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/wonder4/article/details/5630658

  1. 1
  2. ...
  3. 14
  4. 15
  5. 16
  6. 17
  7. 18
  8. 19
  9. 20
  10. ...
  11. 29