Oracle性能優化圖文詳解——利用第三方工具

     開發中或者是正在運行的系統性能顯著惡化的場合，須要進行性能優化。當聽到性能優化時，有些人可能會感受到很是困難，若是使用第三方工具的話，經過使用索引或者內存等能夠很是簡單的進行性能優化。這篇文章將以 Object Browser爲例來介紹怎樣簡單優化數據庫性能。

性能優化是什麼

EC系統的「3秒鐘規則」

    假設在EC網站上，訪問網站的顧客都必需要等待三秒鐘的響應時間，這個時間被稱爲「3秒鐘規則」。若是響應時間在三秒鐘以上的話，顧客就會認爲這個網站服 務慢，有可能會致使商業機會的丟失。不用說EC網站的例子，爲了有效的推行業務，系統的性能是很是重要的。系統中並不只僅要安裝重要的功能（功能需求）， 還必需要知道響應時間是多少，單位時間內電腦的處理量、通訊線路的數據傳送量等（非功能需求）。

    數據庫即便是在系統開發的後端，也有調整響應時間的性能優化。數據庫性能優化就是針對響應時間很是慢的場合實施的對策。OB有不少功能支持性能優化。

性能優化的流程

     如下是包含數據庫的通常的性能優化的流程。

    1.  調查

        性能優化首先要從性能測定和找到產生問題的地方開始。要把系統構成和應用設計做爲優化對象進行確認和測定，調查延遲緣由。

        測定方式除了響應時間以外，還能夠查看SQL實行計劃中「cost」使用量。

    2.  設定目標值

        接下來，咱們要知道要把性能改善到何種程度。進行性能優化有不少種手段，要是所有實施的話將是沒完沒了的，因此最重要的是設定目標值。

        要考慮系統至少須要把性能調整到何種程度，例如EC網站要把響應時間縮短到3秒之內等等。

    3.  研究改善對策

        決定了目標以後就要研究改善對策了。應用邏輯有問題的話就把算法修改爲更高效的，SQL有問題的話就把表的關聯儘可能減小。

        還有給表設定合適的索引，把外部的應用處理用存儲過程的形式。儘可能找到達成目標的最有效的方法。

    4.  實施/調整

        決定了改善對策以後，進入實施階段，看可否達成目標。若是目標達成了，性能優化就成功了。也有實施對策以後沒有達成目標的狀況，這時就要重複一遍以上的步驟，改變改善對策。

        假若有多個改善對策的話，能夠改變改善方法或者是追加改善方法。也許還會遇到其餘的瓶頸，這時要返回去從新進行緣由分析。在達成目標以前，以上的步驟要循環1~4圈。

圖1：性能優化順序

        所謂瓶頸就是數據庫服務器的內存不足，或者SQL的處理速度等數據庫外部的性能調整。本篇文章介紹如何使用OB進行數據庫優化。

SQL處理速度的改善（優化索引）

    最初運行良好的系統忽然變的很是慢，這一般被認爲是由於數據的增長使響應速度下降。像這種場合，「優化索引」屢次發揮了效果。

    優化索引就是給表作成合適的索引，改善性能的方法。若是表中沒有索引的話，檢索時就是從表全部數據中進行搜索（全表搜索）。進行全表搜索時，若是數據量很 大的時候訪問速度就會很是慢。這時，若是給表設置合適的索引的話，從大量的數據中有目的的高效的進行搜索，這就能夠改善性能。如下是通常優化索引的順序和 OB的功能。

    1.  抽出運行慢的SQL-->SQL緩存

    2.  測量SQL的性能-->實行計劃

    3.  作成合適的索引-->索引顧問

圖2：索引優化順序

    使用「SQL緩存」找到SQL性能低下的緣由。用「實行計劃」測量性能。用「索引顧問」決定改善對策。

抽出速度慢的SQL  「SQL捕捉」

    接下來要具體介紹「SQL捕捉」的操做方法。爲了進行索引優化，首先要從全部的SQL文中找到速度慢的SQL。

    SQL捕捉，是跟蹤SQL一覽表示處理速度和測定結果的功能。此功能在「工具」菜單的「SQL捕捉。

    SQL捕捉是爲了調查正在運行的SQL所實施的跟蹤。跟蹤就是對正在運行的SQL的記錄。初次啓動SQL捕捉時，顯示的是跟蹤文件存在的文件夾對話框。

    關於跟蹤文件夾必定要指定成Oracle數據庫服務器上跟蹤文件存在的文件夾。一般是「Oracle Home/ADMIN/ORCL/UDUMP」。

    必定要指定成數據庫服務器上的文件夾。安裝OB的客戶端機器和數據庫服務器不一樣場合，利用操做系統的網絡共享功能，指定成客戶端和服務器都能參照的文件夾。

    TIPS 想要變動跟蹤文件存在的文件夾時

    在主菜單的「SQLcatch」-->「選擇跟蹤文件夾」中指定便可。

    指定了跟蹤文件夾以後，SQL緩存畫面就表示出來了。

    SQL跟蹤的結果被作成日誌文件保存在剛剛設置的文件夾內。

    點擊畫面左上角的「開始」按鈕，開始跟蹤。顯示跟蹤實行畫面，咱們要指定對數據庫全體進行跟蹤仍是對個別session進行跟蹤。若是要對個別 session進行跟蹤的話，要選擇想要調查的應用對應的session，而且還要在應用中執行登陸操做等，作成數據庫session。

    若是選擇對數據庫全體進行跟蹤的話，就是對全部的session進行跟蹤。可是，要把初期化參數「SQL_TRACE」設置成TRUE。

    跟蹤開始後，能夠回到應用頁面進行操做。例如，EC網站中商品檢索畫面緩慢的話，能夠執行商品檢索操做。這時，正在運行的SQL會記錄在跟蹤日誌中。

    操做完成以後，返回到OB，點擊「中止」，中止跟蹤，接下來確認一下跟蹤結果。點擊SQL緩存畫面的「表示」按鈕，跟蹤結果畫面顯示出來。

              COUNT：SQL文實行或者是解析的次數

              CPU：SQL進行解析/實行/取得操做，CPU耗費的時間

              ELAPSED：通過時間

              DISK：實行中讀出物理塊的次數

              QUERY：SQL語句要求的總讀取次數

              CURRENT：SQL語句要求的正在執行的讀取次數

              ROWS：實行中處理的行數

              SQL：實行的SQL文

    CPU列表明處理速度，點擊這些列使他們按照處理速度排序，找到速度慢的SQL。

測量SQL的性能

    找到速度慢的SQL以後，在SQL實行畫面的「實行計劃」功能能夠測量SQL的性能。

    「實行計劃」就是在SQL實行以前數據庫內部進行的處理。例如，若是是SELECT的話，多表結合的方法、順序，是否使用索引取得數據，這些都是基於數據庫內部的信息決定的。在數據庫內部具備決定實行計劃功能的部分叫作「優化器」。

    在SQL實行畫面中點擊「實行計劃」按鈕，「實行計劃」按鈕是on的狀態時，輸入SQL文，點擊「實行」 按鈕，此時進行的是SQL解析，實行計劃表示出來。

    TIPS  從SQL緩存畫面也能夠取得實行計劃

    在SQL緩存畫面選中某行點擊鼠標右鍵，從彈出的對話框中選擇「實行計劃」便可。

    在這之中，索引優化最重要的是如下兩點。

    COST

    實行計劃最右面的列就是COST。COST就是數據庫處理SQL的負荷，是一項性能指標。COST的單位不是秒，1COST至關於多少秒是受服務器的硬件 影響的，因此不能進行嚴密的換算，能夠相對的進行比較。例如，實際上系統的響應時間是30秒，目標值是3秒，只需把COST值縮小10倍就能夠了。

    是否使用索引

    進行全表搜索時（沒有使用索引的場合），實行計劃的行是紅色的。這樣就能夠知道還能夠進行索引優化。

作成合適的索引 「索引顧問」

    從實行計劃得知沒有使用索引時，可使用OB的索引顧問功能作成索引。若是不使用索引顧問還能夠在索引畫面手動作成，可是並非索引使用的越多就越好。

    例如「書籍」表，索引是「目次」。通常讀者只想讀書的一部分的話，首先要參照目次，找到想看的內容的頁數。可是若是書只有20幾頁的話，讀者就不須要看目次，直接找到相應的頁數。反過來，若是目錄有100多頁的話，誰也不會使用這麼麻煩的東西。

    決定實行計劃的優化器也認爲當記錄數不多的時候最好不要使用索引。而且，當索引對象的列不少的時候，由於索引佔的空間很大，也不要使用索引。爲了做成合適的索引必需要考慮這些問題。可是，使用OB的索引顧問的話，即便不知道這些規則，也能夠作出合適的索引。

在使用索引顧問以前

    要使用索引顧問，須要作兩項準備工做。第一個是做成足夠的數據。

    前面說到，判斷使用索引仍是沒有使用索引的重要的指標就是數據量。因此，當數據不多時，要使用數據生成工具生成一些數據。

    還有就是要獲取最新的統計信息。優化器統計表的行數時並非每次都使用COUNT文，而是從統計信息中取得行數。若是統計信息不是最新的話，優化器就不能作出最好的判斷。

    獲取最新的統計信息的方法是，在對象列表中選中一個表點擊鼠標右鍵，選擇「統計信息」，更新畫面顯示出來。點擊「開始」就能取得最新的統計信息。Ctrl+A能夠選中全部表。

    在統計信息畫面有不少選項，由於咱們的目的是優化索引，因此選擇「收集精確的統計信息」。

    TIPS  基於規則、基於COST

    Oracle 的優化器有基於規則和基於COST兩種模式。上面說到優化器決定實行計劃的時候要考慮記錄數，這嚴密的說應該是基於COST場合須要作的。當實行計劃是基 於規則，則不用考慮記錄數，須要遵循必定的規則作出實行計劃，例如，使用WHERE句的列是否包含在索引的對象列中。

    優化器的模式是基於規則的時候，不須要作成數據和更新統計信息，通常不推薦使用基於規則的模式。剛纔圖書的例子，參考統計信息的基於COST的方法更好一些。所以，在Oracle10g之後，OB廢棄了基於規則的優化器模式。

    使用哪一個模式能夠在初期化參數「OPTIMIZER_MODE」中查詢。

    準備工做完成以後，啓動索引顧問。「工具」-->「索引顧問」。

    在索引顧問畫面有「輸入SQL」，「如今的索引」，「作成的索引」3部分。首先在最上方的「輸入SQL」欄中寫入要優化的SQL。索引顧問頁面和SQL實 行畫面同樣，有履歷管理的功能。由於這個履歷和SQL實行畫面的履歷是共有的，因此想在SQL實行畫面查詢實行計劃的話，點擊「前」或者是「履歷」按鈕， 就能夠呼出一樣的SQL。

    SQL輸入完成後，點擊「解析」按鈕，在頁面中間的「如今的索引」欄內表示的是表和附加在表上的索引的使用情況。沒有被使用的索引用紅色表示，若是索引不須要了，能夠用DELETE鍵或者點擊鼠標右鍵「消除」進行刪除。

    在頁面下面的「作成的索引」欄中表示的是每一個表中被認爲是有用的索引。這個欄中表示的是沒有被作成的索引，選擇一項點擊「作成」按鈕，索引就被作成了。

    可是，咱們不知道這樣作成的索引是否必定被使用。

    索引顧問是解析SQL，得出候補的索引，可是根據記錄數的不一樣，作成的索引是否被優化器使用是不同的。所以，OB有了比較索引作成先後的COST數的功能。點擊「測試」按鈕，獲得索引作成前和作成後的COST數。

    若是作成前和作成後的結果不同的話，就證實使用了索引。若是結果沒變的話，就是即便作成了索引也沒有被使用。和實行計劃功能同樣，性能是用COST表示 的，不只僅是索引的使用情況，根據變化也能夠知道性能提升了多少。用戶能夠按照候補索引的順序依次測試，選擇結果最好的索引。

    索引作成以後，會自動進行再解析，最後作成的索引會出如今「如今的索引」欄目中，請確認索引是否被使用。

    到此爲止索引優化就完成了。

    TIPS 不要使用過多的索引

    是每一個SQL決定索引是否被使用，最合適的索引是什麼依據SQL的不一樣而不一樣。一個表不可能只對應一種SQL。即便是不常被更新的主表，除了從管理工具訪問以外，還可能和事務內的其餘表結合。若是作成多個SQL共同使用的索引很困難的話，那麼就給一個表設置多個索引。

    可是，索引過多也很差。索引在表中的數據更新的同時會進行再構築，若是索引多時，就會增長表更新時的負荷。所以，最好是把想要改善性能的SQL和頻繁使用的SQL做爲索引的對象。

資源的優化

    前面介紹的是經過優化SQL改善性能。若是是由於隨着數據量的增長而致使性能惡化的話，這些方法是有效的。可是也有多是由於內存不足輸入輸出增 加，CPU使用到達界限，數據庫服務器的資源不足等。OB有改善這些問題產生的性能惡化的「資源優化」功能。資源優化按照下面的順序進行。

    1.  資源情況測定 「性能信息」

    2.  資源優化 「初期化參數變動」

    首先參照Oracle的系通通計和I/O統計等統計信息，而後更改Oracle資源設定中初期化參數的信息。

資源情況測定

OB中使用「性能信息」來調查資源不足的緣由。「性能信息」畫面在「管理」菜單中。

    性能信息畫面有系通通計和I/O相關的統計等一些項目。重要的項目在前面用表示，選擇這個項目就會顯示項目的說明和改善方法。

    可是多數狀況下是確認這些參數在性能剛開始下降時候的值，即便是有專業知識的專家在性能已經惡化的狀態下找出緣由也是很是困難的。因此，OB提供了按期保存性能信息的功能。保存性能良好時參數的值，這樣就能夠和性能惡化時的參數值進行比較。

    這個功能在「工具」-->「選項」-->「詳細設置」中，選擇「DB鏈接結束時自動保存」，設置保存時間間隔。OB終了時若是到了保存間隔的話就會把參數自動保存起來。例如把保存間隔設成30天的話，就是每30天進行一次保存。

    被保存起來的信息在性能信息畫面表示，能夠把性能惡化前和惡化後的值進行比較。

改善初期化參數

    在「性能信息」中斷定性能惡化的緣由是內存等資源不足的狀況下，可使用改變初期化參數的方法進行性能改善。打開「管理」-->「數據庫信息」，打開「初期化參數」選項卡。

    如下是和性能改善相關的具備表明性的參數。

   SGA_MAX_SIZE：SGA的最大值。SGA（System Global Area）是數據庫緩衝區高速緩存和共享池等服務器進程使用的內存區。

   DB_CATCH_SIZE：數據庫緩衝區高速緩存大小。它的值越大，訪問數據的速度越快。

   SHARED_POOL_SIZE：共享池的大小。它的值越大，程序庫緩存的命中率越高，SQL的實行速度越快。

   JAVA_POOL_SIZE：JAVA池的大小。它的值越大，JAVA存儲過程等的實行速度越高。

   SORT_AREA_SIZE：排序使用的內存容量。它的值越大，排序的速度越快。

   LOG_BUFFER：把REDO信息寫入REDO日誌文件時使用的內存容量。它的值越大，寫入REDO日誌文件的等待時間就越少。

   根據Oracle版本的不一樣，這些項目有可能能修改也有可能不能被修改。「變動」列說明了是否能被修改。

   當變動的狀態是「可能」時，雙擊「值」，會出現變動對話框。

    「不能」的場合能夠更改init.ora或者SPFILE等設定文件，並從新啓動數據庫。

    修改初期化參數是性能優化中很是容易執行的方法，由於要增長Oracle使用的內存空間，因此要先肯定服務器剩餘的內存容量。

表訪問的優化

表領域的分割

    最後介紹一下其餘的優化方法。SQL的處理速度很是慢的時候嘗試用索引優化的方法，可是卻不能把性能提升到目標值。這時，可使用提升表訪問速度的組合分區的方法。

    分區是硬盤的讀取和寫入同時進行的技術。數據庫有表領域的概念，表領域其實是和存放數據的操做系統上的文件有關。表和表領域是從屬關係，一個表可能屬於 一個表領域，可是若是進行分區的話，就能夠把表分紅幾個表領域存放。這樣就可使讀取和寫入並列化，從末端改善表訪問。

分區的順序

    要作成表領域選擇「管理」菜單-->「表領域信息」。在表領域一覽畫面點擊「新建」按鈕，顯示新建畫面。

    至少要輸入的項目是「表領域名」，「文件地址」，「大小」。「文件地址」是服務器上的地址。「大小」是知道表的容量以後設定的。除此以外的項目都不是必須設定的。設定完成後，點擊「做成」按鈕，表領域就作好了。請按須要添加表領域的數量。

    TIPS  調查表領域所需的大小

    表領域必須的數據大小大概是表中各列數據的長度和總數據行數的乘積。可是，嚴密來講表的block size和INITRANS等表領域相關的設定也是有影響的。把這些也考慮進去計算表領域大小的工具是Oracle免費提供的。

http://otn.oracle.co.jp/document/estimate/index.html

「SI Object Browser ER」也提供了估算表領域大小的功能。

    表領域作成以後，在表畫面的「領域信息」選項卡內進行設定。表作成時的存放方法是「一般」，這樣可指定的表領域就只有一個，若是把存放方法改爲「範圍分區」，「列表分區」，「散列分區」中的任何一個，就能夠分區化。

    範圍、列表、散列的不一樣之處是各條數據分配方法的不一樣。分區的場合指定表中的一列是主鍵，根據主鍵對應的值把數據分配在各個分區中。如下是分配方法。

    範圍分區

    根據值的範圍存放在不一樣的表領域中的方法。指定上限值欄內各個表領域包含的數據的範圍來分配表領域。例如，當想根據價格等數值類型、日期類型分配表領域的時候使用。

    列表分區

    根據值指定表領域。例如，當想根據價格等數值類型、日期類型分配表領域的時候使用。當輸入的值是數據庫標識等的時候使用。

    散列分區

    當不根據範圍和值，隨機分配表領域的時候使用。「散列」就是經過「MD5」和「SHA-1」等算法從某個值生成特定的值的算法。在Oracle內部經過散列算法生成值，並根據值分配表領域。當存放的值不必定的場合使用此方法。

    TIPS  綜合分區

    Oracle中有多種分區方法，咱們還可使用「範圍、列表分區」等兩種分區方法組合在一塊兒的「綜合分區」。

    選擇了綜合分區以後，在分區設定欄的下邊會顯示叫「子分區」的設定欄。在子分區中能夠指定值和表領域。

    可是，綜合分區的方法在Oracle8i之前的版本不能使用。9i和10g的版本只能夠選擇「範圍、列表分區」或者「範圍、散列分區」。11g沒有限制 了，可是散列只能夠做爲子分區設定，例如，是不能設定「散列、列表分區」方法的。因此如今能夠設定的分區方式有6種，如下是能夠組合的分區方式（橫列是子 分區）。

	列表	列表	散列
範圍	11g~	9i~	9i~
列表	11g~	11g~	11g~

 

    以上就是使用OB進行的簡單的性能優化的方法。要進行性能優化還有一些其餘的方法，例如使用存儲過程或者是物化視圖。首先請先試試上面的方法吧。