Introduction to 11GR2 Agent

Introduction to 11GR2 Agent by Allen gao-oracle on June

# #转自Oracle官方博客

Objective: This paper introduces the new characteristic agent of Oracle 11GR2 cluster (Grid infrastructure, hereinafter referred to as GI), including the function of agent, the introduction of common agent, and the basic method of diagnosis.

Applicable scope: 11.2.0.1 and above version.

First of all, we introduce the method of 10GR2 CRS management resources briefly. In 10gr2, CRSD is responsible for managing the resources in the cluster. Specifically, CRSD invokes the associated RACG script, generating RACG processes to manage resources, such as RACGVIP scripts to manage VIP resources. This management approach, because it is the RACG process for the operation of resources, sometimes there are some problems. Starting with 11gr2 GI, the agent manages all of the resources in GI as a whole new architecture that makes resource management stronger and more performance--a new agent architecture.

Next we introduce some of the characteristics of the agent.
1. Almost all resources and daemon are managed by agents. For example, GIPC, Gpnp and other OHASD produced by the Orarootagent management.
2. The agent daemon is multi-threaded and is an ha (high Available) process.
3. OHASD will produce the following agent
Cssdagent (this agent represents the resource ORA.CSSD in the command "Crsctl stat Res–t–init")
Orarootagent
Oraagent
Cssdmonitor
CRSD will produce the following agent
Orarootagent
Oraagent
User-defined agent.
Note: Users Oracle and Grid will have their respective oraagent to manage their resources. For example, Oraagent_grid manages Resources Ora.asm, Oraagent_oracle manages ORA.<DATABASE_NAME>.DB resources.

Here we introduce how the agent manages resources. First, the agent has some EP (Entry point), similar to the action that can be performed on the resource.
Start: Starting Resources
STOP: Stopping resources
Check: Checks the status of the resource, and if a resource state change is found, the agent notifies GI that the resource state has changed.
Clean: Cleans up resources, generally cleaning up resources in the event of a resource problem, requiring a reboot or failover.
Abort: Abort the resource.

When the above arbitrary EP ends, one of the following return values is returned, and the return values correspond to the state of the resource.
Online: On line. The online status of the corresponding resource
OFFLINE: Offline. The offline state of the corresponding resource. For offline states, it can be subdivided into planed offline and unplaned offline. planed offline refers to the GI tendency of this resource to be in a offline state, such as our use of GI-related tools (Srvctl, Crsctl) to stop a resource, in which case GI thinks the resource should be in a offline state, Because the operation of stopping resources is done through GI. At the same time, for planed offline resources, its target State is also modified to offline state, which means that if the target state of the resource is offline, the GI stacks is restarted unless the resource's auto_ The Start property is set to always, otherwise the resource will not be started automatically (for more information about target State, and property Auto_start, refer to Oracle online documentation Oracle CLUSTERWARE Administration and Deployment Guide 11g Release 2). For unplaned offline, it means that resources are stopped by tools other than GI, such as using Sqlplus to manually shut down the database, in which case GI does not think that the resource should be in the offline state and the target state of the resource is still online, so The resource will still be started when the GI is restarted, unless, of course, the resource's Auto_start property is set to never.
UNKNOWN: Unknown, corresponding to the UNKNOWN state of the resource. In this state, the agent continues to check the resource.
PARTIAL: Resource part online, corresponding to the intermediate state of resources. In this case, the agent will continue to check the resource and update the resource status in a timely manner.
FAILED: Failed. The return value indicates a problem with the resource and does not work properly, the agent executes the clean EP first, and then failover or restart operations based on the resource's related properties.

After that, we can see the corresponding relationship between the agent and the resource that is responsible for management by using the following table.

Finally, we briefly introduce the agent-related trace file. First, the agent's trace file is located under the path Grid_home/log/
Orarootagent log generated by Grid_home/log/
Oraagent log generated by Grid_home/log/
Cssdagent log generated by Grid_home/log/
Cssdmonitor log generated by Grid_home/log/
Grid_home/log/
Grid_home/log/
Orarootagent log generated by Grid_home/log/
In addition, the following files are also helpful for troubleshooting agent-related problems.

Cluster alert log (Grid_home/log/
Grid_home/log/
Grid_home/log/

Because each agent needs to manage multiple resources, it is more efficient to filter the agent log with problematic resource names if it is only a problem with a resource, but the agent log is very readable and is not described here in detail. Agent if crash, in general, will labor a core file (grid_home/log/