数据库管理-第119期 记一次迁移和性能优化（202301130）
1 迁移
之前因为DV组件没有迁移成功的那个PDB，后来想着在目标端安装DV组件迁移，结果目标端装不上，而且开了SR也没看出个所以然来。只能换一个方向，尝试在源端PDB中删除DV组件，而DV组件的删除从12cR2开始就是一个老大难问题。最终根据How To Enable/Install/Uninstall Database Vault in oracle database ? (Doc ID 2112167.1)，发现：
有了这个消息，即可开始查看Patch 29890347: ADW18.1CDB: DV UNINSTALL SHOULD BE ALLOWED FROM WITHIN PDBS，这个补丁包比较和一般One–off patch有一点不一样，一般补丁需要关闭数据库应用，因为大多数会去影响数据库的一些运行库文件，而这个补丁包仅仅只包含了替换SQL脚本文件：
对应README文件里面也没有需要关闭数据库的操作，因此直接应用补丁即可（其实就是个备份、删除、复制的操作系统层面的操作）：
脚本运行完成后检查，DV组件已被卸载：
到这里后续在目标端的PDB克隆迁移操作就可以一股脑的整出来了（其实以前文章有）：
2 性能优化
3点过弄完盯了一会儿就睡觉，然后9点过早上另一个业务系统打电话说他们有个需要至少每10分钟跑一次存储过程突然变慢了，之前监控是从1分钟慢慢延长到了5分钟左右，今天突然来到25-30分钟才能完成，虽然对业务本身运行影响不大，但是也带来了一些时效性的问题。没办法，强制开机，顶着沉重的眼皮开始优化。
首先检查了存储过程中涉及的3个基表的情况，统计信息没啥问题，count(*)了一下来把数据刷入Exadata存储缓存，性能没有明显提升；其次EMCC上盯一下这个存储过程，发现主要时间耗费在一个CTAS语句中，单独拎出来跑其中的select语句也很慢，因此在EMCC上把SQL Monitor弄出来并检查执行计划，从最耗时的地方开始查看：
而且从下面的执行计划中还多次看到在这张FM_xxx_ALL_TEMP表的耗时，与业务方沟通理清了逻辑脉络：
这中间就会有2个问题：
