前一段时间客户硬软件同事升级,oracle从9i升到10g,服务器在正常运行3个月余后经受不住压力连崩数次.可怜我们这些供应商啊,原程序翻阅数边、数据库进行分析、守在服务器旁异常跟踪......
问题描述:数据库从9I升级到10G之后观察服务器性能情况发现CPU使用率远远高于9I下使用的情况,导致服务器过载。,通过Oracle工具awr分析后发现
SELECT OWNER, SYNONYM_NAME FROM SYS.ALL_SYNONYMS WHERE OWNER = 'PUBLIC' AND SYNONYM_NAME ='APPLY_SHEET_POOL' 相类似的语句占用了大量的CPU资源。对比了SYS.ALL_SYNONYMS 视图在9I和10G上的情况发现这个视图在10G上做了很大的改动,当使用这个视图是效率比9I低很多
处理过程:在咨询了oracle之后,建议增加私有同义词以跳过sys.all_synonms的处理
CREATE OR REPLACE FORCE VIEW "SYS"."ALL_SYNONYMS_9201" ……
CREATE SYNONYM ZHIYDBA.ALL_SYNONYMS FOR SYS.ALL_SYNONYMS_9201
通过性能报告分析发现依然使用 SYS.ALL_SYNONYMS 并没有使用新建立的私有同义词,通过检查找出,问题中的语句是PB在查询公有同义词对象是自动生成的,不是由Oracle生成的,因此只能考虑更改SYS.ALL_SYNONYMS视图或是减少程序中的公有同义词使用。
继续咨询Oracle可否使用9I的ALL_SYNONYMS替换10G的ALL_SYNONYMS视图,得到肯定答复。Oracle说明10G的ALL_SYNONYMS视图变化的原因是修正在同义词上再建立同义词的BUB ...... 更多。。。
问题描述:数据库从9I升级到10G之后观察服务器性能情况发现CPU使用率远远高于9I下使用的情况,导致服务器过载。,通过Oracle工具awr分析后发现
SELECT OWNER, SYNONYM_NAME FROM SYS.ALL_SYNONYMS WHERE OWNER = 'PUBLIC' AND SYNONYM_NAME ='APPLY_SHEET_POOL' 相类似的语句占用了大量的CPU资源。对比了SYS.ALL_SYNONYMS 视图在9I和10G上的情况发现这个视图在10G上做了很大的改动,当使用这个视图是效率比9I低很多
处理过程:在咨询了oracle之后,建议增加私有同义词以跳过sys.all_synonms的处理
CREATE OR REPLACE FORCE VIEW "SYS"."ALL_SYNONYMS_9201" ……
CREATE SYNONYM ZHIYDBA.ALL_SYNONYMS FOR SYS.ALL_SYNONYMS_9201
通过性能报告分析发现依然使用 SYS.ALL_SYNONYMS 并没有使用新建立的私有同义词,通过检查找出,问题中的语句是PB在查询公有同义词对象是自动生成的,不是由Oracle生成的,因此只能考虑更改SYS.ALL_SYNONYMS视图或是减少程序中的公有同义词使用。
继续咨询Oracle可否使用9I的ALL_SYNONYMS替换10G的ALL_SYNONYMS视图,得到肯定答复。Oracle说明10G的ALL_SYNONYMS视图变化的原因是修正在同义词上再建立同义词的BUB ...... 更多。。。