11gR2 Agent 简介

目的:本文会对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)。


原文链接:https://blogs.oracle.com/Database4CN/entry/11gr2_agent_%E7%AE%80%E4%BB%8B


你可能感兴趣的:(oracle,demo,CRS)