本周二凌晨，为了配合某国产数据库从oracle数据库能够实时同步数据，在x9m那套一体机上做了开启附加日志的操作，也正是因为这个操作带来了一些小问题。
1 干了些啥？
其实很标准，在主库cdb里面开启附加日志：
alter database add supplemental log data;
而这时候在emcc监控中发现某个pdb开始出现了一些问题：
数据库两条查询语句出现了大量的latch: cache buffers chains等待，业务方反馈主要是查询几乎卡死，对应操作无法执行。而这两条语句平时执行效率贼高，理应不会出现这个问题，那么根据最近做了啥操作，判定肯定是因为开启附加日志引起的。好的一点是开启附加日志的操作大概在15分钟内完成了，为了快速恢复业务，所以将对应pdb进行了重启操作：
alter pluggable database pdb_xxx close immediate instances=all;
alter pluggable database pdb_xxx open instances=all;
srvctl start service -db xxdbaas -s xxxdb
2 为什么会这样？
首先这里发生的问题很奇怪，如果是开启附加日志引起的异常等待，那么应该是所有pdb都会受到影响，然而受影响的只有一个pdb，在网上和mos查了一圈过后也没找到具体原因，只能开个sr问问，上传了标准3件套：awr报表、ash、tfactl收集的文件之后，后台也很快给了答复：
根据alter database add supplemental log data hangs (doc id 406498.1)，启用supplemental log ，这个会让所有cursor cache 里的cursor失效，这个应该是导致这些sql再次执行时候等待latch: cache buffers chains 的原因，通常来讲， 这个等待应该不会很长时间并且这么多会话同时等待，除非sql 性能很差，这个目前在您的环境中看不出来，因为在同一sample 里，很多会话执行同一sql，并且blocker是不同的。这个应该是正常的， 只是在增加supplemental log data 过程中很大概率遇到的一个情况。
这个问题也是我第一次遇到，因为附加日志开启造成的大量等待，也算是吃一堑长一智，以后所有数据库操作还是申请一个高级别的割接操作，割接期间任何影响就有据可依。这里也可以看到，一体机会给一些性能不大好的sql带来一些幻觉，因为跑的很快；另一方面即是强如exadata也不能在稍有异常的情况下跑出非凡性能。最终还好业务侧把出问题时间的坑给填了，不说了，看语句优化去了。
3 你以为就完了？
数据库的性能问题确实是解决了，但是还得去pdb里面开全列附加日志，因为要从adg备库拉取数据，而备库用于日志存储的磁盘组空间很小，因此该国产数据库技术人员提供了下面的语句来开启需要同步的对应表的全列统计信息：
declare
sqltest varchar2(200;);
begin
for t in (select table_name from all_tables where owner ='xxxx'))
loop
sqltest := 'alter table '||t.table_name||'add supplemental log data (all) columns';
execute immediate sqltest;;
dbms_output.put_line(sqltest;);
end loop;;
end;;
这里吐槽以下几点：
- loop，查一条拼接一条执行一条，这效率，有点低
- 变量大小写问题，主要是看着烦
- 作为dba不干预业务用户账号密码，那我肯定得用高权限用户去执行，那么只不是缺了个schema拼接内容
- add前面少了一个空格（尴尬症还是强迫症抑或都给整出来了）
总结
老规矩，知道写了些啥！