Database Reference
In-Depth Information
Chapter 2
Capacity Planning and Architecture
RAC provides normal features such as recoverability, manageability, and maintainability found in a stand-alone
(single instance) configuration of Oracle Relational Database Management System (RDBMS). Among the business
requirements supported by Oracle RDBMS, availability and scalability are naturally derived from the architecture of
the RAC configuration.
Using database built-in features such as Fast Application Notification (FAN), Transparent Application Failover
(TAF) and Fast Connection Failover (FCF), RAC provides failover and scalability options. Features introduced in
Oracle 11g Release 2 provide additional features such as dynamic provisioning of instances. Such features are a step
toward eliminating the need to physically map a database instance to a specific server and to treat each instance as a
service within a pool of servers available. Further to this, Oracle provides scalability features through implementation
of load balancing based on demand in the pool distributing workload and effectively utilizing resources also through
the implementation of FAN.
Although RAC does provide availability and scalability features, such features can also be obtained through
alternative methods. Availability of the database environment could be obtained by implementing a standby
environment using Oracle Data Guard (ODG). Similarly scalability of the database environment could be achieved
by providing additional resources such as CPU, memory to the existing hardware, or scaling the servers up (vertical
scalability). If all these alternate solutions can help meet the business requirements, why do we need RAC? It's a good
question and it's encouraged that an answer satisfies the business goals and justifies a RAC implementation.
The alternate solutions just mentioned, such as the data guard or the options to vertically scale the servers,
have limitations and do not provide a complete flexible solution to meet the ever-increasing demands of today's
business. For example, when failing over from the primary location/database to the secondary/data guard location, it
is possible that all the data that were generated by the primary site might not have reached the secondary site. Other
complexities may occur as well, such as applications having to be moved from the current locations so they point
to the new data guard locations and users having to disconnect or close the sessions and start their activities again.
Similarly, vertical scalability has its limitations, such as how much additional memory or CPU can be added to the
existing servers. This is limited by how much increase in such resources these servers can physically accommodate.
What happens when these limits are reached? These servers have to be replaced with a higher model, which brings
downtime and possible changes to the application and adds to the additional testing that would have to be included.
With the increased growth of customers and users, businesses face an everyday challenge in providing system
response time. The day-to-day challenge is how these additional users can utilize the limited resources available
on the servers. The capacity of the servers and resources such as CPU, processing power, memory, and network
bandwidths are all limited.
When deciding on the servers and the related infrastructure for the organization, it is critical that the capacity
measured in terms of power to support the user workload be determined.
Search WWH ::
Custom Search