Storage Foundation for Oracle® RAC 7.4.1 Administrator's Guide - Linux
- Section I. SF Oracle RAC concepts and administration
- Overview of Storage Foundation for Oracle RAC
- About Storage Foundation for Oracle RAC
- Component products and processes of SF Oracle RAC
- About Virtual Business Services
- Administering SF Oracle RAC and its components
- Administering SF Oracle RAC
- Starting or stopping SF Oracle RAC on each node
- Administering VCS
- Administering I/O fencing
- About the vxfentsthdw utility
- Testing the coordinator disk group using the -c option of vxfentsthdw
- About the vxfenadm utility
- About the vxfenclearpre utility
- About the vxfenswap utility
- Administering the CP server
- Administering CFS
- Administering CVM
- Changing the CVM master manually
- Administering Flexible Storage Sharing
- Backing up and restoring disk group configuration data
- Administering SF Oracle RAC global clusters
- Administering SF Oracle RAC
- Overview of Storage Foundation for Oracle RAC
- Section II. Performance and troubleshooting
- Troubleshooting SF Oracle RAC
- About troubleshooting SF Oracle RAC
- Troubleshooting I/O fencing
- Fencing startup reports preexisting split-brain
- Troubleshooting CP server
- Troubleshooting server-based fencing on the SF Oracle RAC cluster nodes
- Issues during online migration of coordination points
- Troubleshooting Cluster Volume Manager in SF Oracle RAC clusters
- Troubleshooting CFS
- Troubleshooting interconnects
- Troubleshooting Oracle
- Troubleshooting ODM in SF Oracle RAC clusters
- Prevention and recovery strategies
- Tunable parameters
- Troubleshooting SF Oracle RAC
- Section III. Reference
VCS message logging
VCS generates two types of logs: the engine log and the agent log. Log file names are appended by letters; letter A indicates the first log file, B the second, and C the third. After three files, the least recent file is removed and another file is created. For example, if engine_A.log is filled to its capacity, it is renamed as engine_B.log and the engine_B.log is renamed as engine_C.log. In this example, the least recent file is engine_C.log and therefore it is removed. You can update the size of the log file using the LogSize cluster level attribute.
The engine log is located at /var/VRTSvcs/log/engine_A.log. The format of engine log messages is:
Timestamp (Year/MM/DD) | Mnemonic | Severity | UMI | Message Text
Timestamp: the date and time the message was generated.
Mnemonic: the string ID that represents the product (for example, VCS).
Severity: levels include CRITICAL, ERROR, WARNING, NOTICE, and INFO (most to least severe, respectively).
UMI: a unique message ID.
Message Text: the actual message generated by VCS.
A typical engine log resembles:
2011/07/10 16:08:09 VCS INFO V-16-1-10077 Received new cluster membership
The agent log is located at /var/VRTSvcs/log/<agent>.log
. The format of agent log messages resembles:
Timestamp (Year/MM/DD) | Mnemonic | Severity | UMI | Agent Type | Resource Name | Entry Point | Message Text
A typical agent log resembles:
2011/07/10 10:38:23 VCS WARNING V-16-2-23331 Oracle:VRT:monitor:Open for ora_lgwr failed, setting cookie to null.
Note that the logs on all nodes may not be identical because
VCS logs local events on the local nodes.
All nodes may not be running when an event occurs.
VCS prints the warning and error messages to STDERR.
If the VCS engine, Command Server, or any of the VCS agents encounter some problem, then First Failure Data Capture (FFDC) logs are generated and dumped along with other core dumps and stack traces to the following location:
For VCS engine:
$VCS_DIAG/diag/had
For Command Server:
$VCS_DIAG/diag/CmdServer
For VCS agents:
$VCS_DIAG/diag/agents/type
, where type represents the specific agent type.
The default value for variable $VCS_DIAG is /var/VRTSvcs/
.
If the debug logging is not turned on, these FFDC logs are useful to analyze the issues that require professional support.