Oracle應用產品性能調整實例分析ppt課件

1、運用產品性能調整實例分析 內容運用產品性能調整概要引見性能調整常用方法運用產品性能調整實例分析 運用產品性能調整概要引見準確地定義是處理問題的關鍵 “WHAT : 問題的特性是什么? 其相關的組件是什么?“WHERE: 問題在什么地方發(fā)生?“WHEN: 問題在什么時候發(fā)生?“EXTENT: 問題影響的用戶或地點是什么? 多少功能受影響? 問題能否孤立?“PRIORITY: 問題的相關重要性有多高?性能目的設立基于用戶需求的性能目的基于實踐環(huán)境所能到達的性能性能問題的相關性不同模塊/組件之間存在相互影響的關系,找到產生問題的主要緣由分清三種類型的運用問題在線事務處置后臺批量數(shù)據處置運用報表調整數(shù)

2、據庫調整效力器調整SQL(執(zhí)行方案)調整/監(jiān)控網絡調整數(shù)據庫搜集運用數(shù)據庫運轉的統(tǒng)計數(shù)據(utlB/Estat,V$patameter),調整數(shù)據庫初始化參數(shù)分析數(shù)據庫對象(Analyze The Database)利用Package Pinning 戰(zhàn)略提高緩存命中率(Hit Ratio)減少資源競爭(Resource Contention)數(shù)據塊的大小(DB Block Size)調整效力器磁盤I/O內存Paging和SwappingCPU進程調整SQL(執(zhí)行方案)發(fā)現(xiàn)耗時/資源的SQL(Expensive SQL)跟蹤(Tracing)CBO統(tǒng)計/索引/視圖/嵌套/表銜接High-Wat

3、er Mark監(jiān)控網絡網絡流量監(jiān)控工具pingARPnetstat等客戶端PC用戶數(shù)添加數(shù)據量添加上線模塊添加第三方軟件的參與客戶化報表/程序添加運用時間“Why 找到性能問題瓶頸，檢查詢題真正的緣由“How 分析緣由，找到處理問題的方法內容運用產品性能調整概要引見性能調整常用方法運用產品性能調整實例分析 性能調整常用方法用OS工具來發(fā)現(xiàn)問題,找到最費時的OS進程,并關聯(lián)到相應的ORACLE SessionVmstatIostatPsTop(nmon/topas)sar檢查能否有“死(defunct)進程和運轉時間異常長并耗費大量系統(tǒng)資源的進程經過運轉Utlbstat/utlestat 報告來

4、調整數(shù)據庫用OEM工具找出性能瓶頸確定費時的SQL語句，詳細有以下幾種方法：性能調整常用方法(Cont.)trace (生成SQL的執(zhí)行方案)：alter system set timed_statistics=true;initSID.ora: sql_trace=true;dbms_system.set_sql_trace_in_session(&sid,&serial,true);Profile Option:(AR: Enable SQL trace,INV:Debug Trace,MRP:Trace Mode,OE:Debug Trace,PO:Enable Sql Trace)定義

5、并發(fā)程序“Check trace onOEM top sessionFND_TOP/admin SQL scriptsV$sqlarea, V$sqltext性能調整常用方法(Cont.)select sid,serial# from v$session where paddr = (select addr from v$process where spid=&ospid);select spid from v$process where addr=(select paddr from v$session where sid=&orasid);select request_id,oracle_

6、process_id from apps.fnd_concurrent_requests where request_id=&request_id;select sid,s.serial#,s.username,s.status,pid,spid, gram from v$session s,v$process p where s.paddr=p.addr and spid = &spid;性能調整常用方法(Cont.)定期進展CBO統(tǒng)計，詳細有以下幾種方法：Analyze table/index compute statistics;exec fnd_stats.gather_sc

7、hema_statistics(Appl_shortname)運轉并發(fā)：“Gather Schema/Table/Column statistics運轉并發(fā)：“Analyze All Index Column Statistics“定期“Purge過時的任務流數(shù)據和并發(fā)懇求性能調整常用方法(Cont.)及時安裝上ORACLE建議的，特別是強迫性PATCHMetalink是一個非常有用的工具，遇到性能問題建議先在Metalink上查一查，大部分的問題應該都有理處理方案調整SQL語句/視圖等Log iTAR來獲得技術支持及時聯(lián)絡硬件供應商以獲得協(xié)助性能問題的差別性景象一樣，能夠構成的緣由不一樣，處

8、理的方法也不一樣用戶的實踐情況不一樣，同一緣由，其影響程度也不一樣內容運用產品性能調整概要引見性能調整常用方法運用產品性能調整實例分析 運用產品性能調整實例分析 系統(tǒng)反響慢接納事務處置等非常慢ONT 晉級(R11i) SQL問題運用系統(tǒng)整體反響慢訂單錄入/預定性能問題Planning Manager運轉不完系統(tǒng)反響慢問題景象：運用系統(tǒng)反響非常慢，就連登錄到運用系統(tǒng)就需5分鐘，翻開一FORM需3分鐘 問題檢查：用vmstat 查，有15個“Running的OS進CPU idle不斷為0用nmon/topas查，發(fā)現(xiàn)有14個運轉的RGRARG進程，大部分運轉了十幾小時，有些運轉了幾天，它們占了約9

9、5的CPU資源 對這些TOP Process 找不到相應的Oracle Session系統(tǒng)反響慢(cont.)緣由分析：取消FSG報表，OS進程還在運轉并耗費資源用戶較長時間未運轉“Gather Schema Statistics引起FSG報表性能差處理方法：Kill這些OS進程再對GL Schema運轉“Gather Schema Statistics和運轉“GL優(yōu)化程序 系統(tǒng)反響慢(cont.)結果：FSG報表運轉正常系統(tǒng)釋放了被占用的95的CPU資源，當然系統(tǒng)反響也恢復了正常 問題分析：定期作CBO統(tǒng)計非正常的OS進程會耗費很大的系統(tǒng)資源接納事務處置等非常慢問題景象：接納事務處置選擇子庫

10、存一小時無反響，以前不斷都很好(選擇時間約一秒)應收接口程并發(fā)程序非常慢采購匯總報表運轉不完問題檢查：Vmstat 2 CPU 空閑一致為0并伴有較大的Page outRuning Queue 平均為20對此PO接納操作生成SQL執(zhí)行方案:發(fā)現(xiàn)對MTL_SYSTEM_ITEMS和MTL_SECONDARY_INVENTORIES 進展全表掃描,其中MSI表中有80萬條記錄接納事務處置等非常慢(Cont.)修正了索引:MTL_SYSTEM_ITEMS_U1 (organization_id,inventory_item_id)檢查索引發(fā)現(xiàn)對MSI表新建了索引:MTL_SYSTEM_ITEMS_N

11、8 (organization_id, item_type,segment1) MTL_SYSTEM_ITEMS_N9 (organization_id) 采取的方法:alter table inv.mtl_material_items drop primary key;drop index inv.mtl_system_items_u1;drop index inv.mtl_system_items_n8;接納事務處置等非常慢(Cont.)drop index inv.mtl_system_items_n9;Create index inv.mtl_system_items_u1(inven

12、tory_item_id,organiziotn_id)結果：系統(tǒng)恢復正常問題分析：不能修正規(guī)范索引對規(guī)范基表添加索引要特別小心建議只對客戶化表建索引，并加上CUX_前綴和有本人獨立的表空間(Tablespace)ONT 晉級 SQL問題問題景象：R11i晉級過程中ontup204.sql 運轉了一天無法完成問題檢查：經過生成此SQL的執(zhí)行方案發(fā)現(xiàn): 對MTL_DEMAND進展全表掃描(Full table scan ),此表有1509351 條記錄檢查MTL_DEMAND表上有相應的索引緣由分析：R11i采用CBO,Optimizer=choose采取暫時方法:修正ontup204.sql,

13、加Hintalter session set optimizer_goal = rule;ONT 晉級 SQL問題(Cont.)其他類似 SQL:ont00031.sqlontupg43.sql問題分析：R11i采用CBO基于本錢的優(yōu)化方法，以前都是基于規(guī)那么的優(yōu)化方法(Rule Base)如不作CBO統(tǒng)計能夠會引起執(zhí)行方案的不合理，能夠比Rule Base的還差建議定期作CBO統(tǒng)計運用系統(tǒng)整體反響慢問題景象：運用系統(tǒng)整體性能差，特別是月結期間翻開Forms，運轉報表，并發(fā)程序運轉都慢問題檢查：Sar,vmstat結果CPU空閑很少OEM生成TOP 50并發(fā)懇求報告基于內存的快照(運轉1444

14、分鐘)在制品收發(fā)存日報表_客戶化(平均運轉40分鐘)鈔票消費報表_客戶化(平均運轉30分鐘)工序外廢統(tǒng)計報表_客戶化(平均運轉27分 運用系統(tǒng)整體反響慢(Cont.)用戶還反映“查詢事務處置匯總很慢用OEM TOP session檢查：并發(fā)管理程序本身耗費了較高的系統(tǒng)資源 生成utlbstat/utlestat 報告： db file scattered read 等待經過對表進展Full table scan 發(fā)生的I/Obuffer busy wait 由于undo block and headercontention引起的等。Average Write Queue Length 為13.

15、9, 此統(tǒng)計值過大對TEMP表空間有較大的讀寫操作，特別是寫操作，比普通的表空間要大100多倍運用系統(tǒng)整體反響慢(Cont.)對上述各問題生成SQL執(zhí)行方案處理方案：調整數(shù)據庫init參數(shù)：添加db_file_multiblock_read_count為原來的2倍，盡量減少由于客戶化程序而引起的Full table sacn.添加回滾段的個數(shù),如今為8個,建議添加到12個并優(yōu)化每個Segment的存儲參數(shù)添加db_block_buffer值,現(xiàn)150M, 建議添加到600M添加sort_area_size值,現(xiàn)為256000,建議添加到1.6M,為減少在TEMP表空間過多的讀寫，也要察看是那些

16、客戶化運用引起的，盡量對這些程序進展調優(yōu)運用系統(tǒng)整體反響慢(Cont.)規(guī)范運用查詢事務處置匯總：刪除表：MTL_SUMMARY_TEMP中的記錄，此表有3268051，此查詢程序有對它進展Full table scan并發(fā)管理程序：經過OEM TOP Session監(jiān)控，發(fā)現(xiàn)系統(tǒng)并發(fā)管理調度程序耗費很大的CPU資源，進一步檢查發(fā)現(xiàn)它對fnd_conc_pp_actions表進展Full Table Scan, 檢查表：fnd_conc_pp_actions有62255條記錄，并且此SQL 運轉非常頻繁：Patch#1585448消除Full Table Scan 并處理此問題運用系統(tǒng)整體反響

17、慢(Cont.)規(guī)范運用：基于內存的快照：當運轉MRP的方案參數(shù)設定為Net WIP,MRP的 基于內存的快照將永遠也運轉不完，并耗用大量的系統(tǒng)資源 經過對此情況進展模擬，發(fā)現(xiàn)0837相關組件的義務令存在循環(huán), 處理方法是封鎖0837相關的義務令再重新運轉MRP，方案3分鐘正常完成運用系統(tǒng)整體反響慢(Cont.)客戶化運用：在制品收發(fā)存日報表_客戶化：經過調整數(shù)據庫初始化參數(shù)，使此報表性能提高了3.5倍(現(xiàn)為12分鐘)，在此根底上調整視圖：cux_wip_xa_tmp的定義,改動Where 條件的順序，以減少 Rang Scan的范圍，這樣，使此報表的運轉時間縮短到2.5分鐘，并且大大減少了系

18、統(tǒng)IO鈔票消費報表_客戶化(平均運轉30分鐘)：分析此報表的TOP SQL，對表QA_RESULTS讀取9256680條記錄，運用程序是經過對QA_RESULTS_V 進展讀取的，檢查發(fā)現(xiàn)有相應的Patch#1828261對此視圖進展優(yōu)化，安裝此Patch后此TOP SQL 的執(zhí)行只選取91967條記錄，報表運轉時間縮短到10分鐘運用系統(tǒng)整體反響慢(Cont.)工序外廢統(tǒng)計報表_客戶化：此報表的TOP SQL，對表MTL_SYSTEM_ITEMS, WIP_MOVE_TRANSACTIONS進展了大量的Range Scan,經測試發(fā)現(xiàn)此SQL單獨運轉非?？?，僅需3秒檢查此SQL是一報表公式，它

19、處于內循環(huán)，對同一求和結果運轉了多次修正此報表，使運轉時間由原來27分鐘縮短到2分鐘運用系統(tǒng)整體反響慢(Cont.)結果：系統(tǒng)的整體性能提高了4到5倍Average Write Queue Length 統(tǒng)計值由13.9降低到0db file sequential read統(tǒng)計值由267991/298562/1.1 降低到2911 /3895 / 1.34db file scattered read值由3763/15123 /4.02降低到4 /9 /2.25 buffer busy wait 統(tǒng)計值由104695/94150 /.9降低到0. TEMP表空間的讀寫正常規(guī)范運用的性能問題處理，

20、客戶化運用有了十倍不等的提高運用系統(tǒng)整體反響慢(Cont.)問題分析：運用環(huán)境變化后數(shù)據庫系統(tǒng)需求根據現(xiàn)有情況進展調整用戶數(shù)模塊數(shù)數(shù)據量客戶化管理暫時數(shù)據對客戶化報表應盡量優(yōu)化，并先在測試環(huán)境下進展性能測試 數(shù)據問題也會引起性能問題(MRP問題第三方軟件的參與訂單錄入/預定性能差問題景象：輸入銷售訂單“Next field/line 很慢(需求10+ 秒,1+ 分鐘)預定訂單非常慢( 在一個用戶運用的情況下都需求5+ 分鐘)訂單錄入/預定性能差(Cont.)問題檢查：Vmstat ( 1315 run queue, CPU stuck 0 idle)經過OEM發(fā)現(xiàn)一TOP Session 引起

21、了大量的“ logical read:INSERT INTO QP_PREQ_LINE_ATTRS_TMP.經過nmon發(fā)現(xiàn)相應的TOP Process占用了 90%的CPU經過Metalink發(fā)現(xiàn)相應 Patch#1318663訂單錄入/預定性能差(Cont.)進一步檢查：Select count(*) from wf_items where end_date is not null;select count(*) from WF_ITEMS_ACTIVITY_STATUSES where end_date is not null;Select count(*) from fnd_concurrent_requests;處理方案：安裝Patch# 1318663去除過時的任務流數(shù)據運轉Gather Schema Statistics for the ALL Schema去除過多的并發(fā)懇求數(shù)據訂單錄入/預定性能差(Cont.)結果：Vmstat (12 run queue, average 50% idle last 2 hrs)OEM TOP session 正常輸入銷售訂單“Next field/line (只需求 秒, 23 秒)預定訂單(只需求310 秒)訂單錄