Oracle性能調優之超越表面分析法

    從基於命中率的優化方法轉向基於等待事件的優化方法，顯著地提升了我們診斷和oracle優化應用的能力。然而正如前面提到的，一味關注響應時間長的組件，可能導致下面幾個不良後果。
    1、治標不治本。
    2、更傾向於選擇硬件方案，而非更划算的調整配置或應用。
    3、只顧眼前，忽視長遠及可擴展能力。
    爲了規避基於等待事件調優的隱患.需要明確幾個階段。這幾個階段是由應用、數據庫、操作系統的交互方式決定。總體來看，數據庫進程按照下面幾個層次運行。
    (I)應用以SQL語句的形式向數據庫發出請求(包含PL/SQL請求)。數據庫響應這些請求。並返回對應的返回碼與結果集。
    (2)爲了處理應用請求，數據庫必須解析這條SQL語句。在最終執行它之前，還需要完成多個額外操作(安全、調度及事務管理)。這些操作要用到操作系統資源(CPU和內存)，可能會受併發執行的數據庫會話之間爭用的限制。
    (3)最後，這些數據庫請求還需要處理(創建、閱讀或變更)數據庫中的部分數據。需要處理的確切數據量要視數據庫設計(例如索引設計)和應用(例如SQL語句類別)而定。
    內存中會有部分被請求數據。這些數據塊出現在內存中的概率主要由其中的數據被訪問的頻率以及可用來緩存數據塊的內存總量決定。在內存中訪問數據庫數據的行爲被稱爲邏輯I0。此外，執行排序和散列操作也需要使用內存。
    (4)如果數據塊不在內存中，就必須到磁盤上讀取，從而導致物理IO操作。物理IO是到目前爲止所有操作中代價最高的.因此數據庫會盡量避免不必要的舊操作。然而.有些磁盤讀寫是無法避免的。在排序和散列操作太大而不能在內存中完成時，也會發生磁盤10,
    以上每一層的活動都會影響對下一層的請求。例如，提交一條SQL語句由於某種原因不能有效利用索引，就需要執行大量的邏輯讀操作，而這又將導致爭用並最終引發大量的物理舊操作。看到如此大量的IO操作或爭用時.你常常會忍不住用優化磁盤佈局的方法直接清除這個症狀。不過，如果按照層級的順序來安排調優工作，更有可能抓住問題的根本，並在更低層級上化解性能問題。