『壹』 oracle awr報告怎麼分析一個sql的性能好壞
awr裡面只能初步判斷，判斷標准包括，執行次數，執行時間等。還要根據報告的等待事件等來確定是否要對sql進行調整。再往下就要自己對sql進行執行計劃分析，10046,10053事件的追蹤了。
『貳』 pl/sql 中 怎麼生成awr報告
AWR報告的原理是基於Oracle資料庫的定時鏡像功能。默認情況下，Oracle資料庫後台進程會以一定間隔（一小時）收集系統當前狀態鏡像，並且保存在資料庫中。
生成AWR報告時，只需要指定進行分析的時間段（開始鏡像編號和結束鏡像編號），就可以生成該時間段的性能分析情況。AWR鏡像保存在資料庫中的時間為一個月左右。
『叄』 oracle的awr報告分析parse cpu to parse elapsd 低怎麼優化
cpu較高，一般是SQL執行頻率太快導致，看看「SQL ordered by CPU Time」中有沒有異常的SQL
『肆』 如何使用AWR報告來診斷資料庫性能問題
Interpretation
在處理性能問題時，我們最關注的是資料庫正在等待什麼。
當進程因為某些原因不能進行操作時，它需要等待。花費時間最多的等待事件是我們最需要關注的，因為降低它，我們能夠獲得最大的好處。
AWR報告中的"Top 5 Timed Events"部分就提供了這樣的信息，可以讓我們只關注主要的問題。
•
Top 5 Timed Events
正如前面提到的，"Top 5 Timed Events"是AWR報告中最重要的部分。它指出了資料庫的sessions花費時間最多的等待事件，如下：
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
db file scattered read 10,152,564 81,327 8 29.6 User I/O
db file sequential read 10,327,231 75,878 7 27.6 User I/O
CPU time 56,207 20.5
read by other session 4,397,330 33,455 8 12.2 User I/O
PX Deq Credit: send blkd 31,398 26,576 846 9.7 Other
-------------------------------------------------------------
Top 5 Events部分包含了一些跟Events（事件）相關的信息。它記錄了這期間遇到的等待的總次數，等待所花費的總時間，每次等待的平均時間；這一部分是按照每個Event占總體call time的百分比來進行排序的。
根 據Top 5
Events部分的信息的不同，接下來我們需要檢查AWR報告的其他部分，來驗證發現的問題或者做定量分析。等待事件需要根據報告期的持續時間和當時數據
庫中的並發用戶數進行評估。如：10分鍾內1000萬次的等待事件比10個小時內的1000萬等待更有問題；10個用戶引起的1000萬次的等待事件比
10,000個用戶引起的相同的等待要更有問題。
就像上面的例子，將近60%的時間是在等待IO相關的事件。
• 事件"db file scattered read"一般表明正在做由全表掃描或者index fast full scan引起的多塊讀。
• 事件"db file sequential read"一般是由不能做多塊讀的操作引起的單塊讀（如讀索引）
其他20%的時間是花在使用或等待CPU time上。過高的CPU使用經常是性能不佳的SQL引起的（或者這些SQL有可能用更少的資源完成同樣的操作）；對於這樣的SQL，過多的IO操作也是一個症狀。關於CPU使用方面，我們會在之後討論。
在以上基礎上，我們將調查是否這個等待事件是有問題的。若有問題，解決它；若是正常的，檢查下個等待事件。
過多的IO相關的等待一般會有兩個主要的原因：
• 資料庫做了太多的讀操作
• 每次的IO讀操作都很慢
Top 5 Events部分的顯示的信息會幫助我們檢查：
• 是否資料庫做了大量的讀操作：
上面的圖顯示了在這段時間里兩類讀操作都分別大於1000萬，這些操作是否過多取決於報告的時間是1小
時或1分鍾。我們可以檢查AWR報告的elapsed time如果這些讀操作確實是太多了，接下來我們需要檢查AWR報告中 SQL
Statistics 部分的信息，因為讀操作都是由SQL語句發起的。
• 是否是每次的IO讀操作都很慢：
上面的圖顯示了在這段時間里兩類讀操作平均的等待時間是小於8ms的
至於8ms是快還是慢取決於底層的硬體設備；一般來講小於20ms的都可以認為是可以接受的。
我們還可以在AWR報告"Tablespace IO Stats"部分得到更詳細的信息
Tablespace IO Stats DB/Inst: VMWREP/VMWREP Snaps: 1-15
-> ordered by IOs (Reads + Writes) desc
Tablespace
------------------------------
Av Av Av Av Buffer Av Buf
Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms)
-------------- ------- ------ ------- ------------ -------- ---------- ------
TS_TX_DATA
14,246,367 283 7.6 4.6 145,263,880 2,883 3,844,161 8.3
USER
204,834 4 10.7 1.0 17,849,021 354 15,249 9.8
UNDOTS1
19,725 0 3.0 1.0 10,064,086 200 1,964 4.9
AE_TS
4,287,567 85 5.4 6.7 932 0 465,793 3.7
TEMP
2,022,883 40 0.0 5.8 878,049 17 0 0.0
UNDOTS3
1,310,493 26 4.6 1.0 941,675 19 43 0.0
TS_TX_IDX
1,884,478 37 7.3 1.0 23,695 0 73,703 8.3
>SYSAUX
346,094 7 5.6 3.9 112,744 2 0 0.0
SYSTEM
101,771 2 7.9 3.5 25,098 0 653 2.7
如上圖，我們關心Av Rd(ms)的指標。如果它高於20ms並且同時有很多讀操作的，我們可能要開始從OS的角度調查是否有潛在的IO問題。
『伍』 除了做AWR，運行什麼語句找到資料庫最慢的SQL語句
1，兩個快照之間。
2，Executions 執行次數
Rows per Exec 每次執行處理的行數
Rows Processed 總處理行數
CPU per Exec是單個SQL的CPU耗時
Elap per Exec是執行一次SQL的平均時間
『陸』 系統的一個異常SQL的處理
下面是在awr報告裡面看到的有問題的sql，是9個變數的，在應用前台屬於關聯查詢，在sqlplus裡面手工執行檢查實際執行情況如下：
下面是查詢到的綁定變數值，可以通過查看v$sql_bind_capture視圖來查看變數的實際值，如果時間比較久，可以使用如下的語句查看歷史的綁定變數信息
以下是開啟了autotrace 選項跟蹤的手工執行情況，從執行效率上看是沒有問題的。
從執行計劃和表的數據量等方面判斷如果sql的開銷有問題，應該出現在表SAMS_CHECKINOUT上面，下面檢查該表上面索引的創建語句看是否有問題
下面是在awr報告裡面看到的有問題的sql，是9個變數的，在應用前台屬於關聯查詢，在sqlplus裡面手工執行檢查實際執行情況如下：
下面是查詢到的綁定變數值，可以通過查看v$sql_bind_capture視圖來查看變數的實際值，如果時間比較久，可以使用如下的語句查看歷史的綁定變數信息
以下是開啟了autotrace 選項跟蹤的手工執行情況，從執行效率上看是沒有問題的。
從執行計劃和表的數據量等方面判斷如果sql的開銷有問題，應該出現在表SAMS_CHECKINOUT上面，下面檢查該表上面索引的創建語句看是否有問題
從上圖可以看到，實際測試出來的執行計劃跟awr報告上不同。
現在要對sql做測試
我們通過/*+ gather_plan_statistics */ 收集的相關執行計劃及其統計信息與該SQL的AWR報告中的執行計劃不同，且邏輯讀的數量與AWR報告中的數值也相差巨大。因此，為了更准確的判斷問題，按以下方法測試。
1、SQL在生產庫（SAMS庫的實例 1上，實例名為sams1 ）上，在SQLPLUS中執行。
2、執行後，在同一SQLPLUS窗口中，立即執行以下命令：
結果如下：
1、在目錄下創建一個腳本文件，用來獲取更加相信的信息。
2、在SQLPLUS中，執行以下命令：@sql_rpt 3271368959 1 24114 24115 99vaabs5ptktb
4、執行完成後，在該目錄下生成一個HTML文檔，拿到更加詳細的sql統計信息附帶表的數據信息
初步分析如下：
1、該SQL執行一次的邏輯讀為11130塊次，其中第37步的邏輯讀為6127塊次，佔了一半還多。而該步的操作是根據前面的獲取到的ROWID，回表SAMS_CHECKINOUT獲取"SC".「CHECKTIME"[TIMESTAMP,11], "SC"."VERIFYCODE"[CHARACTER,4], "SC"."SN"[NVARCHAR2,40], "SC"."INSYSTIME"[TIMESTAMP,11]四列的內容。
2、第38步對SAMS_ICLOCK表的全表掃描，對整個SQL的邏輯讀也有較大貢獻。但這個不是問題的關鍵
另外索引上有兩個想法：
1、新建組合索引或改造已有索引，按如下順序構建組合索引：
（BADGENUMBER, CHECKTIME, SN, VERIFYCODE, INSYSTIME）
2、在表SAMS_ICLOCK上創建組合索引，列名及順序如下：
（SN, ALIAS）
這兩個索引先暫時不創建，先從其他方面入手
由於在測試過程中，其生成的執行計劃從未與AWR中顯示的執行計劃一致過。所以，這也許是造成不能模擬出2億個塊次邏輯讀的一個原因。因此，把有問題的SQL的執行計劃綁定到的測試SQL上。然後執行該測試SQL，並觀察和分析測試SQL的執行過程和結果來做出進一步的處理。
為完成上述想法，需要用到ORACLE的SQL PROFILE在不改變SQL文本的前提下，改變其執行計劃。操作方法如下：
1、在SQLPLUS中，生成問題SQL的創建SQL PROFILE的腳本。該腳本執行後，會要求分別輸入SQL_ID和PLAN_HASH_VALUE的值。而我們問題SQL的SQL_ID是99vaabs5ptktb，PLAN_HASH_VALUE的值是4243346097。腳本執行完成後，會在運行SQLPLUS的當前目錄中生成一個腳本文件。其名稱在執行腳本過程中的結尾有顯示。為描述方便，簡稱該生成的S腳本文件為「問題SQL腳本」。
2、再次執行該腳本，只不過這次輸入測試SQL的SQL_ID和PLAN_HASH_VALUE。其SQL_ID為3kys9xsdjrm3b，PLAN_HASH_VALUE的值為561269195。為描述方便，簡稱該生成的腳本文件為「測試SQL腳本」
3、在文本編輯工具中分別打開上述兩個腳本，將問題SQL腳本中出現在以下特徵文字之間的文字（不包含特徵文字 ）復制並覆蓋掉測試SQL腳本中同樣位置的原文字：
h := SYS.SQLPROF_ATTR(
………
……….
……….
:signature := DBMS_SQLTUNE.SQLTEXT_TO_SIGNATURE(sql_txt);
4、將測試SQL腳本另存為一個文件（後綴名為.sql）
5、在SQLPLUS中執行第4步另存後的腳本。
6、在SQLPLUS中原封不動的執行原測試SQL。(註：執行前設置SQLPLUS格式,以避免格式混亂。比如 set lines 200 set pagesize 100 )
7、執行 select * from table(dbms_xplan.display_cursor('','','allstats projection last'));
如果正常生成腳本，沒有報錯信息出現在屏幕上，就是生成腳本成功。比如出現下面的提示就是正常的：
『柒』 如何利用pt-query-digest分析慢查詢日誌top SQL
Oracle資料庫可利用awr報告來查找top sql，其實MySQL中，我們可以利用pt-query-digest工具來查找時間最長的TOP SQL。
pt-query-digest可以從普通MySQL日誌，慢查詢日誌以及二進制日誌中分析查詢，甚至可以從SHOW PROCESSLIST和MySQL協議的tcpmp中進行分析，如果沒有指定文件，它從標准輸入流（STDIN）中讀取數據。
[apps@mvxl0782 bin]$ pwd
/apps/tool/percona-toolkit-2.2.10/bin
[apps@mvxl0782 bin]$ ./pt-query-digest /apps/logs/mysql/slow3306.log
整個輸出分為三大部分：
1、整體概要（Overall）
# 8.9s user time, 50ms system time, 25.92M rss, 200.46M vsz
『捌』 如何通過awr，ash，addm報告查看oracle的異常sql語句
AWR（ Automatic Workload Repository ）報告是對oracle的性能評定以及發現問題SQL語句的重要手段。 AWR報告的原理是基於oracle資料庫的定時鏡像功能。默認情況下，Oracle資料庫後台進程會以一定間隔（一小時）收集系統當前狀態鏡像
『玖』 如何每天從awr抓取top sql
AWR的數據主要有兩部分組成：1）保存在內存中的系統負載和性能統計數據，主要通過v$視圖查詢 ；2）mmon進程定期以快照(snapshot)的方式將內存中的AWR數據保存到SYSAUX表空間中，主要通過dbA_*視圖訪問。1. AWR快照的生成默認情況下，每隔一小時自動產生一個快照，保存最近7天的信息，可以通過以下語句查詢：sql>select SNAP_INTERVAL,RETENTION from dba_hist_wr_control;SNAP_INTERVAL RETENTION----------------------------------------------------------+00000 01:00:00.0 +00007 00:00:00.0可以通過以下語句修改時間間隔和保存時間(以分鍾為單位)：exec dbms_workload_repository.modify_snapshot_settings(interval => 30, retention = > 10*24*60);也可以根據需要隨時手動生成快照：exec dbms_workload_repository.create_snapshot;2. AWR報告的生成以sysdba運行如下命令：@?/rdbms/admin/awrrpt.sql3. AWR報告的分析策略因為AWR報告非常長，不可能從頭到尾一字不漏的去看，要有選擇的去看重點部分。最好能對照的來讀，即和系統正常情況下的AWR報告對比，找差異。AWR報告採用總分的形式，前面是系統的整體情況，後面是各個部分細節，一開始不要陷入細節，先分析系統的整體狀況，對於後面的專題分析，要根據關注點的不同，採取跳躍式分析。還要根據具體業務的不同，決定某種現象是否正常。系統整體狀況方面1）Load Profile：分析系了解系統整體負載狀況，如每秒中的事務數/語句數，每秒/每事務物理讀寫次數(Physical Reads/Writes), 邏輯讀寫次數(Logical Reads/Writes)，sql語句的解析(Parse)，特別是硬解析次數等。2）Instance Efficiency Percentages：各指標都應接近100%，除了：execute to parse (70%以上)和parse cpu to parse elapsed。如果不符合，基本可以確定系統存在性能問題；但是如果反過來，即都符合，也不能說明系統完全正常，還要看實際情況。具體狀況方面1）Top 5 Timed Events：這里列出消耗時間最多的5個等待事件，每種等待說明，都表示一種原因，如：db file sequential read表示按索引訪問出現等待，db file scattered reade表示全表掃描訪問出現等待事件。2）Top N sql：根據時間消耗，內存消耗，物理I/O等排序，對相關sql分析執行計劃3）如果是rac環境，需要特別關注rac Statistic中的相關指標4）sga pga分析5）分析表空間、數據文件I/O
『拾』 除了做AWR，運行什麼語句找到資料庫最慢的SQL語句
一般沒有上awr，ash時，簡單下我就直接用v$sql查看下top disk reads，一般相對來說單次buffer gets大，disk reads也會是top的，當然IO只是一部分，例如cpu的消耗等，sql執行過程中產生的latch競爭 熱點快等，更多是由於並發競爭，單獨看sql邏輯讀是重點，而物理讀top是比較容易體現此sql的IO消耗的，物理讀大的sql往往邏輯讀也是top的！