Measures reported by UnivDBAcGrLkTest

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 UnivDBAcGrLkTest 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.

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:

The measures made by this test are as follows: