共 3 篇相关文章
这篇讲的是Oracle 12c中一个相当实用的新功能：通过数据泵工具expdp，直接将视图数据导出为类似表的数据文件。 以往，我们想迁移某个视图的数据，通常需要先创建一张临时表来存储查询结果，过程稍显繁琐。而从12c开始，expdp引入了`VIEWS_AS_TABLES`参数。作者在文中用一个完整的实例做了验证：在测试库中创建了一个关联查询的视图`v_xifenfei`，随后使用`expdp`配合该参数，直接将其数据导出为转储文件。接着，使用`impdp`导入时，通过`remap_table`参数，成功地将视图数据作为一张名为`v_xff`的新表导入到了目标库，且查询结果完全一致。 这个功能打通了视图与表在数据迁移工具链上的壁垒，特别适合在数据迁移、环境搭建或数据分发时，需要快速提取某个特定视图“快照”结果的场景，省去了中间建表的步骤，让基于视图的数据迁移变得像操作普通表一样直接和简单。
这篇讲的是在使用Oracle数据泵（EXPDP）进行数据导出时，一个容易被忽视的性能瓶颈：后台调用的SYS_XMLGEN函数。作者从实际的客户性能诊断案例出发，指出了当EXPDP进程执行到需要生成XML的环节时，可能会调用SYS_XMLGEN，而这个操作本身可能带来显著的性能开销。 文章建议，当怀疑EXPDP作业存在性能问题时，应重点检查对应时间段的AWR报告，寻找由SYS_XMLGEN引发的可疑SQL。文中提到了一种带有RULE提示符的典型SQL，并解释说，由于RULE提示会影响优化器的行为，因此在不同的优化器模式（如CBO或RBO）下，这条SQL可能生成不同的执行计划，导致性能表现差异巨大。 作者指出，一个有效的诊断步骤是，将这类SQL提取出来在SQL*Plus中手工执行，以直观评估其性能。如果执行结果确实不佳，就需要进一步深入研究其根本原因，比如是否涉及对象统计信息过时、索引缺失，或是XML模式本身的复杂性，从而采取针对性的优化措施。
这篇讲的是一个关于Oracle数据库性能的实际问题。作者从客户的生产环境出发，发现当数据库设置了`cursor_sharing=similar`参数后，执行数据泵（expdp）导出操作的速度出现了显著下降。文章通过测试验证了这一关联，并剖析了其中的技术原因：在该参数模式下，Oracle会过度合并相似SQL，导致为expdp生成大量非最优的执行计划，从而严重拖累了整个导出作业的效率。 核心发现是，这个旨在优化共享游标的参数，反而在特定的大批量数据导出场景下成为了性能瓶颈。文章给出的解决方案直接而有效——在需要进行expdp操作时，临时将参数调整为`cursor_sharing=exact`，以此绕过不必要的SQL合并，让数据泵工作在最佳状态。这个案例为DBA们提供了一个明确的踩坑记录和应对策略，在规划数据库参数与ETL任务时，需要特别留意这类潜在的相互影响。
