Required settings for capturing SQL statements when you are performing incremental capture for client optimization

With these settings, you can capture more SQL statements from an application after you have already captured other SQL statements from it.
If you edited your application after creating a pureQueryXML file and you want the stack traces in that file to be accurate, you cannot perform incremental capture if either of these two conditions is true:
  • Your edits included more than changes to the properties in a URL for a connection or in a DataSource object.
  • Your edits changed the number of lines in your application.

Editing your application can invalidate stack traces that are recorded in the pureQueryXML file.

Table 1. Required settings for capturing SQL statements when you are performing incremental capture
Property Setting Effect
captureMode ON Causes pureQuery to capture statements when you run those statements in an application.
executionMode DYNAMIC Causes pureQuery to run statements dynamically.
For a non-clustered application, if you do not want to preserve the pureQueryXML file from being written to:
pureQueryXml
The name and path of the original pureQueryXML file.
When you run your application with the settings that are in the table, pureQuery checks whether a given SQL statement is already in the pureQueryXML file for the connection that the statement must run against. Then, pureQuery performs one of these actions:
  • If the statement is in the pureQueryXML file and the statement is bound in a DB2® package, pureQuery runs the statement statically.
  • If the statement is in the pureQueryXML file but the statement is not bound, pureQuery runs the statement dynamically.
  • If the statement is not in the pureQueryXML file, pureQuery captures the statement and runs it dynamically.
For a non-clustered application, if you use the original pureQueryXML file as an input file and want only to capture statements that you did not yet capture:
pureQueryXml
outputPureQueryXml
Setting for pureQueryXml:
The name and path of the original pureQueryXML file.

Setting for outputPureQueryXml:
file-name.pdqxml or file-name.xml
When you run your application with the settings that are in the table, pureQuery checks whether a given SQL statement is already in the pureQueryXML file (that you specified with the pureQueryXml property) for the connection that the statement must run against. Then, pureQuery performs one of these actions:
  • If the statement is in the pureQueryXML file and the statement is bound in a DB2 package, pureQuery runs the statement statically.
  • If the statement is in the pureQueryXML file but the statement is not bound, pureQuery runs the statement dynamically.
  • If the statement is not in the pureQueryXML file, pureQuery captures the statement in the file that you specified with outputPureQueryXml and runs the statement dynamically.

After you produce the output pureQueryXml file, you can merge it together with the original file.

For a clustered application, using a pureQueryXML file that is the result of the merge of the pureQueryXML files that you created when you last captured statements from the clustered application:
pureQueryXml
outputPureQueryXml
Setting for pureQueryXml:
The name and path of the pureQueryXML file that resulted from the merge.

Setting for outputPureQueryXml:
file-name.pdqxml or file-name.xml

When you run your application instances with the settings that are in the table, pureQuery checks whether a given SQL statement is already in the pureQueryXML file that you specified with the pureQueryXml property. Then, pureQuery performs one of these actions:

  • If the statement is in the pureQueryXML file and the statement is bound in a DB2 package, pureQuery runs the statement statically.
  • If the statement is in the pureQueryXML file but the statement is not bound, pureQuery runs the statement dynamically.
  • If the statement is not in the pureQueryXML file, pureQuery captures the statement in the file for the instance that is generated from the value of outputPureQueryXml and runs the statement dynamically.

This table does not show properties that you can leave at their default values or other properties that you might want to use. Here is a complete list of the properties that you can use when capturing SQL statements:

You can also set logging properties. See Descriptions of properties for logging and tracing.

See How to set properties for client optimization for information about how and where to set these properties.


Feedback