Nonstop Database, HiRDB Version 9 System Operation Guide

[Contents][Index][Back][Next]

23.5.4 Tuning the buffer length for SQL objects

This section explains tuning of the buffer length for SQL objects (pd_sql_objet_cache_size operand value). When SQL object buffer tuning is performed, the following must be taken into account:

Relationship between an SQL object and an SQL object buffer
HiRDB analyzes each SQL statement in a UAP and creates an execute-form SQL object when the UAP executes. If the same UAP is executed again by another user and if an SQL object corresponding to a specified SQL statement is found in an SQL object buffer, the time required for creating the SQL object is eliminated, thereby reducing SQL statement processing time.
Once an SQL object is deleted from its buffer, it must be analyzed again to re-create it during execution, resulting in a low SQL object buffer hit rate. Therefore, when an SQL statement whose database accesses count is low is executed, a long processing time is required. Furthermore, if the buffers do not contain the table definition information necessary to analyze an SQL statement, the data dictionary tables must be accessed. If many tables or columns are accessed or data is accessed many times, the amount of locked resources increases, thereby increasing the processing time.

SQL object buffers
In the case of a HiRDB parallel server configuration, multiple SQL objects are created for a single SQL statement. The characteristics of SQL objects in the back-end and front-end servers are discussed below.
  • Back-end server
    SQL objects are created in execute form for each corresponding back-end server (including a floating server). Of all the SQL objects buffered in the front-end server, only those SQL objects for a particular back-end server are buffered in the SQL object buffers of that back-end server; therefore, fewer SQL object buffers are required for a back-end server than for the front-end server.
  • Front-end server
    The SQL object buffers for the front-end server contain all SQL objects for the back-end servers. A large number of SQL object buffers is required in order to take advantage of the buffering effects, because cost-based optimization creates SQL objects for selectable access procedures.
    The same applies to stored procedures and stored functions. It should be noted that the size of an SQL object is larger for a stored procedure or a stored function than for a normal SQL.

Performance can be improved efficiently if this information is analyzed together with the following statistical information:

Organization of this subsection
(1) Analysis method (1)
(2) Analysis method (2)
(3) Analysis method (3)
(4) Analysis method (4)

(1) Analysis method (1)

Information to be referenced
See the following system activity statistical information provided by the statistics analysis utility:

Tuning procedure
  1. If the SQL object buffer hit rate is low and the total length of SQL object information in the buffers is short, the application mode might be preventing a high hit rate from being achieved.
  2. If the SQL object buffer hit rate is low and the total length of SQL object information in the buffers is long, the SQL object buffers might be too small.
Use the following formula to obtain the SQL object buffer hit rate:
SQL object buffer hit rate (%) =
(SQL object buffer hits count [Figure] number of SQL object acquisition requests) [Figure] 100

Actions to be taken
If the SQL object buffers are too small, increase the value of the pd_sql_objet_cache_size operand.

(2) Analysis method (2)

Information to be referenced
See the following system activity statistical information provided by the statistics analysis utility:

Tuning procedure
Tune in such a manner that the number of SQL objects taken out of the SQL object buffer is small.
If the number of SQL objects removed from SQL object buffers is greater than the number of SQL object acquisition requests, too many SQL objects are having to be re-created, thereby increasing the processing time. This is probably caused by poor utilization of the SQL object buffer pool.

Actions to be taken
Increase the value of the pd_sql_objet_cache_size operand.

(3) Analysis method (3)

Information to be referenced
See the following system activity statistical information provided by the statistics analysis utility:

Tuning procedure
If the maximum total of the SQL object lengths (REQUEST SQLOBJ SIZE) and stored procedure object lengths (REQUEST STRT SIZE) is greater than the specified buffer length, insufficient memory might have been allocated to execute SQL objects.

Actions to be taken
Increase the value of the pd_sql_objet_cache_size operand.

(4) Analysis method (4)

Information to be referenced
See the following system activity statistical information provided by the statistics analysis utility:

Tuning procedure
When the CALL statement is used to execute a stored procedure, recompilation usually does not occur. If an index is added to a table used within a stored procedure or an index not in use is deleted, recompilation occurs. Such recompilation occurs each time the stored procedure is executed with the CALL statement, which has an adverse effect on performance.
If recompilation has occurred, one of these changes might have been made to a table used within the stored procedure.

Actions to be taken
Use ALTER PROCEDURE or ALTER ROUTINE to re-create the stored procedure.