1、 軟件項目維護方案1. 項目背景及目標1.1. 項目背景在國家政策的指導和幫助下，信息化也越來越發揮出十分重要的作用。XXXX不斷加大信息化管理工作力度，積極實施“上網工程”，大力推進全市局域網建設，加快辦公自動化系統進程，信息技術在改革中發揮了重要的支撐作用，為充分發揮政府公共職能，促進依法理財、科學理財，提供了重要的信息技術保障。近年來建設各系統隨著數據量的逐年增加，陸續出現了性能問題，有必要進行數據庫系統的升級及性能優化，以確保應用系統的正常運行，為單位員工提供更好的信息服務。1.2. 項目目標 對各系統數據庫進行補丁升級服務，安裝補丁前制定詳細的升級計劃和應急回退計劃。 完成各系統數據

2、庫的性能調優工作。 各業務持續性得到有效的保證。2. 需求分析XXXXXXX項目，我公司有多年的行業經驗。具有對運維服務對象進行適時監測、指標分析、和及時修復的能力。Oracle 產品日常運行維護項目主要從如下幾個方面進行：(1). 每天對ORACLE數據庫的運行狀態,日志文件,備份情況,數據庫的空間使用情況,系統資源的使用情況進行查看,發現并解決問題。(2). 每周對數據庫對象的空間擴展情況,數據的增長情況進行監控,對數據庫做健康查看,對數據庫對象的狀態做查看。(3). 查看表空間碎片,提出下一步空間管理計劃。對ORACLE數據庫狀態進行一次全面查看。（4）由于這些數據庫系統承載著XXXX非

3、常重要的業務系統數據，所以在日常維護中需要非常仔細，每周、每月、每季都需要有相應的巡檢記錄，需要詳細記載以下一些內容：n 監控數據庫對象的空間擴展情況n 監控數據量的增長情況n 系統健康查看，查看以下內容:n 數據庫對象有效性查看n 查看是否有危害到安全策略的問題。n 查看 alert、Sqlnet 等日志并歸檔報錯日志n 分析表和索引n 查看對數據庫會產生危害的增長速度n 查看表空間碎片n 數據庫性能調整n 預測數據庫將來的性能n 調整和維護工作n 后續空間3. 整體運行維護服務方案3.1. Lifekeeper維護3.1.1. 驗證 LifeKeeper 的安裝查看已經安裝的LifeKee

4、per軟件包，可以使用命令：rpm qa|grep stee3.1.2. 啟動 LifeKeepera)啟動LifeKeeper 服務器進程如果當前您的系統沒有運行 LifeKeeper 則在所有服務器上以root用戶身份輸入如下命令# /opt/LifeKeeper/bin/lkstartb)啟動LifeKeeper GUI服務器進程同樣以root用戶運行命令# /opt/LifeKeeper/bin/lkGUIserver start 注意：以上命令只需運行一次，以后每次系統重新啟動時，LifeKeeper會自動運行上述進程3.1.3. 有關的LifeKeeper軟件的其它管理任務a)停止

5、 LifeKeeper 服務如果需要在服務器上永久停止LifeKeeper服務，可以輸入下列命令$LKROOT/bin/lkstop該命令同時會使所有LifeKeeper保護的資源處于退出服務狀態，如果希望在停止LifeKeeper時保持資源/應用的運行，可以使用：$LKROOT/bin/lkstop -fb)查看 LifeKeeper 進程鍵入下列命令可以查看當前運行的所有 LifeKeeper 進程列表ps -ef | grep LifeKeeper3.1.4. 啟動LifeKeeperGUI配置工具進入LifeKeeper GUI管理工具可以通過運行命令：/opt/LifeKeeper/

6、bin/lkGUIapp則出現LifeKeeper登錄界面：可以使用root用戶登錄，也可以使用新建的用戶進行登錄。3.1.5. 檢測LifeKeeper 集群運行狀態可以使用lcdstatus命令對LifeKeeper 集群的當前運行狀態進行查看，命令格式：lcdstatus -q -d 該程序向 stdout 輸出在LifeKeeper 資源層次配置狀態和通信路徑的狀態.選項 -q 表示輸出采用簡略的形式（建議使用該選項）選項d 表示要查看的主機，缺X查看本機3.1.6. 管理 LifeKeeper 中的資源注意：如果能運行LifeKeeper GUI，則使用其提供菜單命令執行相應操作；在

7、執行命令行啟動/停止資源前，一定先使用lcdstatus命令確認資源的實際狀態。a)啟用資源(In-Service)可以使用命令：./perform_action -t -a restore將資源標記名所對應的資源在本機上投入服務（啟動）。如果該資源在命令使用前已經在另一臺機器上處于運行狀態，則本命令執行的結果相當于執行了一次手工切換！如果該資源在命令使用前是處于停止狀態（即在備機上執行本命令），則本命令執行的結果相當于執行了一次手工切換b)停止資源(out-of-service)可以使用命令：./perform_action -t -a remove將資源標記名所對應的資源在本機上停止服務。

8、如果該資源在命令使用前已經在另一臺機器上處于運行狀態，則本命令執行不產生任何結果注意：n 在執行命令行前后，一定先使用lcdstatus命令確認資源的當前狀態。n 命令停止/啟動本地的資源n 命令中的是區分大小寫的n 一定要等待命令完成，注意命令的輸出。n 詳細用法見在線幫助手冊。3.2. SQL SERVER維護計算機系統各種軟、硬件故障、用戶誤操作以及惡意破壞是不可避免的,這些影響到數據的正確性甚至造成數據損失、服務器崩潰等致命后果。數據庫的備份對保證系統的可靠性具有重要的作用。下面會根據執行強度對維護任務及其相應的程序進行分類描述，執行強度用不同的時間間隔定義，包括每天、每周、每月和每季

9、度，能夠建立起良好的維護實務，確保SQL Server數據庫性能和安全。3.2.1. 每天的例行維護任務需要數據庫管理員密切關注的維護任務，最好每天都查看一下，這樣可以確保系統的可靠性、可用性、運行性能和安全。每天的例行維護任務包括：1、查看是不是所有被請求的SQL Server服務都正常運行。2、查看日常備份日志中成功、警告或者失敗記錄。3、查看Windows事件日志有沒有錯誤記錄。4、查看SQL Server日志有沒有安全警告記錄，例如非法登錄。5、執行完全備份或差異備份。6、在設置了完全恢復模型或大容量日恢復模型的數據庫上執行事務日志備份任務。7、核實SQL Server作業沒有失敗。8

10、、查看所有的數據庫文件和事務日志具有合適的磁盤空間大小。9、至少要監控處理器、內存或者磁盤計數器沒有出現瓶頸。3.2.2. 每周的例行維護任務關注程度稍遜于每天的例行維護任務，最好每周進行一次例行查看。每周的例行維護任務包括：1、執行完全備份或差異備份。2、查看以前執行的維護計劃報告。3、查看數據庫完整性。4、如果需要，執行收縮數據庫任務。5、通過重新組織索引任務壓縮聚集和非聚集表和視圖。6、通過重新生成索引任務在數據頁和索引頁重新組織數據。7、更新所有用戶表和系統表的統計信息8、清除備份、還原、SQL Server代理作業和維護計劃等操作的歷史數據。9、如果需要，手動增長數據庫或事務日志文件

11、10、清除執行維護計劃殘留下來的文件。3.2.3. 每月或每季度的維護任務有一些維護計劃不需要執行得過于頻繁，可以每個月或每個季度執行一次。但是請不要以為這些任務不需要天天執行就無足輕重，這些任務可以確保數據庫環境的健康，所以不要輕視以下這些維護任務：1、在測試環境中執行備份還原操作。2、將歷史數據歸檔。3、分析收集的性能統計數據，與基準值相比較。3、查看并更新維護文檔。4、查看并安裝最新的SQL Server補丁和補丁包。5、如果運行簇、數據庫鏡像或日志傳送，則監測故障轉移。6、驗證備份和還原進程是否遵循已定義的服務等級協議。7、更新SQL Server構建指南。8、更新SQL Server

12、災難恢復文檔。9、更新維護計劃列表10、修改管理員口令。11、修改SQL Server服務帳戶口令。3.3. WebLogic維護3.3.1. 性能調優. 設定執行隊列的溢出條件Weblogic Server提供給默認的執行隊列或用戶自定義的執行隊列自定義溢出條件的功能，當滿足此溢出條件時，服務器改變其狀態為“警告”狀態，并且額外的再分配一些線程去處理在隊列中的請求，而達到降低隊列長度的目的。通過啟動管理控制臺，在域（如：mydomain） 服務器 server實例（如：myserver） Execute Queue weblogic.kernel.Defalt 配置下面幾項：隊

13、列長度：此值表示執行隊列中可容納的最大請求數，默認值是65536，最后不要手動改變此值。隊列長度閾值百分比：此值表示溢出條件，在此服務器指出隊列溢出之前可以達到的隊列長度大小的百分比。線程數增加：當檢測到溢出條件時，將增加到執行隊列中的線程數量。如果CPU和內存不是足夠的高，盡量不要改變默認值“0”。因為Weblogic一旦增加后不會自動縮減，雖然最終可能確實起到了降低請求的作用，但在將來的運行中將影響程序的性能。最大線程數：為了防止創建過多的線程數量，可以通過設定最大的線程數進行控制。在實際的應用場景中，應根據具體情況適當的調整以上參數。. 設定隊列監測行為Weblogic S

14、erver能夠自動監測到當一個執行線程變為“阻塞”。變為“阻塞”狀態的執行線程將無法完成當前的工作，也無法再執行新請求。如果執行隊列中的所有執行線程都變為“阻塞”狀態，Weblogic server可能改變狀態為“警告”或“嚴重”狀態。如果Weblogic server變為“嚴重”狀態，可以通過Node Manager來自動關閉此服務器并重新啟動它。具體請參考：Node Manager Capabilities文檔。通過啟動管理控制臺，在域（如：mydomain） 服務器 server實例（如：myserver）配置 調整下可配置下面幾項：阻塞線程最長時間：在此服務器將線程診斷為阻塞線程之前，

15、線程必須連續工作的時間長度(秒)。默認情況下，WebLogic Server 認為線程在連續工作600 秒后成為阻塞線程。阻塞線程計時器間隔：WebLogic Server 定期掃描線程以查看它們是否已經連續工作了阻塞線程最長時間 字段中指定的時間長度的間隔時間(秒)。默認情況下，WebLogic Server 將此時間間隔設置為600 秒。.1. 盡量使用本地IO庫WebLogic Server有兩套套接字復用器：Java版和本地庫。采用小型本地庫更有效,盡量激活Enable Native IO(默認),此時UNIX默認使用CPUs+1個線程,Window下為雙倍CPU。如果系

16、統不能加載本地庫,將會拋出java.lang.UnsatisfiedLinkException,此時只能使用Java套接字復用器,可以調整socket readers 百分比,默認為33%。該參數可以在Console Server Tuning Configuration配置欄里設置，配置完，重新啟動WebLogic Server即可。.2. 調整默認執行線程數名稱開發模式產品模式推薦個數Execute Queues 默認的執行線程為15默認的執行線程為25200在管理控制臺修改默認執行隊列線程數的步驟如下：n 如果管理服務器沒有運行，先啟動。n 訪問管理控制臺。n 展開左邊面板

17、的Servers 節點，顯示Server列表。n 右擊Server，在彈出菜單中選擇View Execute Queues ，就會在右邊面板顯示有執行隊列的表用來修改。n 注意：你只能修改默認的執行隊列或者用戶定義的執行隊列。n 在Name列，直接點擊默認執行隊列名稱，顯示配置標簽用來修改執行隊列數。n 填下適當的線程數。n 點擊Apply，保存剛才的修改。n 重啟Server，使新的執行隊列設置生效。. JDBC調優.1. 驅動程序類型選擇Oracle提供thin驅動和oci驅動,從性能上來講,oci驅動強于thin驅動,特別是大數據量的操作。但在簡單的數據庫操作

18、中,性能相差不大,隨著thin驅動的不斷改進,這一弱勢將得到彌補。而thin驅動的移植性明顯強于oci驅動。所以在通常情況下建議使用thin驅動.2. 調節連接池初始容量和最大容量JDBC Connection Pool的調優受制于WebLogic Server線程數的設置和數據庫進程數,游標的大小。通常我們在一個線程中使用一個連接,所以連接數并不是越多越好,為避免兩邊的資源消耗，建議設置連接池的最大值等于或者略小于線程數。同時為了減少新建連接的開銷,將最小值和最大值設為一致；值等于WebLogic Server的執行線程數。.3. 其他配置盡管JDBC Conne

19、ction Pool提供了很多高級參數,在開發模式下比較有用,但大部分在生產環境下不需調整。這里建議最好不要設置測試表, 同時Test Reserved Connections和Test Released Connections也無需勾上。當然如果你的數據庫不穩定,時斷時續,你就可能需要上述的參數打開. WEB調優.1. 調整WEB應用描述符WEB應用除代碼之外的調優比較簡單,僅僅是對一些WEB應用描述符的調整。首先關閉Session Monitoring Enabled,僅僅在Cluster環境下設置Session復制(優先使用內存復制),在保證應用正常運行的情況

20、下,設置較短的Session超時時間。同時生產環境下無需查看Jsp和servlet：JSPPage Check Secs和Servlet Reload Check Secs均設為-1,關閉JSP Keep Generated 和JSP Verbose對性能也有幫助。此外，還可以對jsp進行預編譯,有兩種方法：激活precompile選項；使用weblogic.appc事先編譯，建議采用后者。. 其他調優設置.1. WebLogic文件描述符大小調整首先設置WEB主機系統的ulimit參數為unlimited ，然后設置WebLogic中文件描述符的大小。在WL_HO

21、ME/bea/weblogic/common/bin中打開文件commEnv.sh，修改設置文件描述符大小的指令，將默認的：ulimit n 1024修改為：ulimit n 81923.3.2. 維護管理. 啟動weblogic servern 啟動管理服務器：執行startAdmserver.shn 啟動被管理服務器：執行startManagedWebLogic.sh servername adminurl. 停止weblogic servern 停止被管理服務器：執行stopWebLogic.sh servernamen 啟動被管理服務器：執行stopWebL

22、ogic.sh. 登錄和退出管理控制臺n 管理服務器啟動后可以在瀏覽器中登錄管理控制臺n 輸入URL：http:/hostname:port/console或https:/hostname:port/consolel hostname：管理服務器的ip地址或DNS名l port：管理服務器監聽的端口l 如果管理服務器啟動時使用SSL，則使用https訪問管理控制臺n 在彈出的窗口“Console Login“中輸入用戶名和密碼登錄. 性能監控n 查看性能參數l 登錄控制臺后點擊Servers-servername-Monitoring-Performancen 參數

23、分析n1)Idle Threads & Queue Length & Throughout正常情況下 idle threads 0 ，queue Length為0，Throughout呈不規則變化曲線，Memory Usage呈適度頻度的鋸齒變化曲線。一般來說，對于正常配置的生產環境（線程數50200），如果idle threads 0 ，則 queue length =0 ； B、反之，如果queue length0 ，則空閑線程數=0 ；n2)Memory Usage Memory Usage = totalMemory() freeMemory()內存使用曲線反應了JVM Heap內存使

24、用的變化情況，可以結合其他三個值的變化情況來判斷server工作情況；比較理想的狀態是適當頻度的各種鋸齒變化，由于JVM GC多采用“stop the world”機制，也就是垃圾回收時其他處理將暫停，過度頻繁的GC將明顯降低server工作效率和性能表現。3.4. Oracle維護Oracle Database，又名Oracle RDBMS，或簡稱Oracle。是甲骨文公司的一款關系數據庫管理系統。它是在數據庫領域一直處于領先地位的產品。可以說Oracle數據庫系統是目前世界上流行的關系數據庫管理系統，系統可移植性好、使用方便、功能強，適用于各類大、中、小、微機環境。它是一種高效率、可靠性好

25、的 適應高吞吐量的數據庫解決方案。3.4.1. 數據庫性能優化Oracle 性能管理既是一種藝術，也是一種科學。從實用角度講，它可以分為兩種類型，主動式和被動式性能管理。主動式性能管理涉及到特定系統實施初期的設計和開發，包括硬件選擇、性能及容量規劃，海量存儲系統的選擇， I-O子系統配置及優化，以及如何對不同組件進行定制，以滿足 Oracle 數據庫和應用系統的復雜要求。被動式性能管理涉及到現有環境中不同組件的性能評估、故障排除和 Oracle環境的優化。本文旨在探討如何進行被動式性能調優，以便為 Oracle 性能調優提供必要的指導，從而避免僅僅通過反復嘗試的方式進行性能調優，提高 Orac

26、le性能管理的效率。所以 ORACLE 數據庫性能惡化表現基本上都是用戶響應時間比較長，須要用戶長時間的等待。獲得滿意的用戶響應時間有兩個途徑：一是減少系統服務時間，即提高數據庫的吞吐量；二是減少用戶等待時間，即減少用戶訪問同一數據庫資源的沖突率。對于以上的兩個問題，通常我們采用以下幾個方面來進行改善：n 調整服務器內存分配。例如，可以根據數據庫運行狀況調整數據庫系統全局區（SGA 區）的數據緩沖區、日志緩沖區和共享池的大小；還可以調整程序全局區（PGA 區）的大小。n 調整硬盤 I/O 問題，達到 I/O 負載均衡。n 調整運用程序結構設計。n 優化調整操作系統參數和使用資源管理器。n SQ

27、L 優化、診斷 latch 競爭、Rollback(undo) Segment 優化、提升 block的效率等等。. 查看Oracle數據庫性能查看 Oracle 數據庫性能情況，包含：查看數據庫的等待事件，查看死鎖及處理，查看 cpu、I/O、內存性能，查看是否有僵死進程，查看行鏈接/遷移，定期做統計分析，查看緩沖區命中率，查看共享池命中率，查看排序區，查看日志ORACLE 產品日常運行維護年度服務項目緩沖區，總共十個部分。.1. 查看數據庫的等待事件set pages 80set lines 120col event for a40select sid,even

28、t,p1,p2,p3,WAIT_TIME,SECONDS_IN_WAIT from v$session_wait where event notlike SQL% and event not like rdbms%;如果數據庫長時間持續出現大量像latch free，enqueue，buffer busy waits，db file sequential read，db file scattered read 等等待事件時，需要對其進行分析，可能存在問題的語句。.2. 查看消耗CPU最高的進程SET LINE 240SET VERIFY OFFCOLUMN SID FORMAT

29、999COLUMN PID FORMAT 999COLUMN S_# FORMAT 999COLUMN USERNAME FORMAT A9 HEADING ORA USERCOLUMN PROGRAM FORMAT A29COLUMN SQL FORMAT A60COLUMN OSNAME FORMAT A9 HEADING OS USERSELECT P.PID PID,S.SID SID,P.SPID SPID,S.USERNAME USERNAME,S.OSUSER OSNAME,P.SERIAL#S_#,P.TERMINAL,P.PROGRAM PROGRAM,P.BACKGROUN

30、D,S.STATUS,RTRIM(SUBSTR(A.SQL_TEXT, 1,80) SQLFROM V$PROCESS P, V$SESSION S,V$SQLAREA A WHERE P.ADDR = S.PADDR ANDS.SQL_ADDRESS = A.ADDRESS (+) AND P.SPID LIKE %&1%;.3. 查看碎片程度高的表SQL SELECT segment_name table_name,COUNT(*) extents FROM dba_segments WHERE ownerNOT IN (SYS, SYSTEM) GROUP BY segme

31、nt_name HAVING COUNT(*)=(SELECT MAX(COUNT(*)FROM dba_segments GROUP BY segment_name);.4. 查看表空間的 I/O比例SQLSELECT DF.TABLESPACE_NAME NAME,DF.FILE_NAME FILE,F.PHYRDS PYR, F.PHYBLKRDPBR,F.PHYWRTS PYW, F.PHYBLKWRT PBW FROM V$FILESTAT F, DBA_DATA_FILES DF WHEREF.FILE# = DF.FILE_ID ORDER BY DF.TABLES

32、PACE_NAME;.5. 查看文件系統的 I/O比例SQLSELECTSUBSTR(A.FILE#,1,2)#,SUBSTR(A.NAME,1,30)NAME,A.STATUS,A.BYTES,B.PHYRDS,B.PHYWRTS FROM V$DATAFILE A, V$FILESTAT B WHERE A.FILE# =B.FILE#;.6. Disk Read最高的SQL語句的獲取SQLSELECT SQL_TEXT FROM (SELECT * FROM V$SQLAREA ORDER BY DISK_READS)WHERE ROWNUM=5 desc;3

33、.. 查找前十條性能差的sqlSELECT * FROM (SELECT PARSING_USER_IDEXECUTIONS,SORTS,COMMAND_TYPE,DISK_READS,SQL_TEXT FROM V$SQLAREA ORDER BY DISK_READS DESC)WHERE ROWNUM10 ;.8. 等待時間最多的 5 個系統等待事件的獲取SELECT * FROM (SELECT * FROM V$SYSTEM_EVENT WHERE EVENT NOT LIKE SQL% ORDER BYTOTAL_WAITS DESC) WHERE RO

34、WNUM=5;.9. 查看運行很久的SQLCOLUMN USERNAME FORMAT A12COLUMN OPNAME FORMAT A16COLUMN PROGRESS FORMAT A8SELECT USERNAME,SID,OPNAME,ROUND(SOFAR*100 / TOTALWORK,0) | % ASPROGRESS,TIME_REMAINING,SQL_TEXT FROM V$SESSION_LONGOPS , V$SQL WHERETIME_REMAINING 0 AND SQL_ADDRESS=ADDRESS AND SQL_HASH_VALUE = HA

35、SH_VALUE;.10. 查看死鎖及處理查詢目前鎖對象信息：col sid for 999999col username for a10col schemaname for a10col osuser for a16col machine for a16col terminal for a20col owner for a10col object_name for a30col object_type for a10select sid,serial#,username,SCHEMANAME,osuser,MACHINE,terminal,PROGRAM,owner,objec

36、t_name,object_type,o.object_idfrom dba_objects o,v$locked_object l,v$session swhere o.object_id=l.object_id and s.sid=l.session_id;oracle 級 kill 掉該 session：alter system kill session &sid,&serial#;操作系統級 kill 掉 session：#kill -9 pid.11. 查看數據庫cpu、I/O、內存性能記錄數據庫的 cpu 使用、IO、內存等使用情況，使用 vmstat,iostat,

37、sar,top等命令進行信息收集并查看這些信息，判斷資源使用情況。n CPU 使用情況：rootsale8 # toptop - 10:29:35 up 73 days, 19:54, 1 user, load average: 0.37, 0.38, 0.29Tasks: 353 total, 2 running, 351 sleeping, 0 stopped, 0 zombie Cpu(s): 1.2% us, 0.1% sy, 0.0% ni, 98.8% id,0.0% wa, 0.0% hi, 0.0% si Mem: 16404472k total, 12887428k used

38、, 3517044k free, 60796k buffersSwap: 8385920k total, 665576k used, 7720344k free, 10358384k cached PID USER30495 oracle32501 oracle32503 oracle注意上面的加粗字體部分，此部分內容表示系統剩余的 cpu，當其平均值下降至 10%以下的時視為 CPU 使用率異常，需記錄下該數值，并將狀態記為異常n 內存使用情況：# free -m TotalusedfreesharedbufferscachedMem:20261958670761556-/+ buffers

39、/cache: 326 1700Swap: 5992 92 5900如上所示，total表示系統總內存，used表示系統使用的內存，free表示系統剩余內存，當剩余內存低于總內存的 10%時視為異常。n 系統負載情況：#uptime 12:08:37 up 162 days, 23:33, 15 users,load average: 0.01, 0.15, 0.10如上所示，load average部分表示系統負載，后面的 3 個數值如果有高于 2.5 的時候就表明系統在超負荷運轉了，并將此值記錄到巡檢表，視為異常。.12. 查看是否有僵死進程select spid from

40、v$process where addr not in (select paddr from v$session);有些僵尸進程有阻塞其他業務的正常運行，定期殺掉僵尸進程。.13. 查看行鏈接/遷移Sqlselect table_name,num_rows,chain_cnt From dba_tables Where owner=CTAIS2 Andchain_cnt0;注：含有 long raw 列的表有行鏈接是正常的 ,找到遷移行保存到chained_rows 表中 , 如沒有該表執行 ./rdbms/admin/utlchain.sqlSqlanalyze table t

41、ablename list chained rows;可通過表 chained_rows 中table_name,head_rowid看出哪些行是遷移行如:Sqlcreate table aa as selecta.* from sb_zsxx a,chained_rows b where a.rowid=b.head_rowid andb.table_name =SB_ZSXX; sqldelete from sb_zsxx where rowid in (selecthead_rowid from chained_rows where table_name = SB_ZSXX); sqli

42、nsertinto sb_zsxx select * from chained_row where table_name = SB_ZSXX;.14. 定期做統計分析對于采用 Oracle Cost-Based-Optimizer 的系統，需要定期對數據對象的統計信息進行采集更新，使優化器可以根據準備的信息作出正確的 explain plan。在以下情況更需要進行統計信息的更新：應用發生變化；大規模數據遷移、歷史數據遷出、其他數據的導入等；數據量發生變化。查看表或索引的統計信息是否需更新，如：SqlSelect table_name,num_rows,last_analyzed

43、From user_tables wheretable_name =DJ_NSRXXsqlselect count(*) from DJ_NSRXX 如 num_rows 和 count(*)如果行數相差很多,則該表需要更新統計信息，建議一周做一次統計信息收集，如：Sqlexec sys.dbms_stats.gather_schema_stats(ownname=CTAIS2,cascade=TRUE,degree = 4);.15. 查看日志緩沖區SQL select name,value from v$sysstat where name in (redo entries,

44、redo buffer allocationretries);如果 redo buffer allocation retries/redo entries 超過 1% ，則需要增大 log_buffer。. 性能調優及方法性能調優主要有主動調優和被動調優，主動調優在前面我們已經進行了闡述，被動調優主要有以下方法進行。n 確定合理的性能優化目標n 測試并記錄當前的性能指標n 確定當前存在的 Oracle 性能瓶頸 (Oracle 中何處存在等待，哪個 SQL語句與此有關)n 確定當前的操作系統瓶頸n 優化相關的組件 (應用、數據庫、I/O、連接 OS 及其它)n 跟蹤并實施變化管理

45、制度n 測試并記錄目前的性能指標n 重復第 3 到第 7 步直至達到既定的優化目標不要對并非性能瓶頸的部分進行優化，否則可能引起額外的問題。正如任何聰明的人會告訴你的：“如果還未壞，千萬不要修”。更重要的是，一旦既定的優化目標已經達到，就務必停止所有的優化。獲取 Oracle 的性能指標 (測試前及測試后)必須在峰值處理時測試并獲取系統在優化前和優化后的性能指標。數據采集不應在數據庫 instance 剛剛起動后進行。同時，測試數據應在峰值期間每過 15 分鐘進行一次。初始化參數TIMED_STATISTICS 應該被設為 TRUE。通過運行以下腳本開始快照：$ORACLE_HOME/rdbm

46、s/admin/utlbstat.sql.通過運行以下腳本結束快照：$ORACLE_HOME/rdbms/admin/utlestat.sql.完成 utlestat.sql 操作后，會在當前目錄中生成名為“report.txt”的文件，包含系統的性能數據。該報告包括每 15 分鐘捕獲的所有與 Oracle 例程相關的參數。.1. 尋找問題根源如上所述，通過查看 v$system_event 事件開始系統事件的問題診斷。下一步是查看 v$session_event，找出引起或經歷等待事件的進程。最后一步是通過v$session_wait 獲得事件的細節。同時，應該進一步通過 OS

47、 進行深入分析，了解核心的 CPU、內存和 IO 狀態參數。最后，結合兩種不同的診斷的結論，找出系統瓶頸所在。.2. 應用優化從統計(和現實) 的角度看，80% 的 Oracle 系統性能問題可以通過 SQL 代碼優化來解決。任何應用優化的過程，不外乎是索引優化、全表掃描、并行機制改進和選擇正確數據組合方法的過程。這正是要達到最佳應用性能所必須考慮的因素。沒有 SQL 的優化，就無法實現高性能的應用。良好的 SQL 語句可以減少 CPU資源的消耗，提高響應速度。同時，優化后的 SQL 語句還可以提高應用的可擴展性，這是除增加大量內存外，任何其它硬件手段也無法實現的。

48、.2.1. I-O 優化I-O 優化是系統優化中的一個關鍵步驟，還涉及到其它任務，將文件在不同驅動器/卷中進行分布，采用優化分區技術、確定 I-O 子系統瓶頸、確定控制器瓶頸并根據應用的類型選擇最佳的 RAID 級。I-O 優化應該在全面了解 Oracle 及Oracle RDBMS 結構之后進行。應該在進行 I-O 優化前后實施 I-O 數據監控，如平均服務時間，IOPS，平均磁盤隊列長度等。.2.2. O-S監控數據庫忙時，應該對操作系統進行監控，因為操作系統的性能指標會揭示數據庫活動的性質及其對系統的影響。例如，為了了解 CPU 的利用率，可以通過system activi

49、ty reporter (sar u interval frequency) 、 mpstat (SunSolaris), top (多數 UNIX)、 osview (SGI Irix) 及 vmstat 等命令。Sar 和vmstat 也可被用于確定包括內存使用率、I-O 參數、隊列等待、讀取/交換區活動等信息。在 Solaris 上，mpstat utility 也可用于獲取前面提到的 CPU 利用率數據。Solaris 上的 Adrian 性能管理工具也很有用。可以利用其中的一到多個工具來確定系統的性能狀況，找出可能存在的瓶頸。Oracle 數據庫性能的管理需要遵循系統的方法論，以確保

50、所有核心問題得以解決。多數問題可以事先得以管理。了解與 O-S 相關的問題是成功的關鍵。勿需置疑，系統硬件配置上的良好平衡也是至關重要的。必須承認， 80% 的系統性能問題可以通過書寫更好的 SQL 語句來解決。來文試圖探究其余 20%中可能覆蓋的內容。同時，必須遵守嚴格的規定，在調優目標達到后終止所有努力。了解自己想到何處是重要的，更重要的是，要知道自己何時到達了目的地。.2.3. 例程調優n 需要配置的主要初始化參數以下是一些已知與例程優化關系最密切的一些核心 Oracle 初始化參數。它們都會影響 Oracle 及 SGA 區的活動。任何對這些參數的改動，在實施到生產環境之

51、前，都必須進行測試。一旦改變了生產環境的參數，就必須對相關的 Oracle動態性能指標和操作系統的性能進行監測，尋找可能由此產生的異常現象。1) DB_BLOCK_SIZE該參數在數據庫建立前設定，決定了數據庫中每個數據塊的大小。只有重新建立數據庫，才有可能改變該參數。db_block_size 的配置應遵循以下公式：DB_BLOCK_SIZE = FILESYSTEM BLOCKSIZE = O-S PAGESIZE 這可以確保 Oracle獲得最佳 I/O 性能，同時不會由于冗余或不必要的 I/O，給 I/O 子系統帶來壓力。2) DB_BLOCK_BUFFERS該參數決定了 SGA 區數

52、據庫緩沖區中的塊數量。由于這是 Oracle 讀取和寫入的區域，它的不正確配置會引起嚴重的 I/O 性能問題。盡管緩沖區的大小與應用性質、數據庫大小、同步用戶數等無關，它的確是 SGA 區中最大的組件。經常可以看到緩沖區占用 75-80%SGA 區內存的情況。另外，這一參數設置過大，也會引起整個系統的內存不足，引起操作系統過多的讀寫操作。該參數及 SHARED_POOL_SIZE 通常是兩個最重要的 SGA 優化目標。只有當數據庫緩沖率長時間低于 70%時，才需要增加其大小說。即使在這種情況下，也需要進一步審查應用的性能和整個系統的吞吐性。若存在延遲性的應用設計問題，則無論數據庫緩沖區的大小如

53、何，緩沖和讀寫率都不會有太大改變為。在實調優中，也曾發現由于 SQL 語句的問題，出現緩沖率很高，但仍存在全系統性能問題的情況。3)SHARED_POOL_SIZE該參數按字節數設定，定義了 SGA 中共享區的大小。該組件的大小嚴重依賴于應用的類型 (即該應用是重用 SQL，還是生成動態 SQL，等等)。同時它也取決于同步用戶的數量，以及實例是否被配置成支持多線程服務器(MTS)。如果該應用采用了 MTS 配置，則共享區應該明顯增加，因為光標狀態和用戶進程數據等程序全局區域(PGA)都被置入了共享區。有關多數應用的 SHARED_POOL_SIZE 大小設置，可以從每 10 個同步用戶 16

54、MB共享區開始。這不是一成不變的，因為應用的性質最終會決定該組件的大小。只有當庫緩沖和字典緩沖使用率一直低于 90%時，才需要關注這一參數。但如果應用并未采用變量合并和/共離圖標時，內存的數量并不會使緩沖使用率高于 90%。共享區過大會導致處理時間增加，甚至 SQL 語句的掛起。如果應用不能有效地重用 SQL，則無論配置多大的庫緩沖或字典緩沖都無濟于事，不能改善緩沖使用率。另一個值得考慮的因素是需要隨時使用的存儲 PL/SQL 代碼數量。應用的核心包可以通過查看 DBA_SOURCE、USER_SOURCE 得以確認，其大小通過查詢DBA_OBJECT_SIZE 了解。另外，為了確定存儲 PL

55、/SQL 是否被置于內存，可以查詢動態性能視圖 V$DB_OBJECT_SIZE。內時，包 DBMS_SHARED_POOL 中的程序大小可被用于確定應用中大包的規模。4) LOG_BUFFER根據字節設定，該參數定義了 SGA 緩沖區中 redo log 的大小。缺X值通常是數據庫塊大小的四倍，這對于多數環境并不是最佳的。對于中型的 Oracle 環境，其結構應該為 512 Kb 左右。對該存儲結構而言，更大并不意味著更好。超過 1 MB 就可能有問題。需要監控 V$SESSION_WAIT 中 log buffer space 的等待事件，優化該內存結構。需要提醒的是，在線 redo lo

56、g 文件的大小設置不當，會引起 redo 請求的等待。5) DB_WRITERS該參數可以針對所有文件系統支持，且不可使用 Direct I-O 的 Oracle 實施設定。這并不需要與 raw partitions 一起使用，因為異步 I-O 更加。建議將該參數設定為(2 * 獨立磁盤驅動器數量/卷)。該參數只有在 report.txt 中的“average write queue length”持續高于 1 時，才需要設定。在 Oracle 8.0 和更高版本中，該參數已不再被支持，而為其它兩個名為 DB_WRITER_PROCESSES 和DBWR_IO_SLAVES 的參數取代。若需要設置 DB_WRITER_PROCESSES 值高于 8，則DB_WRITER_PROCESSES 可被設為 1，且 DBWR_IO_SLAVES 可被設為“n”，其中 n的值必須設置為 (2 * 獨立磁盤驅動器數量/卷).2.4. 競爭優化多數與 Oracle 有關的競爭問題可以通過主動配置管理相關的初始化參數進行。不恰當地配置 init.ora 中的