雅冰石的专栏

关键执行1.2步，1.1/1.3结合实际环境操作。

如果有同事误删除数据了，可以用logmnr挖掘归档日志，生成回滚sql，快速恢复数据，比用整个库的备份恢复要快得多。#注意，只分析第一个日志文件的时候加,，后面的文件不要加这个，否则会少数据。

当执行新的SQL语句时，如果这条SQL语句不在共享池中，数据库会进行硬解析，并将解析后的执行计划加载到共享池中。如果执行的是共享池内已经存在的SQL语句，则只会进行软解析，LAST_LOAD_TIME的值不会改变。假如同事让排查某个接口都有哪些慢sql，可以使用这个方法（先调用下这个慢接口，然后统计下这个时间段内的慢sql），只是会导出非这个接口的多余慢sql，再结合业务进行筛选吧。#统计共享池中某类sql执行次数，总体执行时长，平均执行时长等信息，并按总体执行时长降序排序。

有时，一个事务里会包含多个sql，有的还包含上传附件等操作，一个事务长时间不提交会导致其他相关sql被阻塞，比如事务里的sql执行得很快，但上传附件卡住的话，那也会阻塞其他相关sql。查看锁阻塞的sql只能查看到阻塞方事务最近执行的一条sql，查不到之前的sql，所以有时候查出的阻塞结果不准确，这时候需要结合对这个表的审计来确定阻塞方sql。开发同事反馈生产环境某个接口慢，一个普通的按主键更新的update竟然需要5分钟，而我手动执行秒返回，猜测是发生了阻塞，需要排查出阻塞源。会话2会被会话1阻塞。

可以看到该会话执行过的sql，sql_id，PLAN HASH，用户名，等待事件等信息。#跟踪源端sid为372,serial#为58441的会话。#在要被追踪的会话里执行。

union前的sql可以查看源端执行过的sql（在一个事务里执行了，但是还没提交）。但是假如源端执行了这个事务后，又执行了其他事务，这时候查看源端阻塞sql就不准确了。union后的sql可以查看当前源端正在执行的sql。模拟一个会话update一条记录，没提交。在每条记录里可以看到是谁阻塞了谁。978阻塞了729；372阻塞了616。这时结果是不准确的。

点击上面截图里右下方的‘组织列’，可以调整这些列的顺序。都配置好后，点击‘运行’按钮。

统计某类sql执行次数，并按总体cpu消耗时间降序排序。

近期生产环境几台sql server从库cpu使用率总是打满，发现抓的带变量值的慢sql，手动代入变量值执行并不慢，秒级返回，不知道问题出在哪里。

用SSMS可以看到每条慢sql的详细记录，但如果sql较多，可以用sql筛选想查的数据，比较灵活。查看下生成的xel文件，手动改下下面的xel文件名。有两种方式可以查询。

检查从库IO进程和SQL进程状态是否为Yes，检查AUTO_POSITION值。理论上这可能是空的，然后又不是空的。这不是问题，只要它是空过一次就可以。

生产环境当有关于一个大表的大操作时(比如select count一个大表)，此时对大表做DDL会被阻塞，提示等待table metadata lock。如果业务比较频繁的话，该DDL会阻塞关于该表的后续select sql。如果生产库cpu使用率打满，想通过创建索引优化导致cpu使用率打满的慢sql时，被阻塞了，则无法快速处理该故障。使用gh-ost工具可以在不锁表的情况下在线修改表结构，仅仅在最后切换表名(rename table)时锁表，但很快，就一两秒左右。

假如割接有问题，从云上B回滚到C，不覆盖IDC的A，这样保险些。2、根据数据量大小决定提前一天或者多久做好全量+增量数据同步，关注增量同步状态，日志等信息。4、检查DRS增量同步状态，确认状态为“增量迁移中”，且同步无延迟(A->B,B->C)以华为云DRS为例--检查A库和B库据数据一致性，数据行比对，确认数据源目的数据一致。② 等迁移任务1到增量状态之后，再创建云B到idc C的全量+增量实时迁移任务2。2. 选择行数对比（迁移对比->数据级对比->创建对比任务->行数对比)还有的话，将其kill。

线上发现一条类似这样的慢sql（查询时长8s）：from t15;t14的id和id2字段上都有索引，但是因为条件里有or，导致走的是全表扫描:如果没用count(*),而是select 字段这种方式，那可以用union这种方式替代or，但这里是count(),则有些不同。

1、需要确保下面这个sql查询出来的ENABLED值为YESselect ENABLED from performance_schema.setup_instruments WHERE NAME = 'wait/lock/metadata/sql/mdl';如果为NO，则需要先将其开启：UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES'WHERE NAME = 'wait/lock/metadat

由于sql server 备份事务日志会截断事务日志信息（截断的概念：就是把某个位置之前的所有事务日志信息全都设置为可重用，后续就可以被其他信息覆盖），所以如果要追查的事务日志已经被截断，那么则需要添加上事务日志备份。但实际运行的时候可能中间还夹杂了很多 insert/update以及其他行的delete,假如我们只想要这个事务语句操作的undo脚本，则可以根据事务号来恢复数据。如果说，并发很多或者行数太多，我们手动恢复比较困难。比如，我们这里的误操作是。解压安装包后，点击：ApexSQLLog.exe。

有时某个时间段cpu使用率高或者有其他问题，想看下那个时间段的top sql，可以使用OEM看ASH。根据筛选谓词去原sql里查找，可以看到具体慢在哪里。

/在①delete过程中，多次执行该sql，前几次很快（2秒钟）执行完毕，t1数据量是删除前的数据量，但发现有时会阻塞，阻塞了74秒，进程状态是Executing hook on transaction begin，不阻塞后，显示查询结果为0，读到的是① delete后的数据量。//在①delete过程中，多次执行该sql，t1数据量一直是删除前的数据量，直到① delete完毕，这里变成0条数据，说明是同步复制，节点2删除完，节点1才执行成功。//①执行期间，在节点2上查询同一个表，出现阻塞。

表没有主键的时候，delete很多数据，会导致从库出现很长时间延迟，因此需要严格把控，定期检查，确保主库上不存在没有主键的表。发现trx_query为空，以前线上从库出现延迟，能看到当前运行的sql的，不知为何这次看不到。因为上面已经在从库建过主键了，所以从库复制会停止，提示主键冲突，可以通过跳过这个事务来处理。#查看慢事务对应的进程id，注意别多杀了，只杀运行时间很久的，导致延迟的sql。如果没有主键，就需要先在从库上为这个表建下主键，先解决这个延迟的问题。只需要在从库执行以下命令就能跳过一个事务。