oracle應用產(chǎn)品性能調(diào)整實例分析(編輯修改稿)
2024-11-12 16:30 本頁面
【文章內(nèi)容簡介】 一致為 0 ? 并伴有較大的 Page out ? Runing Queue 平均為 20 – 對此 PO接收操作生成 SQL執(zhí)行計劃 : ? 發(fā)現(xiàn)對 MTL_SYSTEM_ITEMS和MTL_SECONDARY_INVENTORIES 進行全表掃描 ,其中 MSI表中有 80萬條記錄 接收事務處理等非常慢 (Cont.) ? 修改了索引 : – MTL_SYSTEM_ITEMS_U1 (anization_id,inventory_item_id) ? 檢查索引發(fā)現(xiàn)對 MSI表新建了索引 : – MTL_SYSTEM_ITEMS_N8 (anization_id, item_type,segment1) – MTL_SYSTEM_ITEMS_N9 (anization_id) ? 采取的辦法 : – alter table drop primary key。 – drop index 。 – drop index 。 接收事務處理等非常慢 (Cont.) – drop index 。 – Create index (inventory_item_id,aniziotn_id) ? 結(jié)果：系統(tǒng)恢復正常 ? 問題分析： – 不能修改標準索引 – 對標準基表添加索引要特別小心 – 建議只對客戶化表建索引，并加上 CUX_前綴和有自己獨立的表空間 (Tablespace) ONT 升級 SQL問題 ? 問題現(xiàn)象： – R11i升級過程中 運行了一天無法完成 ? 問題檢查： – 通過生成此 SQL的執(zhí)行計劃發(fā)現(xiàn) : 對 MTL_DEMAND進行全表掃描 (Full table scan ),此表有 1509351 條記錄 – 檢查 MTL_DEMAND表上有相應的索引 ? 原因分析： – R11i采用 CBO,Optimizer=choose ? 采取臨時辦法 : – 修改 ,加 Hint – alter session set optimizer_goal = rule。 ONT 升級 SQL問題 (Cont.) ? 其他類似 SQL: – – ? 問題分析： – R11i采用 CBO基于成本的優(yōu)化方法，以前都是基于規(guī)則的優(yōu)化方法 (Rule Base) – 如不作 CBO統(tǒng)計可能會引起執(zhí)行計劃的不合理，可能比 Rule Base的還差 – 建議定期作 CBO統(tǒng)計 應用系統(tǒng)整體反應慢 ? 問題現(xiàn)象： – 應用系統(tǒng)整體性能差，特別是月結(jié)期間 – 打開 Forms，運行報表，并發(fā)程序運行都慢 ? 問題檢查： – Sar,vmstat結(jié)果 CPU空閑很少 – OEM生成 TOP 50并發(fā)請求報告 ? 基于內(nèi)存的快照 (運行 1444分鐘 ) ? 在制品收發(fā)存日報表 _客戶化 (平均運行 40分鐘 ) ? 鈔票生產(chǎn)報表 _客戶化 (平均運行 30分鐘 ) ? 工序外廢統(tǒng)計報表 _客戶化 (平均運行 27分 應用系統(tǒng)整體反應慢 (Cont.) ? 用戶還反映“ 查詢事務處理匯總”很慢 – 用 OEM TOP session檢查： ? ” 并發(fā)管理 ” 程序本身消耗了較高的系統(tǒng)資源 – 生成 utlbstat/utlestat 報告： ? 39。db file scattered read39。 –等待通過對表進行 Full table scan 發(fā)生的 I/O ? 39。buffer busy wait? – 由于 undo block and header contention引起的等。 ? ‘ Average Write Queue Length? – 為 , 此統(tǒng)計值過大 ? 對 TEMP表空間有較大的讀寫操作，特別是寫操作，比一般的表空間要大 100多倍 應用系統(tǒng)整體反應慢 (Cont.) – 對上述各問題生成 SQL執(zhí)行計劃 ? 解決方案： – 調(diào)整數(shù)據(jù)庫 init參數(shù)： ? 增加 db_file_multiblock_read_count為原來的 2
教學課件相關推薦
鄂ICP備17016276號-1