![应用补丁后,Oracle 10g 查询非常慢并且 CPU 使用率非常高](https://linux22.com/image/582684/%E5%BA%94%E7%94%A8%E8%A1%A5%E4%B8%81%E5%90%8E%EF%BC%8COracle%2010g%20%E6%9F%A5%E8%AF%A2%E9%9D%9E%E5%B8%B8%E6%85%A2%E5%B9%B6%E4%B8%94%20CPU%20%E4%BD%BF%E7%94%A8%E7%8E%87%E9%9D%9E%E5%B8%B8%E9%AB%98.png)
因此,根据 Oracle 支持的建议,我最近将 Oracle Database 10g 从 10.2.0.3.0 更新到 10.2.0.4.0,以解决稳定性问题(在某些系统下,这是一个已知问题,在高负载下实例会随机冻结)。
应用补丁后,稳定性问题消失了,但查询速度慢了很多,因为表上不断进行全扫描,尽管我重新计算了所有模式中所有表的统计信息,而且索引显然没有问题。我还将优化器版本值设置为上一个版本(这也是 Oracle 支持人员建议的),但到目前为止情况没有改善。
对此有什么想法吗?
答案1
最后,问题似乎是由优化不佳的 SQL 引起的。此外,似乎只有当全扫描的成本低于索引扫描的成本时,实例才会进行全扫描,因此一切似乎都正常。
答案2
我运行以下 SQL 来安排一个作业,每 2 小时对陈旧的表运行一次统计。这可以防止 10g 和 11g 中的许多 SQL 查询出错。如果表中的行修改量不超过 10%,则将跳过统计运行,直到修改了 10% 或更多的行。
-- YOu must commit when you are finished to add the line to sys.job$/dba_jobs
-- You must run this as sys to get the jobs to run as sys to get the correct path to run the job
variable jobno number;
variable instno number;
begin
select max(job)+1 into :jobno from dba_jobs;
select instance_number into :instno from v$instance;
dbms_job.submit(:jobno,
'dbms_stats.gather_database_stats(options=>''gather stale'',estimate_percent=>100,degree=>4,cascade=>true);',
trunc(sysdate)+15/24, 'sysdate+2/24',
TRUE, :instno);
end;
/
commit;