Measures reported by TibSpinTest

Latches are mechanisms for protecting and managing SGA data structures and database objects being accessed concurrently. Unlike locks, latches provide exclusive access to protected data structures. Requests for latches are not queued. So, if a request fails, the requesting process may try later. Typically, latches are used to protect resources that are briefly needed.

A Tibero process can request a latch in one of the following two modes:

• Willing-to-Wait Mode: If the requested latch is not immediately available, the process will wait. When an attempt to get a latch in a willing-to-wait mode fails, the process will spin and try again. If the number of attempts reaches the value of the SPIN_COUNT parameter, the process sleeps. Sleeping is more expensive than spinning.
• Immediate Mode (no-wait mode): In this case, the process will not wait if the requested latch is not available and it continues its processing.

Latch contention has a significant impact on performance when:

• Enough latches are not available
• A latch is held for a relatively long time

Latch mechanisms most likely to suffer from contention involve requests to write data into the redo log buffer. To serve the intended purpose, writes to the redo log buffer must be serialized. There are four different groupings applicable to redo buffer latches: redo allocation latches and redo copy latches, each with immediate and willing-to-wait priorities.

The TibSpinTest test is used to monitor latches in a Tibero database server.

Outputs of the test : One set of results for each target database server being monitored.

The measures made by this test are as follows: