Testing for Scalability - Expert Oracle RAC Performance Diagnostics and Tuning - page 91

and scalability of the application tier must be considered, too. However when testing the hardware for scalability, the
application should not be included. These scalability tests only consider bare database servers.
Several features available from Oracle simply scale out of the box; however, when combined with the application,
similar results maynot be obtained due to various reasons, for example, inefficiently written application code. To
ensure optimal scalability of the code, systematic testing is required.
Testing Hardware for Scalability
In this phase of testing, the basic clustered hardware is tested with the Oracle RAC software to obtain scalability
numbers, which will then become the baseline to other phases of testing.
Under no circumstances should any of the RAP phases be ignored or compromised because the luxury to identify
and fix problems maynot be available once the environment is in production; and it could become really late in the
game when components start failing in production, defeating the entire goal of providing HA to the database.
RAP Phase V Hardware Scalability
During this phase, a standard performance benchmarking software load will test the database environment, not
including the application schemas and data. The purpose of this test is to verify the database and operating system
performance characteristics. Based on the load tests and the statistics collected, the database and environment
should be tuned. Once tuned, the testing should be repeated until a maximum or until such point when no or
minimal scalability gains are noticed.
Workshop
Earlier in this chapter we discussed the various scalable components of a RAC cluster. RAP Phase V checks for
scalability of these components and helps tune the configuration parameters to achieve the maximum throughput
and response times that the server is capable of giving.
This phase of the testing can be completed very early in the RAC migration process. Once RAP Phase I is
complete and it's determined that the various components are stable, the scalability of these components could be
tested and tuned.
Step 1
Gather all information and settings from the various components, such as make, model, memory,and so forth.
Collect information regarding configurations and settings from each component used in the cluster.
Along with this information regarding components, also collect the current operating system (O/S) level
settings for the primary parameters for all of these components. For O/S parameters related to Oracle and network
components, most implementations start with the basic parameters suggested by Oracle in the installation guides.
This should be the initial baseline value before starting the tests.
Step 2
After the initial configuration information is collected, the next step is to start to load test the cluster. Compared to
the Phase I tests where we used same of these tools to test the stability of the components, Phase V tests are more
controlled and should be more organized and planned tests. The workloads used to test should be based on what
type of application workload will use the cluster after it's deployed into production: OLTP, Data warehouse, or a mixed
workload. Based on this, the appropriate testing tool and functionality should be used. For example, load-testing tools
available in the market such as Hammerora support both TPC-C and TPC-H workloads. Whereas TPC-C gives you
an OLTP type of workload TPC-H represents a data warehouse workload. Figure 4-3 illustrates a screenshot from a
workload generated using Hammerora.