UniVerse Database Active Group Locks Test

UniVerse stores its data in containers known as Files. Static and Dynamic files are the most common files in a UniVerse database. Both static and dynamic files consist of a number of separate storage sections, known as buffers. The size and number of these buffers is specified when the file is created, and space is reserved for these on disk. This is known as the 'primary space' of the file. As records are added to the file, UniVerse distributes the records across this primary space using a scattering formula based on the record keys. This formula produces the address of the buffer in which the record should be placed. If a buffer in a file becomes full, and another record is added to the file that is addressed to the same buffer, the file is said to be 'overflowed'. It cannot use a different buffer to hold the record, since this would break the allocation scheme. Instead it will extend the file by chaining an additional buffer to the end of the first buffer – and so on, so that more records are added to the file. The chain of buffers attached to a specific buffer in the primary space, is known as a 'group'.

When a process needs to read or write a record to or from a file, UniVerse first works out which group should hold the record to be written or holds the record to be read in the primary space by applying the relevant hashing algorithm to the record key. Because the group structure can hold more than one record, UniVerse needs to ensure that only one process at a time can read from, or update an individual group. This prevents one process trying to scan through a group whilst another process is busy reorganizing it. So it then proceeds to place a lock entry for that group into the lock table. Because the lock specifies both the file and the group within the file, this does not prevent another UniVerse process from accessing a different group in the same file at the same time. So different processes can still read and write a single file safely.

If a file is well sized and records are distributed across the primary space, it should be very rare that two processes will need access to the same part of the file at the same time, and so there will be few collisions within the group lock table. If a file is badly sized and records are consigned to long overflow chains of buffers belonging to the same group, the chances of more than one process needing access to the same group are much higher – and so the collisions are much higher. And the longer the chains, the longer the time that each lock needs to be held. All of which means that more processes will spend longer queuing up and waiting for the lock to become available.

This is why, if a processing slowdown is noticed in a UniVerse database, administrators should first check whether too many group locks are currently active in the database, and identify the mode of these locks. This is where the UniVerse Database Active Group Locks test helps. For each lock mode, this test reveals the number of active group locks in that mode. The detailed diagnostics provided by this test provide deep insights into these locks, and in the process, enables administrators to figure out:

• Which processes are holding what type of lock?
• Which process is holding a lock on which group of which file?

With the help of these details, administrators can identify processes that are unnecessarily holding a lock, and can unlock the files and groups so locked, so as to ease processing.

Target of the Test: A UniVerse database server

Agent running the test: An internal agent

Output of the test: One set of results for every group lock mode currently active in the target database. The table below discusses the probable locking modes and what they represent:

Descriptor	Description
EX	Exclusive update lock
SH	Shared lock
RD	Read lock
WR	Write lock
IN	Information lock

 

Configurable parameters for the test

Parameter	Description
Test period	How often should the test be executed.
Host	The host for which the test is to be configured.
Port	The port number at which the specified Host listens to. By default, this will be 31438.
Universe Shell Path	This test uses UniVerse shell commands to pull the desired metrics from the server. To enable the test to run these commands, provide the path to the bin folder of the UniVerse install directory. For example, for a Windows installation of UniVerse, the universe shell path can be: C:\U2\UV.  For a Unix installation, your specification can be: \usr\uv.
Eclipse Path	U2 DBTools include Eclipse-based tools for programming and administration. Eclipse is an integrated development environment (IDE). It contains a base workspace and an extensible plug-in system for customizing the environment. Eclipse is written mostly in Java and its primary use is for developing Java applications. Where Eclipse IDE is installed, the eG agent should be configured to use the Eclipse environment for executing the UV shell commands. In this case therefore, type the full path to the Eclipse home directory. By default however, this parameter is set to none, indicating that by default, the eG agent runs the commands from the UniVerse shell only and not Eclipse.
Detailed Diagnosis	To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option. The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled: The eG manager license should allow the detailed diagnosis capability Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.

Metrics reported by the test

Measurement	Description	Measurement Unit	Interpretation
Active group locks	Indicates the number of active group locks in this mode.	Number	Compare the value of this measure across modes to identify the mode which most of the group locks are in. If the database server has been frequently experiencing processing bottlenecks, you can use the detailed diagnosis of this measure to identify the processes that are holding the locks in that mode, the users who initiated the processes, the files and groups that are locked, the file system in which the files exist, and the host from which the lock originated. With the help of this information, administrators can instantly isolate the processes that are holding the locks unnecessarily and the users who are running those processes. Such processes can later be killed or the lock they hold released to clear the processing bottleneck.