并行语句中的库缓存锁答案

【问题标题】：Library Cache lock in parallelized Statements并行语句中的库缓存锁
【发布时间】：2016-02-15 19:12:23
【问题描述】：

最近我注意到很多并行化查询（创建表作为选择...），这会导致高库缓存锁并发。

在以下问题中，Mihail 指出要提防长期运行的 CTAS 中的库缓存锁

create table <new_table_name> parallel <partitioning_info> as select * from <old_table_name> where <filter>;

那为什么会这样呢？硬解析的比例非常低。这是一个问题，因为所有会话都试图在库缓存中查找执行计划吗？我以为通过软解析，库缓存对象上只有一个引脚？

【问题讨论】：

唯一一次我记得 CTAS 导致锁定问题是一些具有极高并行度的错误。你可能想检查你的参数，看看PARALLEL 会走多高。它可能是 RAC 节点 * cpu_count（参数）* parallel_threads_per_cpu（参数）的组合。或者分区子句可能正在创建大量分区。您能否添加有关这些陈述的更多信息？
另外，有等待的真实数字会有所帮助。重新运行该语句，找到 SQL_ID，并通过从 dual;` 运行 select dbms_sqltune.report_sql_monitor(sql_id => '$ADD_SQL_ID_HERE) 为其生成 SQL 监控报告。将该报告的全部内容添加到问题中。

【解决方案1】：

检查 V$SQLAREA 以查看是否有 SQL 语句的解析调用次数相对较多或子游标数量较多（VERSION_COUNT 列）。检查 V$SYSSTAT 中的解析统计信息及其相应的每秒速率。

【讨论】：