Oracle查询仅在添加随机注释时一致运行
编辑:解决了!感谢@kfinity.
AskTom建议在查询开始时使用select/*+ opt_param('_ optimizer_use_feedback''false')*/来禁用反馈用法.这解决了我的问题.
tldr:向查询添加随机注释使其运行一致,删除此注释会破坏它.
警告:很久.
环境
我首选的工作方式是将源代码中的查询作为字符串,以便它们处于版本控制状态,我可以看到随时间的变化.与我一起使用dapper和oracle.ManagedDataAccessNuGet包.有问题的应用程序是在.NET Framework 4.7.2上运行的WPF应用程序(在两种情况下).我正在使用Visual studio professional 2017 15.9.5.
问题
大约一年前,我遇到了一个查询问题.我不记得它是什么,我知道我没有时间记录它并在此发布.我现在这样做,我遇到了同样的问题.那时我想知道如果我重新启动我的电脑或更改查询文本,它会再次正常运行.只是偶尔会出现问题的症状,我会在查询中添加注释,或者删除之前的那个,我会在每个版本中测试该特定功能.我每次都会测试它,因为如果我的机器出现故障,它在目标用户机器上也会出错.当时我认为这是我的电脑的驱动程序/硬件问题.我想通过改变查询文本来解决它的方法是因为我会ctrl-x ctrl-v从代码中剪切并粘贴()整个查询Oracle developer并在那里编辑它.在某些时候,我注意到甚至一个额外的空格或输入将使它再次工作.
回到现在,我又遇到了问题.这一次是不同的,因为它不会偶尔失败.这非常一致.回想一下我是如何理解这是一个驱动程序/硬件问题,我在3台不同的机器上构建并运行应用程序,结果相同.我可以运行查询Oracle developer,使用ctrl + end运行整个查询,而不仅仅是50行.它运行大约10秒钟.它一次又一次地运行,如果没有任何变化,这是有道理的.
如果我从我的应用程序运行它,它运行正常 - 但只有一次.它也需要大约10秒钟.如果我刷新再次运行查询的数据,它会挂起.没有例外,如果我打破调试器,它只会让database.Query<>()电话冷却.如果我重新启动我的电脑或更改查询,它将运行 - 只需一次.
v $ session_longops /全表扫描
当然,我去谷歌寻求帮助.找到一些有趣的文章并没有真正帮助我:
直到我发现这个:
https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1191435335912
他们提到v$session_longops了据说让我们深入了解长期运营的情况.
select *
from v$session_longops
where time_remaining > 0
我在刷新应用程序中的数据时运行了这个,导致查询再次运行.我看到了这个:
第一个查询运行正常,索引很好.第二次启动全表扫描.它不需要这个,因为它在第一次运行时也运行正常oracle developer.正如预期的那样,如果我让它保持运行(超过20分钟),表扫描就会完成,我得到的结果与第一次相同.
我发现你可以explain plan for用来解释一个查询计划,而无需使用GUI Oracle developer.这给了我两个完全不同的计划,一个Oracle developer总是有这个笔记:- 'PLAN_TABLE' is old version.所以我不确定我是否可以信任这些信息,我不知道如何处理它.
修复
就像我之前说的那样,添加或删除注释或者更改查询文本可以解决问题并且不会启动全表扫描.我添加了一个包含DateTime.Now在查询中的注释,以便它始终不同.它一直有效.虽然从技术上来说这解决了这个问题,但我觉得这对于一个更荒谬的问题来说是一个非常荒谬的解决方案.我宁愿知道为什么会这样,如果我可能做错了什么.所以问题是,为什么随机评论会修复我的查询？
代码
一些上下文:这是一个ERP系统,查询得到所有具有分层结构的工作者,或者仅仅是他们自己,将它们组合在一起,然后添加他们所需的材料和一些其他信息,如他们的描述.它只适用于尚未关闭的工作人员.
SQL:
select
--Hierarchic info, some aliases exceeded 30 chars and had to be shorted to current state
hierarchic_workorders.ccn as HierarchicCcn ,
hierarchic_workorders.mas_loc as HierarchicMasLoc,
hierarchic_workorders.wo_num as HierarchicWoNum,
hierarchic_workorders.wo_line as HierarchicWoLine,
wo.item as HierarchicItem,
wo.revision as HierarchicRevision,
wo_item.description as HierarchicDescription,
wo_rtg.wc as HierarchicWorkCenter,
hierarchic_workorders.startdate as HierarchicStartDate,
hierarchic_workorders.mfgclosedate as HierarchicMfgClosedDate,
hierarchic_workorders.chassisnumbers as HierarchicChassisNumbers,
hierarchic_workorders.wo_level as HierarchicLevel,
hierarchic_workorders.parent_wo_num as HierarchicParentWoNum,
hierarchic_workorders.parent_wo_line as HierarchicParentWoLine,
hierarchic_workorders.parent_wo_bom_useq as HierarchicParentwobomuseq,
--wo bom info
wo_bom.ccn as WoRtgCcn,
wo_bom.mas_loc as WoRtgMasloc,
wo_bom.wo_num as WoRtgWoNum,
wo_bom.wo_line as WoRtgWoLine,
wo_bom.wo_bom_useq as WoRtgWobomUseq,
wo_bom.item as WoRtgItem,
wo_bom.revision as WoRtgRevision,
wo_bom_item.description as WoRtgDescription,
wo_bom.bom_comp_qty as WoRtgBomCompQty,
wo_bom.bom_commit as WoRtgCommit,
wo_bom.backflush as WoRtgBackflush,
wo_bom.issue_qty as WoRtgIssueQty,
wo_bom.commit_qty as WoRtgCommitQty,
wo_bom.reqd_qty as WoRtgReqdQty
from live.wo_bom
--===========================================================================================================================================================================
-- Maybe it's possible to remove this or the other min operation join in hierarchic_workorders, to make it faster - not sure if possible ====================================
--===========================================================================================================================================================================
left join(
select
wo_rtg_min_operation.min_operation,
wo_rtg.*
from live.wo_rtg
left join(
select
ccn,
mas_loc,
wo_num,
wo_line,
lpad(to_char(min(to_number(trim(operation)))), 4, ' ') as min_operation
from live.wo_rtg
group by ccn, mas_loc, wo_num, wo_line
)wo_rtg_min_operation
on wo_rtg_min_operation.ccn = wo_rtg.ccn
and wo_rtg_min_operation.mas_loc = wo_rtg.mas_loc
and wo_rtg_min_operation.wo_num = wo_rtg.wo_num
and wo_rtg_min_operation.wo_line = wo_rtg.wo_line
) wo_rtg
on wo_rtg.ccn = wo_bom.ccn
and wo_rtg.mas_loc = wo_bom.mas_loc
and wo_rtg.wo_num = wo_bom.wo_num
and wo_rtg.wo_line = wo_bom.wo_line
--This case when is painfully slow but it can't really be cached or indexed
and wo_rtg.operation = (
case when wo_bom.operation = ' ' then
wo_rtg.min_operation
else
wo_bom.operation
end
)
--===========================================================================================================================================================================
-- Find all open MPS orders and highest hierarchic PRP orders. Having these be a subquery instead of the starting data drastically increases performance ========================
--===========================================================================================================================================================================
join(
select
ccn,
mas_loc,
wo_num,
wo_line,
startdate,
mfgclosedate,
chassisnumbers,
wo_level,
parent_wo_num,
parent_wo_line,
parent_wo_bom_useq
from (
--===========================================================================================================================================================================
-- PRP ======================================================================================================================================================================
--===========================================================================================================================================================================
select
'PRP' as type,
wowob.ccn,
wowob.mas_loc,
wowob.wo_num,
wowob.wo_line,
apssplit_min_operation.operation_start_date as startdate,
wo.mfg_close_date as mfgclosedate,
trim(
trim(wo.user_alpha2) || ' ' ||
trim(wo.user_alpha3) || ' ' ||
trim(wo.chassis3) || ' ' ||
trim(wo.chassis4) || ' ' ||
trim(wo.chassis5)
) as chassisnumbers,
level as wo_level,
wowob.parent_wo_num,
wowob.parent_wo_line,
wowob.parent_wo_bom_useq
from live.wowob
join live.wo
on wo.ccn = wowob.ccn
and wo.mas_loc = wowob.mas_loc
and wo.wo_num = wowob.wo_num
and wo.wo_line = wowob.wo_line
left join(
select
ccn,
mas_loc,
orderident,
order_line,
lpad(to_char(min(to_number(trim(operation)))), 4, ' ') as min_operation,
operation_start_date
from live.apssplit
where schedule = 'SHOP' and order_type = 'W'
group by ccn, mas_loc, orderident, order_line, operation_start_date
) apssplit_min_operation
on apssplit_min_operation.ccn = wowob.ccn
and apssplit_min_operation.mas_loc = wowob.mas_loc
and apssplit_min_operation.orderident = wowob.wo_num
and apssplit_min_operation.order_line = wowob.wo_line
--Only select open wo's
--Underlying wo's obviously have to start BEFORE their parents, we don't have to check them all for this reason.
where apssplit_min_operation.operation_start_date is not null
and apssplit_min_operation.operation_start_date < sysdate + :days_ahead
--wo.mfg_close_date is null and
--wo.fin_close_date is null and
--wo.ord_qty - wo.scrap_qty - wo.complete_qty > 0
--and wo.start_date < sysdate + :days_ahead
--and wowob.wo_num = ' 334594'
--Grab the childs of only the highest parents.
connect by prior wowob.ccn = wowob.ccn
and prior wowob.mas_loc = wowob.mas_loc
and prior wowob.wo_num = wowob.parent_wo_num
and prior wowob.wo_line = wowob.parent_wo_line
start with wowob.ccn || wowob.mas_loc || wowob.wo_num || wowob.wo_line in (
--Subquery to select all the highest hierarchic wowob's that are still open in wo.
--Performance:
--all: 21253 in ?
--Open only: 174 in 0.155 seconds
select
wowob.ccn || wowob.mas_loc || wowob.wo_num || wowob.wo_line as wowob_key
from live.wowob
--Parent join
left join live.wowob parent_wowob
on wowob.ccn = parent_wowob.ccn
and wowob.mas_loc = parent_wowob.mas_loc
and wowob.parent_wo_num = parent_wowob.wo_num
and wowob.parent_wo_line = parent_wowob.wo_line
--end parent join
where wowob.ccn = :ccn
and wowob.mas_loc = :mas_loc
and parent_wowob.ccn is null
)
union all
--===========================================================================================================================================================================
-- MPS ======================================================================================================================================================================
--===========================================================================================================================================================================
select
'MPS' as type,
wo.ccn,
wo.mas_loc,
wo.wo_num,
wo.wo_line,
apssplit_min_operation.operation_start_date as startdate,
wo.mfg_close_date as mfgclosedate,
trim(
trim(wo.user_alpha2) || ' ' ||
trim(wo.user_alpha3) || ' ' ||
trim(wo.chassis3) || ' ' ||
trim(wo.chassis4) || ' ' ||
trim(wo.chassis5)
) as chassisnumbers,
1 as wo_level,
'' as parent_wo_num,
'' as parent_wo_line,
'' as parent_wo_bom_useq
from live.wo
join live.item_ccn
on item_ccn.ccn = wo.ccn
and item_ccn.item = wo.item
and item_ccn.revision = wo.revision
and item_ccn.mastsched = 'Y' --mps
and item_ccn.planned = ' ' --mrp
and item_ccn.prp = ' ' --NOT prp...
left join(
select
ccn,
mas_loc,
orderident,
order_line,
lpad(to_char(min(to_number(trim(operation)))), 4, ' ') as min_operation,
operation_start_date
from live.apssplit
where schedule = 'SHOP' and order_type = 'W'
group by ccn, mas_loc, orderident, order_line, operation_start_date
) apssplit_min_operation
on apssplit_min_operation.ccn = wo.ccn
and apssplit_min_operation.mas_loc = wo.mas_loc
and apssplit_min_operation.orderident = wo.wo_num
and apssplit_min_operation.order_line = wo.wo_line
--Only select open wo's
--Underlying wo's obviously have to start BEFORE their parents, we don't have to check them all for this reason.
where apssplit_min_operation.operation_start_date is not null
and apssplit_min_operation.operation_start_date < sysdate + :days_ahead
)
order by startdate
) hierarchic_workorders
on hierarchic_workorders.ccn = wo_bom.ccn
and hierarchic_workorders.mas_loc = wo_bom.mas_loc
and hierarchic_workorders.wo_num = wo_bom.wo_num
and hierarchic_workorders.wo_line = wo_bom.wo_line
--===========================================================================================================================================================================
-- Descriptions from wo. wowob and wo_bom are different items and they have different descriptions. =========================================================================
--===========================================================================================================================================================================
left join live.wo
on wo.ccn = hierarchic_workorders.ccn
and wo.mas_loc = hierarchic_workorders.mas_loc
and wo.wo_num = hierarchic_workorders.wo_num
and wo.wo_line = hierarchic_workorders.wo_line
left join live.item wo_item
on wo_item.item = wo.item
and wo_item.revision = wo.revision
left join live.item wo_bom_item
on wo_bom_item.item = wo_bom.item
and wo_bom_item.revision = wo_bom.revision
C#(不起作用):
using (IDbConnection database = new OracleConnection(_applicationSettings.OracleConnectionString))
{
DynamicParameters parameters = new DynamicParameters();
parameters.Add("ccn", ccn);
parameters.Add("mas_loc", masLoc);
parameters.Add("days_ahead", daysAhead);
return database.Query<HierarchicWoWoBom>(Query, parameters).ToList();
}
C#(确实一致):
using (IDbConnection database = new OracleConnection(_applicationSettings.OracleConnectionString))
{
DynamicParameters parameters = new DynamicParameters();
parameters.Add("ccn", ccn);
parameters.Add("mas_loc", masLoc);
parameters.Add("days_ahead", daysAhead);
return database.Query<HierarchicWoWoBom>($"-- {DateTime.Now}: randomized comment so that this query keeps working.\n"
+ Query, parameters).ToList();
}
我不确定这是否真的是一个答案，但评论太长了。
我认为快速的第一个查询随后缓慢的第二个查询通常表明存在统计/基数反馈问题。
基本上，在第一次运行查询时，优化器可能会检测到当前表/索引统计信息中估计的基数（行数）非常不准确，因此它会尝试为下次运行同一查询缓存更准确的统计信息。但有时这实际上会让事情变得更糟。
作为一个快速解决方案，AskTom 建议您可以尝试通过提示禁用该功能/*+ opt_param('_optimizer_use_feedback' 'false') */，或者使用 SQL 计划管理来保存好的计划，如 Ted 上面提到的。
从长远来看，我认为这可能表明您的一些统计数据可能已经过时了？您可以通过进行基数调整并查找计划中实际行数远高于预期行数的位置来缩小问题统计范围。基本过程是使用/*+ GATHER_PLAN_STATISTICS */提示运行查询，然后执行SELECT * FROM table(DBMS_XPLAN.DISPLAY_CURSOR(FORMAT=>'ALLSTATS LAST'));查看结果。