Oracle Performance Tuning 11g2 (6-2)

下面是我的一個試驗：

第一階段是準備工作：

1. 建立一個使用者

2. 檢視一下系統啟動和目前的時間，我用的是虛擬機器，所以從10號就沒關機，是從13:33:16開始啟動的

3. 先建立一個表

4. 第一次插入資料後，有76166條記錄

5. 不斷的向裡面插入資料，最後達到了1218656 * 2條資料，即有2437312資料。

6. 然後執行select * from my_objects1 where owner = ‘WP’的語句，因為沒有索引，我期望這條語句能慢一些，這樣我就能收集到資料了。

因為這個my_objects1是沒有索引的，我的主要目的是看看ADDM能否分析出我這個SQL語句沒有建索引，然後能否給出我一個建議來。

準備從這裡開始分析，所以我先建立一個當前的快照，不想去分析這個準備工作的工作。

可以從dba_hist_snapshot中看到目前的快照資訊，也就是從129開始的

現在開始做一次ADDM分析

我在收集的時候是加有spool t.txt; 最後再執行spool off;的，所以這個報告放到檔案 t.txt檔案中

從這個報告中可以看到，在128到129這兩個快照中，一共的：Total database time was 115 seconds。

竟然說我沒有問題！

原因何在呢？因為我的資料庫記憶體是1G，整個虛擬機器是3G，我的電腦是6G，表很多內容還是快取在記憶體中的；同時因為這個時間差有115秒，而執行這個語句其實也就幾秒種，所以ADDM認為這個還是可以接受的，雖然我知道它有問題，但是顯然ADDM僅以DB TIME去判斷是犯了錯誤。

這位我再測試一下，一來不使用繫結變數，二來全部全表掃描，並且快照間隙再小了一點，然後分析這個報表。

declare

v_num number;

begin

for i in 1..1000000 loop

select cnt into v_num from (select count(*) as cnt from my_objects1 where DATA_OBJECT_ID = i);

end loop;

end;

/

這次呢我從132的快照開始即：014919開始執行，一直沒停過，在外面吃點東西，回來已經024903分了，這次這個執行是消耗了絕大多數時間了。

這次我們可以看到，終於有報告出來了！ 總的時間是778秒 ， 778 / 60 = 12.9分鐘。可是我們是從014919 ~ 022403 這期間大約有34分鐘呢，為什麼只有12.9分鐘呢？因為是DB TIME,不是牆上時鐘的

先看看報告的總體框架：

1. analysis period --> 分析的週期，即快照的時間

2. analysis target --> 分析的目標，即資料庫的概要資訊，這裡可以看到，我分析ANALYZE_DB，但是它卻是按例項去分析的

3. activity during the analysis period --> 總的活躍性

4. summary of Findings --> 總的介紹，這裡看到有2個問題，一個是SQL問題，一個是IO問題

l Findings and Recommendations

l Finding 1

l Finding 2

l Additional Information

從這個Finding 1:中可以看到問題的根原是由SQL引起的，接下來就是recommendation 1:建議我們使用sql tunning去除錯一下我們的SQL語句：

action: 使用sql tunning去除錯一下，它將我們這個sql的sql_id給了我們，這樣就容易做了

接下來有5個Rationale（原理），這些原因就是為了解釋資料庫為什麼要我們去做SQL TUNING，也就是說它要我們做是有科學依據的。

一：這條SQL佔據了太多的CPU,IO；

二：將SQL解析完後，100%時間在執行，0%用於解析，0%用於PL/SQL,0%用於JAVA。其實不是0%用於解析，而是可能是0.01%，資料庫一看是不到1%就省略了

三：這條SQL語句執行了197次，平均是3.8秒。因為我在寫這個PL/SQL塊時，一開始有錯誤，所以除錯時多執行了幾次，本質上不是這次執行這麼多

四：對wp.my_objects1表進行了全表掃描，這個物件的ID是76906（可以從dba_objects中檢視到這物件資訊了）

五：列出了我當時執行的PL/SQL塊，看看寫的是什麼

因為不斷的消耗IO中，所以finding 2給出了IO的問題，這裡和finding 1不同，因為這裡給了3個ACTION，卻只有1個rationale

三個ACTION是：使用SEGMENT ADVISOR；查一下在my_objects1上有什麼應用邏輯處理；看一下TOP SQL的那個 SQL_ID問題

一個rationale： 在這個物件上有199次全表掃描，一共有6，925，051次物理讀

最後是一些額外資訊，在這裡我們看到wait class “Application，commit,concurrency,confiuration,network”,CPU,connect,hard parse都沒有消耗足夠的資料庫時間，所以在消耗這些類的活動都沒有列出來。

瞭解完整個報告之後，再這篇文章的開始看，發現寫了太多的廢話，可以說根本用不著再看了，這篇文章只要知道怎樣去收集資料庫分析模式，例項模式；知道怎樣去顯示報告；知道怎樣去看這個報告就可以了。其它的廢話不用去看了

最後再看一下：