时间的印记

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

周末参加了一个数据库的维护培训，感觉颇有收获，突然想记录一下，其实工作中会有各种技能培训，参加了也不少，也组织过一些，回想一下哪些培训是真正有意义的，有收获的？
首先一般一次培训2个小时左右，即使活力非常密集，全部是干货，到头来真正能留在头脑里面的也是少数，因为人在一个时刻的记忆是有限，理解力也是有限的，培训的价值就在于启发思维，打破定式，指明方向。
授人以鱼不如授人以渔，重要的是思维方式的传递。
如何组织一次有效的培训呢？
第一、对于参与的听众需求也明确的了解，能够有针对性的培训。
第二、对于材料的充分准备，能够引用多个不同的方面对观点进行论证。
第三、有层次的展现培训的内容，讲解逻辑合理，循序渐进。
第四、预演准备。

核心业务上线前数据库的重要工作

作者: wukaiqiang
时间: 2022-01-07
分类: ORACLE,IT运维
评论

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

mysql 主从重新同步

作者: wukaiqiang
时间: 2022-01-06
分类: MYSQL
评论

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

mysql的版本为：5.7.20-log

查看服务器版本
通过如下命令：
cat /etc/redhat-release

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

下载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

全量备份
innobackupex --defaults-file=${my.cnf} --user=${user} --password=${password} /opt

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

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

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

scp到从库
scp -r /opt/2019-07-16_16-38-13 root@192.192.2.26:/opt
关闭从库并清空从库数据和日志信息
systemctl stop mysqld

rm -rf ${dataPath}

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

在从库上恢复数据
innobackupex --user=${user} --password=${password} --copy-back /opt/2019-07-16_16-38-13

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

修改权限
chmod -R 777 ${dataPath}

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

查看master位置
cat /opt/2019-07-16_16-38-13/xtrabackup_binlog_info

结果如下：

mysql-bin.000468 742632435

从库执行同步
打开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

logic dg 查询常用语句。

作者: wukaiqiang
时间: 2022-01-04
分类: ORACLE
评论

客户单位部署了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

mysql 杀会话

培训的意义

核心业务上线前数据库的重要工作

mysql 主从重新同步

logic dg 查询常用语句。

最新文章

分类

归档

其它