Methodology - Expert Oracle RAC Performance Diagnostics and Tuning - page 2

Problem-solving tasks of any nature need to be approached in a systematic and methodical manner. A detailed
procedure needs to be developed and followed from end to end. During every step of the process, data should be
collected and analyzed. Results from these steps should be considered as inputs into the next step, which in turn
is performed in a similar step-by-step approach. A methodology should be defined to perform the operations in
a rigorous manner. Methodology ( a body of methods, rules, and postulates employed by a discipline: a particular
procedure or set of procedures ) is the procedure or process followed from start to finish, from identification of the
problem to problem solving and documentation. A methodology developed and followed should be a procedure or
process that is repeatable as a whole or in increments through iterations.
During all of these steps or iterations, the causes or reasons for a behavior or problem should be based on
quantitative analysis and not on guesswork. Every system deployed into production has to grow in the process of a
regression method of performance testing to determine poorly performing units of the application. During these tests,
the test engineer would measure and obtain baselines and optimize the code to achieve the performance numbers or
service-level agreements (SLA) requirements defined by the business analysts.

Performance Requirements
As with any functionality and business rule, performance needs are also (to be) defined as part of business
requirements. In organizations that start small, such requirements may be minimal and may be defined by user
response and feedback after implementation. However, as the business grows and when the business analyst defines
changes or makes enhancements to the business requirements, items such as entities, cardinalities, and the expected
response time requirements in use cases should also be defined. Performance requirements are every bit as important
as functional requirements and should be explicitly identified at the earliest possible stage. However, too often, the
system requirements will specify what the system must do, without specifying how fast it should do it.
When these business requirements are translated into entity models, business processes, and test cases, the
cardinalities, that is, the expected instances (aka records) of a business object and required performance levels should
be incorporated into the requirements analysis and the modelling of the business functions to ensure these numbers
could be achieved. Table 1-1 is a high-level requirement of a direct-to-home broadcasting system that plans to expand
its systems based on the growth patterns observed over the years.

Table 1-1. Business Requirements

Entity Current Count Maximum Count Maximum Read

Access (trans/sec)

Maximum Update
Access (trans/sec)

Average Growth
Rate (per year)

Smartcards 16,750,000 90,000,000 69 73 4,250,000

Products 43,750,000 150,000,000 65 65 21,250,000

Transmission logs 400,000

records/day

536,000,000 N/A 138 670,000,000

Report back files 178,600

records/day

390,000,000
records
processed/year

N/A N/A 550,000,000

Note: trans/sec. = transactions per second; N/A = not applicable.

1. It will store for 15 million subscriber accounts.

2. Four smart cards will be stored per subscriber account.

3. Average growth rate is based on the maximum number of active smart cards.