这是我的问题：
>我们有一个名为：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小时,迭代非常慢
我们吃了很多谷歌页面如下：
why-does-a-query-run-slower-in-a-stored-procedure-than-in-the-query-window
oracle-pl-sql-procedure-runs-slower-than-sql
oracle-insert-in-stored-procedure-very-slow-compared-to-insert-run-manually
stored-proc-running-30-slower-through-java-versus-running-directly-on-database
所以我的问题是：
>为什么Oracle以这种方式行事？
>在所有情况下(相同的参数),它不应该表现得很快吗？
>存储过程必须修改？
>如果查询计划,跟踪文件或统计信息显示不同的行为,则必须修复存储的prodecure？
>为什么查询窗口中的执行速度很快？
提前致谢.
@H_301_40@TIP #1
遵循@BobJarvis关于统计数据的建议
结果：我们的统计数据是最新的.甚至,我们重新执行了EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname =>’SOME_USER’,tabname =>’SOME_TABLE’,cascade => TRUE);在所有问题表中,结果是一样的.
@H_301_40@TIP #2
遵循@KonstantinSorokin的建议
我怀疑由于会话设置的不同,执行计划可能会有所不同.考虑比较v $ses_optimizer_env
结果：我们已经比较并且结果v $ses_optimizer_env对于(1)和(4)场景是相同的.
@H_301_40@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
@H_301_40@TIP #4
遵循@KonstantinSorokin有关跟踪的建议.
结果：一个临时DBA已经调查过,他告诉我们一些sql_id有不同的执行计划.他的建议是：使用提示.
这可能是解决方案但是,为什么有些sql ID有不同的执行计划？
@H_301_40@[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''';
select * from NLS_SESSION_PARAMETERS
然后在商店程序内部设置变量,使它们与最快的情况相等.
execute immediate 'alter session set NLS_SORT=''SPANISH''';
一旦SP拥有所有nls参数.它会跑得快.
我刚刚在Alter session slows down the query through Hibernate发现了一个类似的案例.但在他们的情况下,他们改变de参数,然后变得缓慢.
我调查并发现参数NLS_COMP和NLS_SORT可能会影响oracle如何使用字符串的执行计划(当它比较或排序时)
当NLS_COMP定义为LINGUISTIC时,它将使用NLS_SORT中的语言定义.
例如,如果NLS_COMP = LINGUISTIC和NLS_SORT = BINARI_AI您的查询
是
select * from table where string_column like 'HI%'
在内部它会做
select * from table where
NLSSORT(string_column,'BINARI_AI') >= HEXTORAW('324242432')
NLSSORT(string_column,'BINARI_AI') >= HEXTORAW('675757576')
所以,如果你没有NLSSORT的索引(列,’BINARI_AI’),它将会很慢.
知道NLS_SORT = BINARY_AI会使您的排序和比较对重音不敏感和不区分大小写.
