这是我的问题：
>我们有一个名为：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)
oracle某个存过的执行时间 java – 为什么oracle存储过程的执行时间会大大增加 具体取决于它的执行方式？...
