数据库管理-第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
@?/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表的耗时，与业务方沟通理清了逻辑脉络：
这中间就会有2个问题：
- delete对表操作可能会引起该表产生大量碎片，且这是个累积的过程，操作实践前面是1->5分钟的缓慢增加当达到一定量后就造成了较大的性能下降，因此建议用truncate来替代delete来清理全表数据
- 中间表清理重新插入数据后，统计信息大概率是异常的，因此建议在此操作步骤后添加对这张表的统计信息收集操作
在业务方根据建议完成操作后，涉及存储过程的执行时间立即从25-30分钟下降至了40秒不到，比以前“正常”时候速度还要快一些。至此优化完成。（这里还要感谢Oracle RWP团队的董志平老师的支持）
总结
老规矩，知道写了些啥。
原文地址:https://blog.csdn.net/yhw1809/article/details/134716544
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若转载，请注明出处：http://www.7code.cn/show_50375.html
如若内容造成侵权/违法违规/事实不符，请联系代码007邮箱：suwngjj01@126.com进行投诉反馈，一经查实，立即删除！
