Database Reference
In-Depth Information
ocssd.log
: Cluster Synchronization Service daemon (CSSD) is undoubtedly one of the most critical components
of Clusterware, whose primary functionality includes node monitoring, group service management, lock services,
and cluster heartbeats. The process maintains a log file named
ocssd.log
under the
$GIRD_HOME/log/<hostname>/cssd
location and writes all important event messages in the log file. This is one of the busiest CRS log files and is
continuously being written; when the debug level of the process is set too high, the file tends to get more detailed
information about the underlying issue. Before the node eviction happens on the node, it writes the warning message
in the log file. If a situation such as node eviction, VD access issues, or inability of the Clusterware to start up on the
local node is raised, it is strongly recommended that you examine the file to find out the reasons.
Following are a few sample entries of the log file:
2012-11-30 10:10:49.989: [CSSD][21]clssnmvDiskKillCheck: not evicted, file /dev/rdsk/c0t5d4 flags 0x00000000,
kill block unique 0, my unique 1351280164
ocssd.l04:2012-10-26 22:17:26.750: [CSSD][6]clssnmvDiskVerify: discovered a potential voting file
ocssd.l04:2012-10-26 22:36:12.436: [CSSD][1]clssnmvDiskAvailabilityChange: voting file
/dev/rdsk/c0t5d4 now online
ocssd.l04:2012-10-26 22:36:10.440: [CSSD][1]clssnmReadDiscoveryProfile: voting file discovery
string(/dev/rdsk/c0t5d5,/dev/rdsk/c0t5d4)
2012-12-01 09:54:10.091: [CSSD][30]clssnmSendingThread: sending status msg to all nodes
ocssd.l01:2012-12-01 10:24:57.116: [CSSD][1]clssnmInitNodeDB: Initializing with OCR id 1484043234
•
[cssd(7335)]CRS-1612:Network communication with node rac2 (02) missing for 50% of
timeout interval. Removal of this node from cluster in 14.397 seconds2013-03-15 17:02:44.964
•
[cssd(7335)]CRS-1611:Network communication with node rac2 (02) missing for 75% of
timeout interval. Removal of this node from cluster in 7.317 seconds2013-03-15 17:02:50.024
•
[cssd(7335)]CRS-1610:Network communication with node rac2 (02) missing for 90% of
timeout interval. Removal of this node from cluster in
Oracle certainly doesn't recommend removing the log file manually for any reason, as it is governed by Oracle
automatically. Upon reaching a size of 50 MB, the file will be automatically archived as
cssd.l01
in the same location
as part of the predefined rotation policy, and a fresh log file (
cssd.log
) will be generated. There will be ten archived
copies kept for future reference in the same directory as part of the built-in log rotation policy and ten-times-ten file
retention formula.
When the log file is removed before it reaches 50 MB, unlike the database alter.log file, Clusterware will not
generate a new log file instantly until the removed file reaches 50 MB. This is because despite the removal of the file
from the OS, the CSS process will be still writing the messages to the file until the file becomes a candidate for the
rotation policy. When the removed file reaches a size of 50 MB, a new log file will appear or be generated and will be
available in this way. However, the previous messages won't be able to recall in this context.
When the CSSD fails to start up, or it is reported to be unhealthy, this file can be referred to ascertain the root
cause of the problem.
crsd.log
: CRSD is another critical component of Clusterware whose primary functionality includes resource
monitoring, resource failover, and managing OCR. The process maintains a log file named
crsd.log
under the
$GIRD_HOME/log/<hostname>/crsd
location and writes all important event messages in the log file. Whenever a
cluster or non-cluster resource stops or starts, or a failover action is performed, or any resource-related warning
message or communication error occurs, the relevant information is written to the file. In case you face issues like
failure of starting resources, the DBA can examine the file to get relevant information that could assist in a resolution
of the issue.
Deleting the log file manually is not recommended, as it is governed by Oracle and archived automatically. The
file will be archived as
crsd.l01
under the same location on reaching a size of 10 MB, and a fresh log file (
crsd.log
)
will be generated. There will be ten archived copies kept for future reference in the same directory.
