11gR2 Agent 簡介

11gR2 Agent 簡介  By Allen Gao-Oracle on 六月 15, 2012

##轉自Oracle官方部落格

目的：本文會對oracle 11gR2 叢集件(Grid Infrastructure,以下簡稱GI) 新特性 agent進行介紹，包括 agent的功能，常見的agent介紹，以及基本的診斷方法。

適用範圍：11.2.0.1及以上版本。

    首先我們對10gR2 crs 管理資源的方法進行簡單的介紹。在10gR2 當中，crsd 負責對叢集中的資源進行管理。具體說來，crsd 調用相關的racg指令碼，產生racg進程對資源進行管理，例如racgvip 指令碼用來管理vip資源。這種管理辦法，由於是racg進程進行對資源的操作，有時候會存在一些問題。從11gR2 GI開始, agent 作為一個全新的架構對GI中所有的資源進行管理，這種全新的agent 架構使資源管理更加強壯，效能更好。

    接下來我們對agent的特點進行一些介紹。
1．幾乎所有的資源和daemon都是由agent 管理的。例如gipc, gpnp等 由ohasd 產生的orarootagent管理。
2．Agent守護進程是多線程的，而且是HA（High Available）進程.
3．Ohasd 會產生下面的agent
        cssdagent（這個agent代表命令“crsctl stat res –t –init” 中的資源ora.cssd ）
        orarootagent
        oraagent
        cssdmonitor
    Crsd 會產生下面的agent
        orarootagent
        Oraagent
        使用者自訂的agent.
注意：使用者oracle和grid都會產生各自對應的oraagent來管理各自的資源。例如 oraagent_grid管理資源ora.asm， oraagent_oracle管理ora.<database_name>.db資源。 

    下面我們對agent如何管理資源進行介紹。首先，agent 擁有一些EP(Entry Point)，類似於可以對資源執行的動作。
       Start：啟動資源
       Stop：停止資源
       Check：檢查資源的狀態，如果發現了資源狀態改變，則agent會通知GI，資源狀態發生了改變。
       Clean：清理資源，一般來說清理資源會在資源存在問題，需要重新啟動或failover之前發生。
       Abort：中止資源。

    當以上的任意EP結束之後，會返回以下傳回值中的一個，而這些傳回值也對應著資源的狀態。
       ONLINE：線上。對應資源的online狀態
       OFFLINE：離線。對應資源的offline狀態。對於offline狀態，可以細分為planed offline 和unplaned offline。Planed offline是指GI傾向於這個資源處在offline狀態，例如我們使用GI相關的工具（srvctl, crsctl）停止了一個資源，這種情況，GI就認為資源應該處於offline狀態，因為停止資源的操作是通過GI來實現的。同時，對於planed offline的資源，它的target狀態也會被修改為offline狀態，這意味著，如果在資源的target狀態為offline時重啟GI stacks，除非資源的auto_start屬性設定為always，否則，該資源不會被自動啟動（關於target狀態，和屬性auto_start的更多資訊，請參考oracle聯機文檔Oracle Clusterware Administration and Deployment Guide 11g Release 2）。對於unplaned offline,是指資源被GI以外的工具停止，例如使用sqlplus手動關閉資料庫，在這種情況下，GI並不認為該資源應該處於offline狀態，資源的target狀態仍然為online,所以，資源在重新啟動GI時仍然會被啟動，當然除非資源的auto_start屬性設定為never。
       UNKNOWN：未知，對應資源的unknown狀態。在這種狀態下，agent會繼續對該資源進行check。
       PARTIAL：資源部分線上，對應資源的intermediate狀態。 在這種情況下agent會繼續對該資源進行check，並及時更新資源狀態。
       FAILED：失敗。該傳回值說明資源存在問題，不能正常工作，agent會首先執行clean EP，之後根據資源的相關屬性進行failover或restart操作。

    之後，我們可以通過下面這張表格瞭解agent與負責管理的資源的對應關係。

    最後，我們對agent相關的trace檔案進行簡單的介紹。首先,agent的trace 檔案位於路徑GRID_HOME/log/<host>/agent下，以下是比較詳細的資訊。

            GRID_HOME/log/<host>/agent /ohasd/orarootagent_root  <– ohasd產生的orarootagent日誌

            GRID_HOME/log/<host>/agent/ohasd/oraagent_grid  <– ohasd產生的oraagent日誌

            GRID_HOME/log/<host>/agent/ohasd/oracssdagent_root  <– ohasd產生的cssdagent日誌

            GRID_HOME/log/<host>/agent/ohasd/oracssdmonitor_root  <– ohasd產生的cssdmonitor日誌

            GRID_HOME/log/<host>/agent/crsd/oraagent_grid  <– crsd產生的oraagent日誌,owner為grid

            GRID_HOME/log/<host>/agent/crsd/oraagent_oracle  <– crsd產生的oraagent日誌,owner為oracle

            GRID_HOME/log/<host>/agent/crsd/orarootagent_root  <–crsd產生的orarootagent日誌

    另外,以下的檔案對診斷agent相關的問題也很有協助。

            叢集alert log(Grid_home/log/<hostname>/alert<hostname>.log)

            Grid_home/log/<hostname>/ohasd/ohasd.log

            Grid_home/log/<hostname>/crsd/crsd.log


    由於每個agent需要管理多個資源，所以，如果只是某一個資源存在問題，可以使用有問題的資源名稱過濾agent日誌會更有效率，當然Agent日誌的可讀性很好，在這裡不進行詳細的介紹。Agent如果crash，一般情況下，會產程一個core檔案（Grid_home/log/<hostname>/agent/{ohasd|crsd}/<agent名>_<使用者名稱>）和對應的堆棧檔案（Grid_home/log/<hostname>/agent/{ohasd|crsd}/<agent名>_<使用者名稱>/<agent名>_<使用者名稱>OUT.log）。