Search <book_title>...

Storage Foundation for Oracle® RAC 7.3.1 Administrator's Guide - Linux

Last Published: 2018-01-16

Product(s): InfoScale & Storage Foundation (7.3.1)

Section I. SF Oracle RAC concepts and administration
1. Overview of Storage Foundation for Oracle RAC
2. Administering SF Oracle RAC and its components
Section II. Performance and troubleshooting
Section III. Reference
1. Appendix A. List of SF Oracle RAC health checks
2. Appendix B. Error messages

LLT health checks

This section lists the health checks performed for LLT, the messages displayed for each check, and a brief description of the check.

Note:

Warning messages indicate issues in the components or the general health of the cluster. Follow the troubleshooting recommendations to resolve the issues.

See Troubleshooting LLT health check warning messages.

Table: List of health checks for LLT lists the health checks performed for LLT.

Table: List of health checks for LLT

List of health checks	Message	Description
LLT timer subsystem scheduling check	*Warning: OS timer is not called for num* seconds**	Checks whether the LLT module runs in accordance with the scheduled operating system timer. The message indicates that the operating system timer is not called for the specified interval. The parameter timer_threshold contains the optimum threshold for this check.
OS memory availability check for the packet transmission	*Warning: Kernel failed to allocate memory num* time(s)**	Checks whether the kernel has allocated sufficient memory to LLT for cluster communication. The message indicates that the kernel attempts at allocating the requisite memory has failed (num) times. The parameter no_mem_to_xmit_allow contains the optimum threshold for this check.
Flow control status monitoring	Flow-control occurred num time(s)and back-enabled num time(s) on port port number for node node number	Checks whether LLT has sufficient bandwidth to accept incoming data packets and transmit the data packets. Flow control also depends on the peer nodes' ability to accept incoming data traffic. The message indicates that packet transmission and reception was controlled (num) and normalized (num) times. The parameter max_canput contains the optimum threshold for this check.
Flaky link monitoring	*Warning: Connectivity with node node id* on link link id is flaky num time(s). The distribution is: (0-4 s) <num> (4-8 s) <num> (8-12 s) <num> (12-16 s) <num> (>=16 s)**	Checks whether the private interconnects are stable. The message indicates that connectivity (link) with the peer node (node id) is monitored (num) times within a stipulated duration (for example, 0-4 seconds). The parameter flakylink_allow contains the optimum threshold for this check.
Node status check	*One or more link connectivity with peer node(s) node name* is in trouble.**	Checks the current node membership. The message indicates connectivity issues with the peer node (node name). This check does not require a threshold.
Link status check	*Link connectivity with node name* is on only one link. Veritas recommends configuring a minimum of 2 links.**	Checks the number of private interconnects that are currently active. The message indicates that only one private interconnect exists or is operational between the local node and the peer node node id. This check does not require a threshold.
Connectivity check	Only one link is configured under LLT. Veritas recommends configuring a minimum of 2 links.	Checks the number of private interconnects that were configured under LLT during configuration. The message indicates that only one private interconnect exists or is configured under LLT. This check does not require a threshold.
LLT packet related checks	Retransmitted % percentage of total transmitted packets. Sent % percentage of total transmitted packet when no link is up. % percentage of total received packets are with bad checksum. % percentage of total received packets are out of window. % percentage of total received packets are misaligned.	Checks whether the data packets transmitted by LLT reach peer nodes without any error. If there is an error in packet transmission, it indicates an error in the private interconnects. The message indicates the percentage of data packets transmitted or received and the associated transmission errors, such as bad checksum and failed link. The following parameters contain the optimum thresholds for this check: retrans_pct, send_nolinkup_pct, recv_oow_pct, recv_misaligned_pct, recv_badcksum_pct
DLPI layer related checks	% percentage of total received packets are with DLPI error.	Checks whether the data link layer (DLP) is causing errors in packet transmission. The message indicates that some of the received packets (%) contain DLPI error. You can set a desired percentage value in the configuration file. The parameter recv_dlpierror_pct contains the optimum threshold for this check.
Traffic distribution over the links	Traffic distribution over links: %% Send data on linknum percentage %% Recv data on linknum percentage	Checks the distribution of traffic over all the links configured under LLT. The message displays the percentage of data (%) sent and recd on a particular link (num) This check does not require a threshold.
LLT Ports status check	**% per of total transmitted packets are with large xmit latency (>16ms) for port port id %per received packets are with large recv latency (>16ms) for port port id**.	Checks the latency period for transmitting or receiving packets. The message indicates that some percentage (%) of the transmitted/received packets exceed the stipulated latency time. The following parameters contain the optimum thresholds for this check: hirecvlatencycnt_pct, hixmitlatencycnt_pct.
System load monitoring	Load Information: Average : num,num,num	Monitors the system workload at the stipulated periodicity (1 second, 5 seconds, 15 seconds) This check does not require a threshold.