提问背景
Oracle国产化替代浪潮中，OceanBase以高度兼容Oracle为卖点，但实际迁移中常遇存储过程依赖、高级功能缺失等问题。例如，PL/SQL包中的UTL_FILE、DBMS_SCHEDULER，以及层次查询CONNECT BY等是否完全等效？现有评估工具能否覆盖全部兼容性风险？
具体问题
- 存储过程中大量使用UTL_FILE读写操作系统文件，OceanBase是否提供替代方案（如外部表、文件UTL）？若需改造，推荐模式是什么？
- 对于Oracle高级队列（AQ），OceanBase是否有对应功能？分布式事务中的消息持久化如何实现？
- 层次查询（CONNECT BY PRIOR）在复杂数据集（如数百万节点）上的性能表现如何？执行计划是否支持类似Oracle的nocycle、connect_by_root等扩展？
- 迁移评估阶段，有无官方工具可扫描Oracle数据库对象，自动生成兼容性报告并估算改造工作量？目前社区版对PL/SQL包（如DBMS_CRYPTO、DBMS_SQL）的支持列表在哪里可以查到？
问题价值
Oracle迁移复杂度高，深挖这些兼容性细节能帮助企业提前规避风险，降低迁移成本，也能推动OceanBase完善对Oracle特性