The test environment that is used to capture SQL data and test pureQuery client optimization should match the production environment as closely as possible.
Set application-specific pureQuery Runtime properties when more than one application is sharing a data source and you need to capture SQL statements at the application level. These application-specific properties can point to a repository in a database for easy property management for an application.
Ensure that you are setting the pureQuery Runtime properties at the appropriate level: connection, data source, application specific, or global. For example, if you set pureQuery Runtime properties to capture at a global level in WebSphere installation, all applications will write to the same file.
For example, to minimize the pureQueryXML file size and increase processing speed, you can disable the capturing stack trace information if it is not needed.
The minimal sized stack traces can be gathered by filtering the contents of the stack trace with the pureQuery Runtime property packagePrefixExclusion.
If your application runs many SQL statements that share the same syntax and differ only in the literal values that they contain, pureQuery Runtime can capture and consolidate those statements by substituting parameter markers for the literal values
Enable IBM® Data Server Driver for JDBC and SQLJ tracing and set pureQuery tracing to the level FINER to direct pureQuery Runtime to report potential static SQL execution issues.
This is practice is particularly necessary for WebSphere applications when pureQuery Runtime is writing the captured SQL data to file on disk.
The application does not need to be shut down if pureQuery Runtime stores captured SQL data in a repository created in a database. The captured SQL data are written to records in the repository. When extracting the data, the pureQuery ManageRepository utility does not create pureQueryXML files from records that are still being used to capturing data.