oracle 性能優化 04_報告及日誌解讀

1、Alert日誌解讀
    告警日誌文件是一類特殊的跟蹤文件（trace file）。告警日誌文件命名通常爲
alert_<SID>.log，其中SID爲ORACLE數據庫實例名稱。數據庫告警日誌是按時間順序記錄message
和錯誤信息。
一、查找alert日誌目錄
    show parameter dump; #即bdump目錄10G
    select * from v$diag_info; 11G，增長了文本和XML格式的日誌
二、告警日誌結構及內容解讀
    全部的內部錯誤（ORA-600）信息，塊損壞錯誤（ORA-1578）信息，以及死鎖錯誤（ORA-60）信息等。 
    管理操做，如CREATE、ALTER、DROP語句等，以及數據庫啓動、關閉以及日誌歸檔的一些信息。 
        物理結構操做：例如建立、刪除、重命名數據文件與聯機重作日誌文件的ALTER DATABASE命令，
        從新分配數據文件大小以及將數據文件聯機與脫機的操做。 
        表空間操做，如DROP與CREATE命令，還包括進行用戶管理的備份而將表空間置入和取出熱備
        份模式的操做 
    與共享服務器或調度進程相關功能的消息和錯誤信息。 
    物化視圖的自動刷新過程當中出現的錯誤。 
    動態參數的修改信息。
三、監控告警日誌的方案
a、經過外部表查看告警日誌文件的內容。使用定製SQL語句來查詢錯誤信息。
    create or replace directory  bdump as '/u01/app/oracle/admin/ipemsdb/bdump';
    create table alert_logs(
           text  varchar2(2000))
           organization external(
              type oracle_loader
              default directory bdump
           access parameters(
             records delimited by newline
             fields
             reject rows with all null fields)
           location(
               'alert_ipemsdb.log')
           )
           reject limit unlimited;
    select * from alert_logs where text like '%ORA-%'
四、告警日誌歸檔
    告警日誌若是不及時歸檔，時間長了，告警日誌文件會變得很是大，查看、讀取告警日誌會引發額
外的IO開銷。通常應該按天歸檔告警日誌文件，保留一段時間（例如 90天），超過規定時間的刪除。
參考資料：
http://www.cnblogs.com/kerrycode/p/3899558.html
http://www.cnblogs.com/kerrycode/p/3168662.html

2、statspack報告解讀：
    StatsPack:oracle自帶的性能分析工具，運行oracle自帶腳本，生成一系列的統計表，生成
快照，經過快照採樣生成報告。
安裝StatsPack報告
設置job_queue_process：設置後臺JOB相關進程個數；
alter system set job_queue_processess=6;
timed_statistics：設置爲true，使收集的時間信息存儲在動態性能視圖中，會消耗資源，採集後改成false;
alter system[session] set timed_statistics=true;
建立表空間，用於保存採樣數據，Statspack的報表數據存儲須要最小100M左右的空間；
create tablespace perfstat datafile 'e:\hs01\dat\perstat.ora' size 100m;
安裝運行@ ORACLE_HOME/rdbms/admin/spcreate.sql
生成自動採集數據任務 spauto.sql
生成分析報告 spreport.sql,輸入起始和終止快照號，生成報告在用戶系統目錄下
卸載 spdrop.sql
清除不在須要的數據 sppurge.sql
清除全部的數據 sptrunc.sql
生成快照 exec statspack.snap 
查看產生的快照
select t.snap_id,to_char(t.snap_time,'yyyy-mm-dd hh:mi:ss') as S_Time,t.snapshot_exec_time_s from STATS$SNAPSHOT t;
刪除所有歷史數據
delete from stats$snapshot where snap_id;
StatsPack報告結構及使用
1.database的整體信息
數據庫及系統信息
快照信息
三大緩存信息
2.負載間檔（Load profile）：列出了每秒和每一個事物的統計信息，監控系統吞吐量和負載變化
Redo size:每秒每事務產生的重作日誌大小（單位字節），標誌數據庫變動頻率，數據庫繁忙程度；
Logical reads:產生邏輯讀的oracle塊數，也能夠反映數據庫的業務壓力；
Block changes:變化塊數，業務繁忙程度；
Physical reads:物理磁盤讀塊數，反映系統緩衝狀況；
Physical writes:物理磁盤寫塊數；
User calls:每秒用戶call次數
Parses:解析次數
Hard parses:硬解析次數；
Sorts:排序次數
Logons:登入次數
Executes:執行次數；
Transactions:每秒產生的事務數
% Blocks changed per Read:邏輯讀系統改變的比例，另外部分爲用於查詢的比例
Recursive Call %:遞歸訪問
Rollback per transaction %:事務回滾百分比 rollback/(rollback+commit),回滾率過多，說明數據庫
                           經歷無效操做
Rows per Sort:排序的行數，反映系統排序負載
3.實例的各組件的命中率
Buffer Nowait %:DB cache中得到buffer未等待的比例，<99%說明有熱塊，能夠經過x$bh表的tch字段
                select file#,dbablk,obj,tch from x$bh order by tch desc;查到熱塊的文件和塊號
                再經過對象號能夠找到具體屬於哪一個對象的塊。v$latch_children的cache buffers chains
                查找具體的latch
Redo NoWait %:在redo cache中得到buffer的未等待比率                 
Buffer  Hit   %：DB cache的命中率，小於90%須要調整db cache的大小；
In-memory Sort %:內存排序中的排序率
Library Hit   %:sql在共享區域中的命中率，95%左右的標準（加大共享池，綁定變量，cursor_sharing
                [FORCE | SIMILAR | EXACT]參數）    FORCE字面量，不管是否最佳，SIMILAR字面量使用最佳
                EXACT徹底相同才使用                
Soft Parse %:軟解析比率，反映sql重用狀況
Execute to Parse %:1-parses/executions若是值小於0則說明shared pool存在性能問題
Latch Hit %:確保>99%不然及存在性能問題；
Parse CPU to Parse Elapsd %:解析實際運行時間/(解析實際運行時間+解析中等待資源時間)，反映CPU等
                            待時間
% Non-Parse CPU:解析外的時間，值很高說明系統大部分時間在執行查詢操做
4.共享池在兩個快照時間的整體狀況
Memory Usage %:值應穩定在75%～90%之間
% SQL with executions>1:執行次數大於1的sql比率
% Memory for SQL w/exec>1:頻繁使用的sql消耗內存比率
5.前5個等待事件，
%total call time=(wait times)/db time
Event(等待事件) 
Waits(等待次數) 
Time (s)(等待時間) 
avg wait(ms)(平均等待時間) 
%total call time(訪問總時間百分比)
db file scattered read：該事件一般與全表掃描有關，全表掃描在內存中進行，不可能放入連續的緩
                        存區，索引可能有問題，必要全表掃描的小表能夠放入keep池
db file sequential read：該事件說明在單個數據塊上大量等待，該值太高一般因爲表間鏈接順序糟糕，
                         或者使用了非選擇性索引。DB_CACHE_SIZE能夠決定該事件出現的頻率
buffer busy wait：緩衝區db cache不足或者如正在被讀入到緩衝時，就會出現該等待。該值不該該大於1%                        
latch free：常因沒有很好的應用綁定有關。閂鎖是底層的互斥機制
log buffer space：日誌緩衝區寫的速度快於LGWR寫REDOFILE的速度，能夠增大日誌文件，增長日誌緩衝
                  區，使用更快的磁盤。
logfile switch：歸檔速度不夠快，須要增大重作日誌。
log file sync：提交或回滾數據時，LGWR將會話得重作操做從日誌緩衝區填充到日誌文件中，用戶的進
               程必須等待這個填充工做完成修改應用的提交頻率，將重作日誌REDO LOG文件訪在不一樣
               的物理磁盤上。
6.CPU的平均負載，內存統計，系統時間模型，等待事件，後臺等待事件，等待事件柱狀圖
    s - second, cs - centisecond,  ms - millisecond, us - microsecond
7.TOP sql order by buffer gets,executions,parse calls
8.實例活動統計
9.OS統計信息
10.表空間IO統計
11.文件IO
12.buffer pool統計
13.PGA統計
14.進程統計
15.lstch活動統計
16.字典緩存統計
17.共享池統計
18.SGA統計
19.參數統計
參考資料：http://blog.csdn.net/tianlesoftware/article/details/4682329

3、AWR報告解讀
    AWR(Automatic Workload Repository)自動工做負載信息庫，採集與性能相關的統計數據，導出性能量
度，用以跟蹤潛在的問題。快照由一個 MMON 的後臺進程及其從進程自動地每小時採集一次，7天后自動清除，
快照頻率和保留時間用戶能夠修改。
存儲數據分類：
    WRM$表存儲AWR的元數據（awrinfo.sql腳本）
    WRH$表存儲採樣快照的歷史數據（awrrpt.sql腳本）
    WRI$表存儲同數據庫建議功能相關的數據（ADDM相關數據）
參數說明：
    statistics_level 默認是typical，在10g中表監控是激活的，建議在10g中此參數的值設爲typical。如
果STATISTICS_LEVEL設置爲basic，不只不能監控表，並且將禁掉以下一些10g的新功能：
    ASH(Active Session History)
    ASSM(Automatic Shared Memory Management)
    AWR(Automatic Workload Repository)
    ADDM(Automatic Database Diagnostic Monitor)    
生成AWR報告：
    @ ORACLE_HOME/rdbms/admin/awrrpt.sql
    指定報告格式[html/txt]
    指定起始終止快照號
    指定報告名稱
    生成報告默認存儲在用戶系統目錄裏
AWR報告參數調整：
    查看相關參數：
    select * from dba_hist_wr_control;
    調整AWR產生snapshot的頻率和保留策略(快照30分鐘生成一次，保留5天)
    exec dbms_workload_repository.modify_snapshot_settings(interval=>30, retention=>5*24*60);
    關閉AWR，把interval設爲0則關閉自動捕捉快照
    exec dbms_workload_repository.modify_snapshot_settings(interval=>0);
    手工建立一個快照
    exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();
    查看快照
    select * from sys.wrh$_active_session_history;
    手工刪除指定範圍的快照
    exec DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE(low_snap_id => 973, high_snap_id => 999, dbid => 262089084);
    建立baseline，保存這些數據用於未來分析和比較
    exec dbms_workload_repository.create_baseline(start_snap_id => 1003, end_snap_id => 1013, 'apply_interest_1');
    刪除baseline
    exec DBMS_WORKLOAD_REPOSITORY.DROP_BASELINE(baseline_name => 'apply_interest_1', cascade => FALSE);
    將AWR數據導出並遷移到其它數據庫以便於之後分析
    exec DBMS_SWRF_INTERNAL.AWR_EXTRACT(dmpfile => 'awr_data.dmp', mpdir => 'DIR_BDUMP', bid => 1003, eid => 1013);
    遷移AWR數據文件到其餘數據庫
    exec DBMS_SWRF_INTERNAL.AWR_LOAD(SCHNAME => 'AWR_TEST', dmpfile => 'awr_data.dmp', dmpdir => 'DIR_BDUMP');
    把AWR數據轉移到SYS模式中：
    exec DBMS_SWRF_INTERNAL.MOVE_TO_AWR (SCHNAME => 'TEST');
AWR報告結構和使用：
1.數據庫基礎信息，快照範圍信息
2.緩存信息
3.load profile
4.各內存區域命中率
5.shared pool統計快照區間內信息
6.TOP 5 timed events
7.Time model(時間模型)
8.Wait class
9.Wait Events
10.Background Wait Events
11.Operating system statistics
12.Service statistics
13.Service Wait class
14.SQL statistics(order by 消耗時間，CPUtime,buffer gets,physical reads,executions,Parse call,
Sharable Memory,Version count(子游標)) complete list of SQL text
15.實例活動統計
16.IO stats(tablespace,file)
17.buffer pool
18.Advisory statistics(實例恢復，buffer pool建議，PGA，shared pool建議，SGA，streams,Java建議)
19.Wait statistics(buffer,enqueue)
20.UNDO statistics
21.Latch statistics
22.segment statistics
23.dictionary cache stats
24.Library cache stats
25.Memory statistics
26.Streams statistics
27.Resource Limit Stats
28.init.ora parameter
TOP SQL的解析：
SQL ordered by Elapsed Time:記錄了執行總和時間的TOP SQL(請注意是監控範圍內該SQL的執行時間總和，
                              而不是單次SQL執行時間 Elapsed Time = CPU Time+ Wait Time)。
    Elapsed Time(S): SQL語句執行用總時長，此排序就是按照這個字段進行的。注意該時間不是單個SQL跑
                     的時間，而是監控範圍內SQL執行次數的總和時間。單位時間爲秒。Elapsed Time = 
                     CPU Time + Wait Time
    CPU Time(s): 爲SQL語句執行時CPU佔用時間總時長，此時間會小於等於Elapsed Time時間。單位時間爲秒。
    Executions: SQL語句在監控範圍內的執行次數總計。
    Elap per Exec(s): 執行一次SQL的平均時間。單位時間爲秒。
    % Total DB Time: 爲SQL的Elapsed Time時間佔數據庫總時間的百分比。
    SQL ID: SQL語句的ID編號，點擊以後就能導航到下邊的SQL詳細列表中，點擊IE的返回能夠回到當前SQL ID
            的地方。
    SQL Module: 顯示該SQL是用什麼方式鏈接到數據庫執行的，若是是用SQL*Plus或者PL/SQL連接上來的那基
                本上都是有人在調試程序。通常用前臺應用連接過來執行的sql該位置爲空。
    SQL Text: 簡單的sql提示，詳細的須要點擊SQL ID。
SQL ordered by CPU Time:記錄了執行佔CPU時間總和時間最長的TOP SQL(請注意是監控範圍內該SQL的
                          執行佔CPU時間總和，而不是單次SQL執行時間)。
SQL ordered by Gets:記錄了執行佔總buffer gets(邏輯IO)的TOP SQL(請注意是監控範圍內該SQL的執行佔
                      Gets總和，而不是單次SQL執行所佔的Gets)。
SQL ordered by Reads:記錄了執行佔總磁盤物理讀(物理IO)的TOP SQL(請注意是監控範圍內該SQL的執
                       行佔磁盤物理讀總和，而不是單次SQL執行所佔的磁盤物理讀)。
SQL ordered by Executions:記錄了按照SQL的執行次數排序的TOP SQL。該排序能夠看出監控範圍內的SQL執
                            行次數。
SQL ordered by Parse Calls:記錄了SQL的軟解析次數的TOP SQL。說到軟解析(soft prase)和硬解析(hard 
                             prase)，就不能不說一下Oracle對sql的處理過程。
SQL ordered by Sharable Memory:記錄了SQL佔用library cache的大小的TOP SQL。Sharable Mem (b)：佔
                                 用library cache的大小，單位是byte。
SQL ordered by Version Count:記錄了SQL的打開子游標的TOP SQL。
SQL ordered by Cluster Wait Time:記錄了集羣的等待時間的TOP SQL
參考資料：http://blog.itpub.net/26954807/viewspace-1300697/

4、ADDM報告解讀
    ADDM（Automatc Database Diagnostic Monitor）數據庫自動診斷監控工具收集相關的統計數據到
自動工做量知識庫(Automatic Workload Repository AWR)中，而STA（SQL Tuning AdvisorSTA）則根據
這些數據，可以自動的完成最數據庫的一些優化的建議，給出SQL的優化，索引的建立，統計量的收集等
建議。
    ADDM 經過檢查和分析AWR獲取的數據來判斷Oracle數據庫中可能的問題.而後ADDM會定位引發性能問
題的的根源,並提供解決的建議和預期能到到的改進效果.每次AWR快照(默認一小時一次)後,將會執行一次
ADDM分析,分析結果存在數據庫中,經過OEM能夠看到分析結果。
    ADDM分析的執行是從上到下的,首先肯定情況,而後分析找到性能問題的根源. ADDM 使用DB time 統計
來肯定性能問題.DB time是數據庫處理用戶請求花費的累計時間,包括等待時間和全部非閒置的用戶session
的CPU時間.性能診斷的目標就是對於特定的工做量減小系統的DB time.經過減小DB time, 數據庫使用一樣
的資源可以支撐更多的用戶請求. ADDM報告的問題區域指的就是顯著佔用了DB time的系統資源,它們是按照
相關的DB time 按從大到小的順序列出的。
生成ADDM報告
    EM工具界面生成
    執行@ /u01/app/oracle/product/10.2.0/db_1/rdbms/admin/addmrpt.sql
    指定起始snapshot和結束snapshot值
    指定ADDM報告名稱
    默認存放路徑爲用戶的系統目錄，根據字符集不一樣可能會生成部分中文的報告
ADDM報告分析範圍是按照等待類別進行分類：
    內存使用
    CPU數據庫時間
    SQL語句消耗（解析，commit,rollback）
    SGA大小設置
    PL/SQL消耗
    用戶I/O
    過分頻繁的login/logoff,內存設置偏小，致使熱塊的SQL，鎖和ITL等待，Checkpointing致使，PL/SQL,java
    Top SQL,I/O問題，Parsing問題，數據庫配置方面的問題
報告的結構和使用：
1.任務頭信息，數據庫及任務相關信息
2.FINDING n：#發現
    sql語句消耗數據庫時間
3.RECOMMENDATION：#建議
4.ACTION:#活動，只能具體問題
5.RELEVANT OBJECT:#相關對象
6.RATIONALE:#原理說明
7.SYMPTOMS：#症狀
參考資料：http://blog.csdn.net/zq9017197/article/details/16963001

5、ASH報告解讀
    ASH（active session hostory）活動會話歷史報告，數據來源爲v$active_session_history視圖
在實例級別抽取會話活動信息.記錄活動會話等待的事件。包含了被捕獲的每個sql語句的執行計劃.
可使用這個信息來識別哪部分sql執行消耗了大部分的sql執行時間.
ash報告展示瞭如下各類信息:
    sql語句的sql標識符，執行計劃標識符，執行計劃的哈希值，執行計劃，對象數，文件數，塊數
等待事件標識符和參數，會話標識符和會話序列號，模塊和操做名，服務哈希標識符，用戶組標識符。
ASH報告可分析性能問題:
    短暫的性能問題一般只會持續幾分鐘，短暫的性能問題不在出如今addm分析中，addm試圖報告指出
在分析週期內最對DB時間最有影響的性能問題。
    經過各類維度或者象時間,會話,模塊,操做或sql_id的組合來進行有範圍或針對性的性能分析。
生成ASH報告：
    執行@$ORACLE_HOME/rdbms/admin/ashrpt.sql
    @$ORACLE_HOME/rdbms/admin/ashrpti.sql[給別的實例生成ASH報告，DG備庫等]
    html/txt
    開始時間-60 #60分鐘前
    持續時間或結束時間，默認持續到當前
    報告名稱
    報告默認路徑linux在oracle用戶目錄，windows也在對應用戶的目錄裏

報告結構及使用：
1.數據庫信息及基本的取樣信息
2.TOP EVENTs #被抽樣會話活動中的頂級等待事件
    TOP user events #頂級用戶等待事件
    TOP background events #後臺登記等待事件
    TOP events values #等待事件的參數
3.LOAD Profile #抽樣會話活動活動中的負載分析
    Top Service/Model #服務和模塊信息
    Top client IDs #客戶端ID信息
    Top Command Types #SQL命令類型
4.TOP SQL #高負載SQL語句
    top sql with top events：#等待SQL狀況
    top sql with top row sources：#等待SQL和執行計劃詳細信息，肯定那部分SQL最消耗時間
    top sql using literals：#是否使用字面值，肯定對應SQL是否使用綁定變量
    top parsing module/action：#執行SQL語句的模塊和操做
    complete list of sql text：#頂級sql語句的完整的文本內容
    top pl/sql：#主要等待的pl/sql過程.
    top java：#主要等待的java程序
5.TOP SESSION #主要的等待會話信息
    top blocking sessions：#主要的的阻塞會話
    top sessions running PQs：#主要等待的並行查詢
6.TOP objects/Files/Latches #主要消耗數據庫資源的信息
    top db objects：#主要的數據庫對象(好比表和索引)
    top db files：#訪問量很高百分比的數據庫文件
    top latches：#很高百分比的閂鎖信息
7.Activity over time #長週期中的ASH報告提供負載概要深層次的信息，將抽樣時間分紅10個時間段，統計
                      每一個時段的信息
    列                       描述
    slot time(持續時間)      時段的持續時間
    solt count               在時段中抽樣會話的數量
    event                    在時段中頂級的三個等待事件
    event count              ash抽樣等待的等待事件的數量
    %event                   ash抽樣等待的等待事件在整個分析期間所佔的百分比
參考資料：http://blog.itpub.net/26015009/viewspace-776642/