oracle 性能優化 03_閂鎖及33等待事件

1、閂鎖
一、oracle的鎖
    應用級鎖：應用中對錶等資源進行鎖定，保證業務邏輯正確性，v$lock視圖，鎖詳細見體系結構介紹
    數據字典鎖：Oracle RDBMS內核程序員使用的用來保證數據字典訪問邏輯正確性的鎖
    內存控制鎖：用來保護Oracle內部數據結構的鎖（LATCH,MUTEX）
二、內存控制鎖
latch
    經過簡單高效的底層技術，保護oracle內存結構，保證oracle串行的訪問核心內存，不使用隊列機
制，一個latch能夠保護多個內存區域，一個內存區域只能由一個latch保護。latch時間開銷包括獲取
latch,持有，釋放三部分時間，能夠經過v$latch,v$latch_children視圖或者statpack,AWR報告發現閂
鎖等待。
mutex
    oracle10g引入，用於保存部份內存結構，比latch保護的粒度更小，開銷也小。
    
2、等待事件：
    分爲兩類，即空閒(IDLE)等待事件和非空閒(NON-IDLE)等待事件。
    空閒等待事件指ORACLE正等待某種工做，在診斷和優化數據庫的時候，不用過多注意這部分事件。
    非空閒等待事件專門針對ORACLE的活動，指數據庫任務或應用運行過程當中發生的等待，這些等待事件
是調優數據庫的時候須要關注與研究的。
    在Oracle 10g中的等待事件有872個，11g中等待事件1365個。v$event_name 視圖可查看等待事件的相關信息。
    查看等待事件分類狀況：
    SELECT   wait_class#,
           wait_class_id,
           wait_class,
           COUNT ( * ) AS "count"
    FROM   v$event_name
    GROUP BY   wait_class#, wait_class_id, wait_class;
12類等待事件
    IDLE #空閒
    APPLICATION #行鎖、表鎖、DDL鎖等
    Configuration #因爲配置致使的
    Administrative #特權用戶的某些維護操做致使的
    Concurrency #因爲併發量大引發的
    commit #log file sync
    Network
    User I/O waits #前臺進程，SMON,MMON
    System I/O Waits #除了SMON,MMON外的後臺進程
    Scheduler #資源管理引發的
    CLUSTER #RAC
    Other                           
3、33個常見的等待事件
1.Buffer busy waits
    發生這個等待事件說明了一個會話在等待一個Buffer（數據塊），常見的兩種是：本會話要修改的數據塊被其餘會話
正修改，本會話要讀取的數據庫被其餘會話讀入內存。Oracle 操做的最小單位是塊（Block），即便你要修改一條記錄，
也須要對這條記錄所在的這個數據塊作操做。 當你對這個數據塊作修改時會在數據塊上加鎖，其餘的會話將被阻止對這
個數據塊上的數據作修改（即便其餘用戶修改的不是當前用戶修改的數據），能夠利用CR塊實現一致性讀。這種加鎖的機
制咱們叫Latch。
    會話修改一個數據塊的步驟：以排他的方式得到這個數據塊（Latch），修改這個數據塊，釋放Latch。
    Buffer busy waits等待事件常見於數據庫中存在的熱塊，能夠在AWR或者statspack 報告中就能夠看到。經過SQL語
句查找x$bh視圖，找到具體的熱塊，進行優化處理。

2.Buffer  latch
    當一個會話須要訪問某個數據塊時，它首先要搜索記錄buffer地址 hash 列表，從列表中得到數據塊的地址，而後通
過這個地址去訪問須要的數據塊，這個列表Oracle會使用一個latch來保護它的完整性。 訪問這個列表時，須要獲取一個
Latch。
    產生buffer latch的等待事件的主要緣由是：
    Buffer chains太長，致使會話搜索這個列表花費的時間太長，使其餘的會話處於等待狀態；存在熱塊問題。
    _db_block_lru_latches: lru buffer chain的個數
    SELECT x.ksppinm NAME, y.ksppstvl VALUE, x.ksppdesc describ
    FROM x$ksppi x, x$ksppcv y
    WHERE x.inst_id = USERENV ('Instance')
    AND y.inst_id = USERENV ('Instance')
    AND x.indx = y.indx
    AND x.ksppinm LIKE '%_db_block_lru_latches%' 

3.Control file parallel write
    當數據庫中有多個控制文件的拷貝時，Oracle 須要保證信息同步地寫到各個控制文件當中，這是一個並行的物理
操做過程，由於稱爲控制文件並行寫，當發生這樣的操做時，就會產生control file parallel write等待事件。事件
發生後能夠下降控制文件的拷貝數量，將控制文件的拷貝存放在不一樣的物理磁盤上的方式來緩解I/O 爭用。
    控制文件頻繁寫入的緣由： 日誌切換太過頻繁，致使控制文件信息相應地須要頻繁更新。

4.Control file sequential read
    當數據庫須要讀取控制文件上的信息時，會出現這個等待事件，由於控制文件的信息是順序寫的，因此讀取的時
候也是順序的，所以稱爲控制文件順序讀，它常常發生在如下狀況： 備份控制文件，讀取控制文件信息，RAC 環境下
不一樣實例之間控制文件的信息共享。
5.Db file parallel read
    這個等待事件和並行操做（好比並行查詢，並行DML）沒有關係。 這個事件發生在數據庫恢復的時候，當有一些
數據塊須要恢復的時候，Oracle會以並行的方式把他們從數據文件中讀入到內存中進行恢復操做。
6.Db file parallel write
    這是一個後臺等待事件，它一樣和用戶的並行操做沒有關係，它是由後臺進程DBWR產生的，當後臺進程DBWR想磁
盤上寫入髒數據時，會發生這個等待。
    DBWR會批量地將髒數據並行地寫入到磁盤上相應的數據文件中，在這個批次做業完成以前，DBWR將出現這個等待
事件。 若是僅僅是這一個等待事件，對用戶的操做並無太大的影響，當伴隨着出現free buffer waits等待事件時，
說明此時內存中可用的空間不足，這時候會影響到用戶的操做，好比影響到用戶將髒數據塊讀入到內存中。
7.Db file scattered read
    這個等待事件在實際生產庫中常常能夠看到，這是一個用戶操做引發的等待事件，當用戶發出每次I/O須要讀取
多個數據塊這樣的SQL 操做時，會產生這個等待事件，最多見的兩種狀況是全表掃描（FTS： Full Table Scan）和索
引快速掃描（IFFS： index fast full scan）。
    當發生這種等待事件時，SQL的操做都是順序地讀取數據塊的，好比FTS或者IFFS方式（若是忽略須要讀取的數據
塊已經存在內存中的狀況）。這裏的scattered指的是讀取的數據塊在內存中的存放方式，他們被讀取到內存中後，是
以分散的方式存在在內存中，而不是連續的。
8.Db file sequential read
    這個等待事件在實際生產庫也很常見，當Oracle 須要每次I/O只讀取單個數據塊這樣的操做時，會產生這個等待
事件。 最多見的狀況有索引的訪問（除IFFS外的方式），回滾操做，以ROWID的方式訪問表中的數據，重建控制文件，
對文件頭作DUMP等。
    這裏的sequential指的是讀取的數據塊在內存中是以連續的方式存放的。
9.Db file single write
    這個等待事件一般只發生在一種狀況下，就是Oracle 更新數據文件頭信息時（好比發生Checkpoint）。當這個等
待事件很明顯時，須要考慮是否是數據庫中的數據文件數量太大，致使Oracle 須要花較長的時間來作全部文件頭的更
新操做（checkpoint）。
10.Direct path read
    這個等待事件發生在會話將數據塊直接讀取到PGA當中而不是SGA中的狀況，這些被讀取的數據一般是這個會話私
有的數據，因此不須要放到SGA做爲共享數據，由於這樣作沒有意義。這些數據一般是來自與臨時段上的數據，好比一
個會話中SQL的排序數據，並行執行過程當中間產生的數據，以及Hash Join，merge join產生的排序數據，由於這些
數據只對當前的會話的SQL操做有意義，因此不須要放到SGA當中。
    當發生direct path read等待事件時，意味着磁盤上有大量的臨時數據產生，好比排序，並行執行等操做。 或
者意味着PGA中空閒空間不足。
11.Direct path write
    這個等待事件和direct path read 正好相反，是會話將一些數據從PGA中直接寫入到磁盤文件上，而不通過SGA。
這種狀況一般發生在：使用臨時表空間排序（內存不足），數據的直接加載（使用append方式加載數據）並行DML操做。
12.Enqueue
    Enqueue 這個詞實際上是lock 的另外一種描述語。關聯AWR報告中的enqueue activity部分來肯定是哪種鎖定出
現了長時間等待。
    可使用以下SQL 查看當前會話等待的enqueue名稱和類型：
SELECT   CHR (TO_CHAR (BITAND (p1, -16777216)) / 16777215)
        || CHR (TO_CHAR (BITAND (p1, 16711680)) / 65535)
            "Lock",
         TO_CHAR (BITAND (p1, 65535)) "Mode"
  FROM   v$session_wait
 WHERE   event = 'enqueue'
13.Free buffer waits
    當一個會話將數據塊從磁盤讀到內存中時，它須要到內存中找到空閒的內存空間來存放這些數據塊，當內存中
沒有空閒的空間時，就會產生這個等待；除此以外，還有一種狀況就是會話在作一致性讀時，須要構造數據塊在某
個時刻的前映像（image），此時須要申請內存來存放這些新構造的數據塊，若是內存中沒法找到這樣的內存塊，
也會發生這個等待事件。
    出現比較嚴重的free buffer waits等待事件時，可能的緣由是：
        data buffer 過小，致使空閒空間不夠
        內存中的髒數據太多，DBWR沒法及時將這些髒數據寫到磁盤中以釋放空間
14.Latch free
    在10g以前的版本里，latch free 等待事件表明了全部的latch等待，在10g之後，一些經常使用的latch事件已經被
獨立了出來，因此latch free 等待事件在10g之後的版本中並不常見，而是以具體的Latch 等待事件出現。
    select name from v$event_name where name like 'latch%' order by 1;
15.Library cache lock
    這個等待時間發生在不一樣用戶在共享中因爲併發操做同一個數據庫對象致使的資源爭用的時候，好比當一個用
戶正在對一個表作DDL 操做時，其餘的用戶若是要訪問這張表，就會發生library cachelock等待事件，它要一直
等到DDL操做完成後，才能繼續操做。
16.Library cache pin
    這個等待事件和library cache lock 同樣是發生在共享池中併發操做引發的事件。一般來說，若是Oracle 要
對一些PL/SQL 或者視圖這樣的對象作從新編譯，須要將這些對象pin到共享池中。 若是此時這個對象被其餘的用戶
特有，就會產生一個library cache pin的等待。
17.Log file parallel write
    後臺進程LGWR 負責將log buffer當中的數據寫到REDO 文件中，以重用log buffer的數據。 若是每一個REDO LOG
組裏面有2個以上的成員，那麼LGWR進程會並行地將REDO 信息寫入這些文件中。
    若是數據庫中出現這個等待事件的瓶頸，主要的緣由多是磁盤I/O性能不夠或者REDO 文件的分佈致使了I/O爭
用，好比同一個組的REDO 成員文件放在相同的磁盤上。
18.Log buffer space
    當log buffer 中沒有可用空間來存放新產生的redo log數據時，就會發生log buffer space等待事件。 若是
數據庫中新產生的redo log的數量大於LGWR 寫入到磁盤中的redo log 數量，必須等待LGWR 完成寫入磁盤的操做，
LGWR必須確保redo log寫到磁盤成功以後，才能在redo buffer當中重用這部分信息。
19.Log file sequential read
    這個等待事件一般發生在對redo log信息進行讀取時，好比在線redo 的歸檔操做，ARCH進程須要讀取redo log
的信息，因爲redo log的信息是順序寫入的，因此在讀取時也是按照順序的方式來讀取的。
20.Log file single write
    這個等待事件發生在更新redo log文件的文件頭時，當爲日誌組增長新的日誌成員時或者redo log的sequence號
改變時，LGWR 都會更新redo log文件頭信息。
21.Log file switch(archiving needed)
   在歸檔模式下，這個等待事件發生在在線日誌切換（log file switch）時，須要切換的在線日誌尚未被歸檔進
程（ARCH）歸檔完畢的時候。當在線日誌文件切換到下一個日誌時，須要確保下一個日誌文件已經被歸檔進程歸檔完
畢，不然不容許覆蓋那個在線日誌信息（不然會致使歸檔日誌信息不完整）。
   出現這樣的等待事件一般是因爲某種緣由致使ARCH 進程死掉，若是發生這種狀況，在數據庫的alert log文件中
能夠找到相關的錯誤信息。
22.Log file switch(checkpoint incomplete)
    當一個在線日誌切換到下一個在線日誌時，必須保證要切換到的在線日誌上的記錄的信息（好比一些髒數據塊產
生的redo log）被寫到磁盤上（checkpoint），這樣作的緣由是，若是一個在線日誌文件的信息被覆蓋，而依賴這些
redo 信息作恢復的數據塊還沒有被寫到磁盤上（checkpoint），此時系統down掉的話，Oracle將沒有辦法進行實例恢復。
    若是系統中出現大量的log file switch（checkpoint incomplete）等待事件，緣由多是日誌文件過小或者日
志組太少，因此解決的方法是，增長日誌文件的大小或者增長日誌組的數量。
23.Log file sync
    這是一個用戶會話行爲致使的等待事件，當一個會話發出一個commit命令時，LGWR進程會將這個事務產生的
redo log從log buffer裏面寫到磁盤上，以確保用戶提交的信息被安全地記錄到數據庫中。
    會話發出的commit指令後，須要等待LGWR將這個事務產生的redo 成功寫入到磁盤以後，才能夠繼續進行後續的操
做，這個等待事件就叫做log file sync。當系統中出現大量的log file sync等待事件時，應該檢查數據庫中是否有
用戶在作頻繁的提交操做。
24.SQL*Net break/reset to client
    當出現這個等待事件時，說明服務器端在給客戶端發送一個斷開鏈接或者重置鏈接的請求，正在等待客戶的響
應，一般的緣由是服務器到客戶端的網絡不穩定致使的。
25.SQL*Net break/reset to dblink
    這個等待事件和SQL*Net break/reset to client 相同。 不過它表示的是數據庫經過dblink訪問另外一臺數據庫
時，他們之間創建起一個會話，這個等待事件發生在這個會話之間的通訊過程當中，一樣若是出現這個等待事件，需
要檢查兩臺數據庫之間的通訊問題。
26.SQL*Net message from client
    這個等待事件基本上是最多見的一個等待事件。 當一個會話創建成功後，客戶端會向服務器端發送請求，服務器
端處理完客戶端請求後，將結果返回給客戶端，並繼續等待客戶端的請求，這時候會產生SQL*Net message from client
等待事件。
    這是一個空閒等待，若是客戶端再也不向服務器端發送請求，服務器端將一直處於這個等待事件狀態。
27.SQL*Net message from dblink
    這個等待事件和SQL*Net message from client相同，不過它表示的是數據庫經過dblink 訪問另外一個數據庫時，
他們之間會創建一個會話，這個等待事件發生在這個會話之間的通訊過程當中。
    這個等待事件也是一個空閒等待事件。
28.SQL*Net message to client
    這個等待事件發生在服務器端向客戶端發送消息的時候。 當服務器端向客戶端發送消息產生等待時，可能的
緣由是用戶端太繁忙，沒法及時接收服務器端送來的消息，也多是網絡問題致使消息沒法從服務器端發送到客戶端。
29.SQL*Net message to dblink
    這個等待事件和SQL*Net message to client 相同，不過是發生在數據庫服務器和服務器之間的等待事件，
產生這個等待的緣由多是遠程服務器繁忙，而沒法及時接收發送過來的消息，也多是服務器之間網絡問題致使
消息沒法發送過來。
30.SQL*Net more data from client
    服務器端等待用戶發出更多的數據以便完成操做，好比一個大的SQL文本，致使一個SQL*Net 數據包沒法完成
傳輸，這樣服務器端會等待客戶端把整個SQL 文本發過來在作處理，這時候就會產生一個SQL*Net more data from client 
等待事件。
31.SQL*Net more data from dblink
   在一個分佈式事務中，SQL 分佈在不一樣的數據庫中執行，遠程數據庫執行完畢後將結果經過dblink返給發出SQL的
數據庫，在等待數據從其餘數據庫中經過dblink傳回的過程當中，若是數據在遠程數據庫上處理時間好久，或者有大量
的結果集須要返回，或者網絡性能問題都會產生SQL*Net more data from dblink 等待事件，它的意思是本地數據庫
須要等到全部的數據從遠程處理完畢經過dblink傳回後，才能夠在本機繼續執行操做。
32.SQL*Net more data to client
    當服務器端有太多的數據須要發給客戶端時，可能會產生SQL*Net more data to client等待事件，也可能因爲
網絡問題致使服務器沒法及時地將信息或者處理結果發送給客戶端，一樣會產生這個等待。
33. SQL*Net more data to dblink
    這個等待事件和SQL*Net more data to client 等待時間基本相同，只不過等待發生在分佈式事務中，即本地數
據庫須要將更多的數據經過dblink發送給遠程數據庫。因爲發送的數據太多或者網絡性能問題，就會出現
SQL*Net more data to dblink等待事件。

參考資料：
http://www.2cto.com/database/201110/107267.html