Net.Data Administration and Programming Guide for OS/400

Improving Performance

To learn about DB2 performance considerations, see DB2 for AS/400 SQL Programming Guide. This publication has a wealth of information, such as effectively using SQL indexes, improving performance of join queries, and improving performance when selecting data from more than two tables. In the following sections, highlights of database and SQL language environment-specifc techniques are described:

Database Techniques

The following summary outlines some of the most simple database techniques that can improve database access:

• Avoid numeric conversion. When a column value and a literal value are being compared, try to specify the same data types and attributes. DB2 for AS/400 does not use an index for the named column if the literal value has a greater precision than the precision of the column. If the two items being compared have different data types, DB2 for AS/400 will have to convert one or the other of the values, which can result in inaccuracies (because of limited machine precision).

  For example, EDUCLVL is a halfword integer value (SMALLINT). Specify:

   ... WHERE EDUCLVL < 11 AND EDUCLVL >= 2
  

  Instead of:

  ... WHERE EDUCLVL < 1.1E1 AND EDUCLVL > 1.3
  

• Avoid character string padding. Try to use the same data length when comparing a fixed-length character string column value to a literal value. DB2 for AS/400 does not use an index if the literal value is longer than the column length.

  For example, EMPNO is CHAR(6) and DEPTNO is CHAR(3). Specify:

  ... WHERE EMPNO > '000300' AND  DEPTNO < 'E20'
  

  Instead of:

  ... WHERE EMPNO > '000300 ' AND DEPTNO < 'E20 ' 
  

• Avoid the use of LIKE patterns beginning with % or _. The percent sign (%), and the underline (_), when used in the pattern of a LIKE predicate, specify a character string that is similar to the column value of rows you want to select. When used to denote characters in the middle or at the end of a character string, LIKE patterns can take advantage of indexes. For example:

  ... WHERE LASTNAME LIKE 'J%SON%'
  

  However, when used at the beginning of a character string, LIKE patterns can prevent DB2 for AS/400 from using any indexes that might be defined on the LASTNAME column to limit the number of rows scanned. For example:

  ... WHERE LASTNAME LIKE '%SON' 
  

  Avoid using these symbols at the beginning of character strings, especially if you are accessing a particularly large table.

SQL Language Environment Techniques

Use the following SQL language environment techniques to improve performance.

• Reduce the number of user IDs connecting to a database to avoid reconnecting to the database. The SQL language environment associates a user-profile and password to any remote connections to databases that it establishes. If the LOGIN and PASSWORD variables do not match the user-profile and password associated with an opened connection, the connection is closed and re-established, and the LOGIN and PASSWORD values are associated with the re-opened connection.

• Use the START_ROW_NUM and RPT_MAX_ROWS Net.Data variables to reduce the size of returned tables. If, on a SELECT SQL statement, the result set contains hundreds of records, return a subset of the result set back to the browser by using the START_ROW_NUM like a scrollable cursor and RPT_MAX_ROWS to limits the number of records returned. You should be aware that Net.Data reissues the query every time since there is no notion of state. However, you can use Net.Data support for persistent macros to store the result set in a Net.Data table that persists for the life of the transaction. See Transaction Management with Persistent Macros to learn more about persistent Net.Data macros.

• Consider calling a stored procedure that uses static SQL. Dynamic SQL is prepared at runtime, while static SQL is prepared at the precompile stage. The SQL language environment uses dynamic SQL, which allows it to run SQL statements at program run time. Because preparing statements requires additional processing time, static SQL may be more efficient.

  Note that starting in OS/400 V4R2, the SQL engine has a prepared statement cache. Using the cache, the SQL engine stores away information about prepared statements, and keeps this information in system-wide storage. Then, when the same statement is executed again, even if its by a different user and a different job, the statement will run much faster. The system-wide prepared statement cache is part of normal SQL processing and requires no user action to configure or enable it. The cache may reduce any performance benefits that the static SQL might have over dynamic SQL.