Locked resources management table information is output to a file each time a shortage of locked resources management tables occurs. The name of this output file is output-date-and-time.mem, where mem is a file descriptor. In the event of a shortage of locked resources management tables occurring at 09:16:02 on October 3, the name of the output file would be Oct3091602.mem. This file name is displayed in the KFPS00447-I message.

Deleting unneeded locked resources management table data files

HiRDB does not delete locked resources management table data files. Unneeded files must be deleted by the HiRDB administrator (using the OS's rm command, for example). For details about the rm command, see the applicable OS documentation.

The following figure shows the locked resources management table information that is output.

Figure 8-12 Locked resources management table information that is output

Explanation

1. Date and time the shortage of locked resources management tables was detected (mmm dd hh:mm:ss yyyy).
2. Type of affected locked resources management tables:
   RESOURCE
   Tables used for managing resource names. These tables are shared among multiple users. Therefore, the sum of the tables used by all users might exceed the total number of tables.
   OCP/WAIT
   Tables used for managing shared or wait status. These tables are not shared among multiple users.
   The following shows the difference between RESOURCE and OCP/WAIT:
   

   

3. Total number of available locked resources management tables.
   Information about the user who was involved in the shortage of locked resources management tables:
   
4. UAP identification information^#1
5. Server name
6. Process ID
7. Transaction identifier
8. User identification number
9. Deadlock priority value
10. Client's IP address^#3
11. Client's process ID^{#2, #3}
12. Number of tables currently used
    Information about another user when the shortage of locked resources management tables occurred (user whose usage factor of locked resources management tables is 10% or higher):
    
13. UAP identification information^#1
14. Server name
15. Process ID
16. Transaction identifier
17. User identification number
18. Deadlock priority value
19. Client's IP address^#3
20. Client's process ID^{#2, #3}
21. Number of tables currently used
    Information about other users when the shortage of locked resources management tables occurred (users whose usage factor of locked resources management tables is less than 10%):
    
22. Number of users whose usage factor of locked resources management tables is less than 10%

#1

Displays in 30 bytes the name of the client UAP that was connected.

This is the PROGRAM information that is output by the pdls -d prc or the pdls -d trn command. This information is not displayed for some utilities, in which case ******** is displayed. If the transaction is being recovered by restart processing, Rerun is displayed.

#2

When the HiRDB version of the client library linked to the connected client UAP is 4.0 04-00 or earlier or when the connection was made from a Type4 JDBC driver, 0 is displayed as the process ID.

#3

This information might not be displayed for a back-end server or dictionary server, in which case *.*.*.* is displayed as the client IP address, and 0 is displayed as the process ID.

Following are the key items that should be checked in the locked resources management table information:

• 3. Total number of available locked resources management tables
• 21. Number of tables currently used

The HiRDB administrator can determine from this information the UAPs using the locked resources management tables and their table usage factors. The number of locked resources management tables used is equal to the number of lock requests issued by UAPs. Therefore, a UAP for which the 21. Number of tables currently used value is too high might have issued too many lock requests. The number of lock requests issued by a UAP depends on the SQL; for the number of lock requests for each SQL (the estimated number of locked resources), see the manual HiRDB Version 9 System Definition.

(a) When there is a UAP issuing too many lock requests

A UAP that is issuing too many lock requests should be modified so that it does not issue so many lock requests.

The PDLOCKLIMIT operand in the client environment definition can also be used to set a maximum number of lock requests that can be issued by any UAP.

(b) When there is no UAP issuing too many lock requests

It might be that too few locked resources management tables are available. The following actions can be taken in this case.

When there is not enough shared memory space available at the unit (shared memory cannot be increased)

Do not execute concurrently many UAPs that use locked resources management tables.

When there is enough shared memory space at the unit (shared memory can be increased)

Modify the HiRDB system definition. The operand to be modified depends on the type of server. The server at which there are too few locked resources management tables can be determined from the 5. Server name information in the locked resources management table information.

When a shortage of locked resources management tables has occurred at the front-end server, the value of the pd_fes_lck_pool_size operand in the front-end server definition should be increased.

When a shortage of locked resources management tables has occurred at a server other than the front-end server, the value of the pd_lck_pool_size operand in the corresponding server definition should be increased.

Note

Before the HiRDB system definition is modified, the entire HiRDB or the entire unit whose definition is to be modified must be terminated normally, then the HiRDB system definition can be modified. If only the applicable server is terminated with the pdstop -s, modifications made to the definition will not be effective.