oracle db trace中的动态采样查询
dynamic sampled query in oracle db trace
我有一个巨大的 Oracle Trace 文件。生成此文件的应用程序运行了 1 小时 15 分钟。
在这个 Tracefile 中,我发现了 4 个 Selects 以及一个多小时的运行时间。
问题是这些选择是由优化器采样的。
SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS IGNORE_WHERE_CLAUSE
NO_PARALLEL(SAMPLESUB) opt_param('parallel_execution_enabled', 'false')
NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),:"SYS_B_00"),
NVL(SUM(C2),:"SYS_B_01")
FROM
(SELECT /*+ IGNORE_WHERE_CLAUSE NO_PARALLEL("LST_G") FULL("LST_G")
NO_PARALLEL_INDEX("LST_G") */ :"SYS_B_02" AS C1, CASE WHEN
"LST_G"."SENDUNG_TIX"=:"SYS_B_03" AND "LST_G"."LST_K"=:"SYS_B_04" AND
"LST_G"."LST_ART"=:"SYS_B_05" AND "LST_G"."FAK_TIX"=(-:"SYS_B_06") THEN
:"SYS_B_07" ELSE :"SYS_B_08" END AS C2 FROM "TMS1033"."LST_G" SAMPLE BLOCK
(:"SYS_B_09" , :"SYS_B_10") SEED (:"SYS_B_11") "LST_G") SAMPLESUB
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 56076 3.93 4.21 0 0 0 0
Execute 56076 1.98 1.80 0 0 0 0
Fetch 56076 1127.54 1122.77 222 46487004 0 56076
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 168228 1133.45 1128.79 222 46487004 0 56076
这是四个中的一个,它们看起来几乎一样。我想我找到了原始语句,这些语句是从 Uniface-Service 执行的。我不知道 Uniface 是如何工作的,我只是负责数据库的人。
问题是我不知道为什么优化器会重建这个语句。原来的不使用 dynamic_sample
提示。我也发现了这些,我想是的,在跟踪文件中另外发现了原始的 Statments。
select count(*)
from
lst_g where sendung_tix = 10330805990396 and lst_k = 'E' and lst_art = 'G'
and fak_tix = -4
这就是为什么我不确定这些示例语句是什么的原因。有什么想法吗?
非常感谢。
该查询已启用动态采样。要么
- 查询使用
/*+ DYNAMIC_SAMPLING */
提示
- 代码发出
alter session set optimizer_dynamic_sampling=
命令
- optimizer_dynamic_sampling在数据库spfile中设置。
例如
alter session set OPTIMIZER_DYNAMIC_SAMPLING = 2;
然后针对大 table 发出一个查询,该查询具有可以使用索引的非常有选择性(但不精确)的条件。
select * from mtl_system_items /* biiig table */
where organization_id = 92
and segment1 LIKE 'DY_' /* very selective condition with index */
运行 它可以让您快速取回数据。但是,
alter session set OPTIMIZER_DYNAMIC_SAMPLING = 10;
并重新 运行 相同 SELECT
出去吃午饭,对 table 中的每个块进行采样。
我相信这些是统计信息收集作业用于更新数据库对象统计信息的查询。请检查在生成跟踪文件时是否有任何统计信息收集/更新作业 运行。
在您的案例中,从 SQL 发布的数据来看,统计数据似乎是在 "TMS1033"."LST_G" 上收集的。您发现的其他 3 SQL 也是如此。
希望对您有所帮助。
我有一个巨大的 Oracle Trace 文件。生成此文件的应用程序运行了 1 小时 15 分钟。 在这个 Tracefile 中,我发现了 4 个 Selects 以及一个多小时的运行时间。 问题是这些选择是由优化器采样的。
SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS IGNORE_WHERE_CLAUSE
NO_PARALLEL(SAMPLESUB) opt_param('parallel_execution_enabled', 'false')
NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),:"SYS_B_00"),
NVL(SUM(C2),:"SYS_B_01")
FROM
(SELECT /*+ IGNORE_WHERE_CLAUSE NO_PARALLEL("LST_G") FULL("LST_G")
NO_PARALLEL_INDEX("LST_G") */ :"SYS_B_02" AS C1, CASE WHEN
"LST_G"."SENDUNG_TIX"=:"SYS_B_03" AND "LST_G"."LST_K"=:"SYS_B_04" AND
"LST_G"."LST_ART"=:"SYS_B_05" AND "LST_G"."FAK_TIX"=(-:"SYS_B_06") THEN
:"SYS_B_07" ELSE :"SYS_B_08" END AS C2 FROM "TMS1033"."LST_G" SAMPLE BLOCK
(:"SYS_B_09" , :"SYS_B_10") SEED (:"SYS_B_11") "LST_G") SAMPLESUB
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 56076 3.93 4.21 0 0 0 0
Execute 56076 1.98 1.80 0 0 0 0
Fetch 56076 1127.54 1122.77 222 46487004 0 56076
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 168228 1133.45 1128.79 222 46487004 0 56076
这是四个中的一个,它们看起来几乎一样。我想我找到了原始语句,这些语句是从 Uniface-Service 执行的。我不知道 Uniface 是如何工作的,我只是负责数据库的人。
问题是我不知道为什么优化器会重建这个语句。原来的不使用 dynamic_sample
提示。我也发现了这些,我想是的,在跟踪文件中另外发现了原始的 Statments。
select count(*)
from
lst_g where sendung_tix = 10330805990396 and lst_k = 'E' and lst_art = 'G'
and fak_tix = -4
这就是为什么我不确定这些示例语句是什么的原因。有什么想法吗?
非常感谢。
该查询已启用动态采样。要么
- 查询使用
/*+ DYNAMIC_SAMPLING */
提示 - 代码发出
alter session set optimizer_dynamic_sampling=
命令 - optimizer_dynamic_sampling在数据库spfile中设置。
例如
alter session set OPTIMIZER_DYNAMIC_SAMPLING = 2;
然后针对大 table 发出一个查询,该查询具有可以使用索引的非常有选择性(但不精确)的条件。
select * from mtl_system_items /* biiig table */
where organization_id = 92
and segment1 LIKE 'DY_' /* very selective condition with index */
运行 它可以让您快速取回数据。但是,
alter session set OPTIMIZER_DYNAMIC_SAMPLING = 10;
并重新 运行 相同 SELECT
出去吃午饭,对 table 中的每个块进行采样。
我相信这些是统计信息收集作业用于更新数据库对象统计信息的查询。请检查在生成跟踪文件时是否有任何统计信息收集/更新作业 运行。
在您的案例中,从 SQL 发布的数据来看,统计数据似乎是在 "TMS1033"."LST_G" 上收集的。您发现的其他 3 SQL 也是如此。
希望对您有所帮助。