数据库管理-第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)，发现：

从12.2-19c，DV组件无法在CDB中被卸载
20c中也仅仅只能在PDB中卸载DV组件
注意：现在提供Patch 29890347补丁包允许在PDB中卸载DV组件

有了这个消息，即可开始查看Patch 29890347: ADW18.1CDB: DV UNINSTALL SHOULD BE ALLOWED FROM WITHIN PDBS，这个补丁包比较和一般One-off patch有一点不一样，一般补丁需要关闭数据库应用，因为大多数会去影响数据库的一些运行库文件，而这个补丁包仅仅只包含了替换SQL脚本文件：
在这里插入图片描述
对应README文件里面也没有需要关闭数据库的操作，因此直接应用补丁即可（其实就是个备份、删除、复制的操作系统层面的操作）：

unzip p29890347_1913000DBRU_Generic.zip
cd 29890347
$ORACLE_HOME/OPatch/opatch apply

在这里插入图片描述
然后再在需要操作的PDB中卸载DV组件即可：

@?/rdbms/admin/dvremove.sql

脚本运行完成后检查，DV组件已被卸载：
在这里插入图片描述
到这里后续在目标端的PDB克隆迁移操作就可以一股脑的整出来了（其实以前文章有）：

create pluggable database pdb_xxx from pdb_xxx@xxx_LINK;
alter pluggable database pdb_xxx open upgrade;

$ORACLE_HOME/OPatch/datapatch -verbose

@?/rdbms/admin/utl32k.sql
@?/rdbms/admin/utlrp.sql
alter pluggable database close immediate

srvctl add service -db xxdbaas -pdb PDB_XXX -service XXXDB -preferred xxdbaas1,xxdbaas2
srvctl start service -db xxdbaas -s xxxdb

2 性能优化

3点过弄完盯了一会儿就睡觉，然后9点过早上另一个业务系统打电话说他们有个需要至少每10分钟跑一次存储过程突然变慢了，之前监控是从1分钟慢慢延长到了5分钟左右，今天突然来到25-30分钟才能完成，虽然对业务本身运行影响不大，但是也带来了一些时效性的问题。没办法，强制开机，顶着沉重的眼皮开始优化。
首先检查了存储过程中涉及的3个基表的情况，统计信息没啥问题，count(*)了一下来把数据刷入Exadata存储缓存，性能没有明显提升；其次EMCC上盯一下这个存储过程，发现主要时间耗费在一个CTAS语句中，单独拎出来跑其中的select语句也很慢，因此在EMCC上把SQL Monitor弄出来并检查执行计划，从最耗时的地方开始查看：
在这里插入图片描述
而且从下面的执行计划中还多次看到在这张FM_xxx_ALL_TEMP表的耗时，与业务方沟通理清了逻辑脉络：

先用delete命令删除多张临时表，其中包含FM_xxx_ALL_TEMP
用insert select的方式向这张表插入数据
在用CTAS新建一张表（就是慢在这个地方，后续做了啥就没必要操心）

这中间就会有2个问题：

delete对表操作可能会引起该表产生大量碎片，且这是个累积的过程，操作实践前面是1->5分钟的缓慢增加当达到一定量后就造成了较大的性能下降，因此建议用truncate来替代delete来清理全表数据
中间表清理重新插入数据后，统计信息大概率是异常的，因此建议在此操作步骤后添加对这张表的统计信息收集操作

在业务方根据建议完成操作后，涉及存储过程的执行时间立即从25-30分钟下降至了40秒不到，比以前“正常”时候速度还要快一些。至此优化完成。（这里还要感谢Oracle RWP团队的董志平老师的支持）