Load Testing for Performance Validation:
Performing load test will not only determine the type of tests (CPU utilization, memory, I/O subsystem, locking) and how valuable the results are, but can also be used to validate several aspects of the application that a functional testing cannot validate. When setting up performance metrics on loading, the following data should at least be collected: start time, end time, duration, job parameters, number of rows being loaded, and the amount of data being loaded.
·    Disk I/O: put the I/O subsystem under stress test by running many processes simultaneously together to determine when I/O subsystem might overload. Disks usually have a recommended I/O rate, and when this rate is exceeded, I/O bottlenecks occur.
·    CPU utilization: put the processor under stress test to determine whether the operating system has been configured properly by monitoring the way it consumes resources, or to determine the number user processes it’ll take to cause CPU contention.
·     Locking: facilitate many concurrent processes to access the same table to determine or discover locking issues.
·     Memory: put the memory structure under stress test to determine the extent to which the buffer cache or shared pool gets overtaxed. Memory problems occur with main memory when paging or swapping becomes excessive.

Load testing can also be used to validate how a new or upgraded hardware works with an existing application, or to baseline the performance of brand-new application on a brand-new hardware platform. The results are then analyzed and interpreted in accordance to the changes being tested.

Tuning Potential Problems
Depending on the results of the testing:
·    Tune the Data Design
·    Tune the Application Design
·    Tune Memory Allocation
·    Tune I/O and Physical Structure
·    Tune Resource Contention
·    Tune the Underlying Platform(s), (operating system).

 At this point the database implementation process becomes an iteration process until the database application passes the user acceptance test. That is, when problems are detected during the test phase, they are documented and the database is migrated back to the development environment to troubleshoot those problems. Then the database comes to the test environment for further test analysis, and when it passes at this point, it becomes the basis for the production database.



References:
Afyouni, A. H. (2004). Oracle 9i Performance Tuning: Optimizing Database Productivity. Thompson Course Tech.

Alapati, S. R. (2008). Expert Oracle Database 11g Administration. Apress.

Burleson, D. K. & Danchenkov, A. B. (2005). Oracle Tuning: The Definitive Reference. Rampant Techpress

Connolly, M. T, & Begg, E. C, (2002). Database Systems: A Practical Approach to Design, Implementation, and Management. Addison-Wesley.

Donar, T. (2002). Tru64 UNIX-Oracle9i cluster quick reference (HP Technologies)

Freeman, R. G. (2008). Oracle Database 11g New Features: Maximize the New Capabilities of the Latest Database Release. McGraw Hill-Osborne.

Johnson, J. C. (2002). OCP: Oracle9i performance tuning study guide. Illustrated Edition. John Wiley and Sons.

Mittra, S. S. (2002). Database Performance Tuning and optimization: Using Oracle. Illustrated Edition: Springer.

Page, W. G. (1999). Using Oracle8/8i, Special Edition. Chapter 20: Que Books. Retrieved on September 28, 2009 from http://docs.rinet.ru/O8/index.htm

Piedad, F. & Hawkins, M. (2001). High Availability: Design, Techniques, and Processes. Prentice Hall PTR, New Jersey.

Rob, P. & Coronel, C. (2004). Database Systems: Design, Implementation, & Management. 6th Edition. Thompson Course technology

Stephens, R., Plew, R., & Sams, A. J. (2003). Teach Yourself SQL in 24 Hours, 3rd Edition. Sams Publishing.

Whalen, Edward. (2005). Oracle Database 10g Linux administration. McGraw-Hill-
Osborne/Oracle Press