You can use the Automated Workload Repository (see
Chapter 8) to gather all the commands generated during testing periods and then determine the
explain plans for the most resource-intensive queries in that set. If the commands are still in the
shared SQL area, you can see the statistics via V$SQL and the explain plan via V$SQL_PLAN.
Acceptance Test Procedures
Purchased packages should be held to the same functional requirements that custom applications
must meet. The acceptance test procedures should be developed before the package has been
selected; they can be generated from the package-selection criteria. By testing in this manner,
you will be testing for the functionality you need rather than what the package developers
thought you wanted.
Be sure to specify what your options are in the event the package fails its acceptance test
for functional or performance reasons. Critical success factors for the application should not be
overlooked just because it is a purchased application.
The Testing Environment
When establishing a testing environment, follow these guidelines:
It must be larger than your production environment. You need to be able to forecast
future performance.
It must contain known data sets, explain plans, performance results, and data result sets.
It must be used for each release of the database and tools, as well as for new features.
It must support the generation of multiple test conditions to enable the evaluation of the
features??™ business costs.
Pages:
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299