为什么我不能强迫Oracle 11g为单个SQL查询消耗更多的CPU
NG *_*lgo 4 sql oracle parallel-processing
我有一些在巨大的桌子上运行的大量查询.这些查询似乎是CPU瓶颈,并运行了几个小时.据我所知,Oracle有很多新功能,11g,第2版内部并列化查询的执行.但是无论我在查询中添加什么样的提示,我似乎都不能在数据库框上使用多个CPU.我有一个非常值得尊敬的Solaris机器,有8个CPU,但是每次运行这个查询时,我最终只是将一个CPU推到100%,然后在那里坐了几个小时.
我尝试过的提示是:
SELECT /*+ PARALLEL */ ...
SELECT /*+ PARALLEL(5) */ ...
SELECT /*+ PARALLEL(10) */ ...
在查看盒子上的整体CPU消耗时,这些似乎都不起作用.似乎总是将一个CPU固定在100%.不幸的是,即使解释计划似乎也需要永远运行.我会尝试用不同的提示获得不同的解释计划,看看是否有帮助.有些查询是否可能是不可并行的,即使它们的运行时间是在几小时内？!!？此查询中的主表有3.35亿行.
SQL查询文本:
系统参数:
编辑:
详细的解释计划 - 没有并行性:
优化器相关的系统参数:
进一步编辑: 我们已经联系Oracle了解为什么EXPLAIN PLAN需要超过2个小时.我们正试图运行各种解释计划.
Jon*_*ler 12
了解Oracle并行性最重要的是它很复杂.优化并行性需要大量的Oracle知识,阅读手册,检查许多参数,测试长时间运行的查询以及许多怀疑.
问正确的问题
并行问题确实涉及三个不同的问题:
- 请求了多少个并行服务器？
- 分配了多少个并行服务器？
- 有多少并行服务器被有意义地使用？
使用最佳工具
直接使用最佳工具 - 带有活动报告的SQL监控.找到您的SQL_ID并生成HTML报告:select dbms_sqltune.report_sql_monitor(sql_id => 'your_sql_id', type => 'active') from dual;.这是了解执行计划中每个步骤花费了多少时间的唯一方法.它会告诉你有效使用了多少并行性,以及在哪里.例如:
另一个不错的选择是type => 'text'.它没有那么多的信息,但它更容易看,更容易分享.
SQL Monitoring还包括请求的DOP和分配的DOP:
100行并行select可以运行得很漂亮,但是由于未缓存的序列,所有内容都会在一步中停止.你可以盯着解释计划,追踪或AWR报告几个小时,而不是看到问题.活动报告使得缓慢的步骤几乎无足轻重.不要浪费时间猜测问题所在.
但是,仍然需要其他工具.用explain plan for ...和生成的解释计划select * from table(dbms_xplan.display); 将提供一些关键信息.具体而言,该Notes部分可以包含查询未请求并行性的许多原因.
但为什么我得到那么多的并行服务器呢？
相关信息分布在几本不同的手册中,这些手册非常有用,但偶尔也不准确或误导.关于并行性有很多神话和许多不好的建议.每个版本的技术都会发生重大变化.
当您整理所有信誉良好的来源时,影响并行服务器数量的因素列表非常大.下面的列表大致按照我认为最重要的因素排序:
- 操作间并行性使用排序或分组的任何查询将分配两倍于DOP的并行服务器.这可能是神话"Oracle分配尽可能多的并行服务器!"的原因.
- 查询提示 最好是语句级提示
/*+ parallel */,或者可能是对象级提示/*+ noparallel(table1) */.如果计划的特定步骤是串行运行的,通常是因为仅对查询的一部分提供了对象级提示. - 递归SQL某些操作可以并行运行,但可以通过递归SQL进行有效序列化.例如,大插入上的未缓存序列.生成的用于解析语句的递归SQL也将是串行的; 例如动态采样查询.
- 更改会话
alter session [force|enable] parallel [query|dml|ddl];请注意,默认情况下禁用并行DML. - 表学位
- 指数学位
- 索引更便宜 并行提示只告诉优化器考虑使用某个DOP进行全表扫描.它们实际上并不强制并行性.如果认为它更便宜,优化器仍然可以自由使用串行索引访问.(
FULL提示可能有助于解决此问题.) - 计划管理 SQL计划基准,大纲,配置文件,高级重写和SQL转换程序都可以改变背后的并行度.查看计划的"注释"部分.
- 仅版企业版和个人版允许并行操作.包DBMS_PARALLEL_EXECUTE除外.
- PARALLEL_ADAPTIVE_MULTI_USER
- PARALLEL_AUTOMATIC_TUNING
- PARALLEL_DEGREE_LIMIT
- PARALLEL_DEGREE_POLICY
- PARALLEL_FORCE_LOCAL
- PARALLEL_INSTANCE_GROUP
- PARALLEL_IO_CAP_ENABLED
- PARALLEL_MAX_SERVERS 这是整个系统的上限.这里有一个权衡.一次运行太多并行服务器对系统不利.但是,对于某些查询,将查询降级为串行可能是灾难性的.
- PARALLEL_MIN_PERCENT
- PARALLEL_MIN_SERVERS
- PARALLEL_MIN_TIME_THRESHOLD
- PARALLEL_SERVERS_TARGET
- PARALLEL_THREADS_PER_CPU
- RAC节点数默认DOP的另一个乘数.
- CPU_COUNT如果使用默认DOP.
- RECOVERY_PARALLELISM
- FAST_START_PARALLEL_ROLLBACK
- Profile
SESSIONS_PER_USER还限制了并行服务器. - 资源经理
- 系统加载 如果parallel_adaptive_multi_user为true.可能无法猜测Oracle何时会开始限制.
- PROCESSES
- 并行DML限制如果出现以下任何一种情况,并行DML将无法工作:
- 兼容<9.2用于分区内
- INSERT VALUES,带触发器的表
- 复制
- 自引用完整性或删除级联或延迟完整性约束
- 访问对象列
- 带有LOB的非分区表
- 与LOB的分区内并行性
- 分布式交易
- 集群表
- 临时表
- 标量子查询不并行运行？ 这是在手册中,我希望这是真的,但我的测试表明并行性在这里工作在11g.
- ENQUEUE_RESOURCES 10g中的隐藏参数,这是否相关？
- 索引组织表不能并行路径到IOT的直接路径？(这仍然是真的吗？)
- 并行流水线功能要求必须使用
CURSOR(？).去做. - 函数必须是PARALLEL_ENABLE
- 语句类型旧版本根据分区限制DML上的并行性.目前的一些手册仍然包括这一点,但它肯定不再适用.
- 分区数仅适用于旧版本的分区连接.(？)
- 错误特别是我已经看到很多解析错误.Oracle将分配正确数量的并行服务器,但不会发生任何事情,因为它们都在等待像这样的事件
cursor: pin s wait on x.
此列表肯定不完整,不包括12c功能.它没有解决操作系统和硬件问题.它并没有回答这个非常棘手的难题,"并行度的最佳程度是什么？" (简短的回答:通常更好,但牺牲其他过程.)希望它至少让你了解这些问题有多困难,并且是一个开始寻找的好地方.