这是我的问题:
>我们有一个名为:HEAVY_SP的存储过程,在所有场景中都使用相同的参数
>我们有一个oracle sql开发人员.这可以称为:IDE
根据执行方式,执行时间大大增加:
>(1)直接在查询窗口(IDE)中调用HEAVY_SP(0,’F’,5,…)= 15秒(我们当前的解决方案)
>(2)使用IDE的特殊按钮= 15秒
>(3)使用dbms_job(预定执行)= 15秒(作业已调度且未执行.使用IDE执行作业:右键单击并执行)
>(4)使用dbms_job(即时执行)=超过01小时,迭代非常慢
>(5)从sql_PLUS(linux)=超过01小时,迭代很慢
>(6)从JAVA =超过01小时,迭代非常慢
>(7)从TOAD =超过01小时,迭代非常慢
我们吃了很多谷歌页面如下:
所以我的问题是:
>为什么Oracle以这种方式行事?
>在所有情况下(相同的参数),它不应该表现得很快吗?
>存储过程必须修改?
>如果查询计划,跟踪文件或统计信息显示不同的行为,则必须修复存储的prodecure?
>为什么查询窗口中的执行速度很快?
提前致谢.
TIP #1
遵循@BobJarvis关于统计数据的建议
结果:我们的统计数据是最新的.甚至,我们重新执行了EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname =>’SOME_USER’,tabname =>’SOME_TABLE’,cascade => TRUE);在所有问题表中,结果是一样的.
TIP #2
遵循@KonstantinSorokin的建议
我怀疑由于会话设置的不同,执行计划可能会有所不同.考虑比较v $ses_optimizer_env
结果:我们已经比较并且结果v $ses_optimizer_env对于(1)和(4)场景是相同的.
TIP #3
使用此查询:
select s.sid,s.serial#,s.username,s.machine,replace(q.sql_FULLTEXT,chr(0)) sql_text,s.program,s.logon_time,s.status,s.OSUSER
from v$session s,v$sql q
where
s.status='ACTIVE'
and s.username is not null
and s.sql_hash_value = q.hash_value
order by s.logoN_TIME,s.username;
我注意到机器,程序和ouser的变化取决于测试:
快速模式(查询窗口)
machine | program | ouser
--------------------|------------------ | -------
my laptop username | sql DEVELOPER | User
LAG MODE(后台执行)
machine | program | ouser
--------------------|------------------ | -------
ip-10-6-7-1 | oracle@ip-10-6-7-1| rdsdb
TIP #4
遵循@KonstantinSorokin有关跟踪的建议.
结果:一个临时DBA已经调查过,他告诉我们一些sql_id有不同的执行计划.他的建议是:使用提示.
这可能是解决方案但是,为什么有些sql ID有不同的执行计划?
[SOLVED]
感谢@IsaacMejia,NLS_COMP = LINGUISTIC是缓慢执行的原因.
必须在实例级别为NLS_COMP = BINARY设置正确的解决方案.
但就我而言,我有几个应用程序可以很好地使用这个值.因此,为了避免在我们的应用程序中排序和比较问题,我无法覆盖实例NLS设置.
临时解决方案在存储过程开始时执行:
execute immediate 'alter session set NLS_COMP=''BINARY''';
并在完成时返回上一个值:
execute immediate 'alter session set NLS_COMP=''LINGUISTIC''';
现在存储过程快速运行,直接在查询窗口中执行(ORACLE sql DEVELOPER)