这是我的问题：

>我们有一个名为：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)