Database Reference
In-Depth Information
3.
In some database environments with I/O-intensive workloads, most performance
bottlenecks are on storage I/O with lower CPU utilization. Such environments will not scale
well just by adding more RAC nodes. Therefore, it is important to understand the workload
characteristics and potential performance bottlenecks before we opt for the scalable
solution. Storage performance capacity is measured in IOPS (I/O operations per second)
for OLTP workloads and throughput MB/second for DSS workloads. Since the speed of hard
disks is limited by physics (drive seek time and latency), they tend to impose an upper limit
on IOPS and throughput. One way to scale storage performance is to add more disk drives
and stripe the data files with either RAID or Oracle ASM striping. Another option is to move
frequently accessed data (hot data) to solid disk drives (SSDs). SSDs provide much higher
IOPS, especially for the random small I/O operations which dominate OLTP workloads, as
SSDs have no moving parts and hence no mechanical delays. Using SSDs is a very viable
option to scale storage IOPS performance for OLTP workloads. For DSS workloads, one
option is based on the building block concept. Each building block is composed of a RAC
node plus additional storage and network based on the balance between CPU processing
power and storage throughput for a DSS/Data warehouse-type workload. Scalability is
based on the building block instead of just a server.
RAC or Not
When IT organizations need to decide whether to deploy an Oracle RAC as their database architecture, IT architects
and DBAs need to make decisions based on many factors.
1.
The High availability SLA: How much database downtime is acceptable for both
unplanned and planned downtime? Without RAC, planned downtime for hardware
and software maintenance may vary from a few minutes to as much as a few hours. And
the unplanned time for hardware and software problems can also vary from minutes
to hours. If a database server is completely lost, it will take a longer time to rebuild it,
although some downtimes, like the complete loss of the server, may occur only rarely,
Are these potential downtimes acceptable to the business according to the SLA? If not,
can downtime prevention justify the cost of the RAC deployment? And furthermore, a
loss of the entire database system including the storage may take hours or days to recover
from the backup. Does this justify a Disaster Recovery (DR) solution which consists of a
completely duplicated system in another data center? Some mission-critical databases
may be equipped with the combination of RAC and Data Guard DR solution to protect
the database from server failure as well as storage and site failure. However, the cost and
technical complexity need to be justified by business needs.
2.
Scalability Requirement: What kind of workloads are there and where is the performance
bottleneck: CPU intensive and/or storage I/O intensive? If there is no need to scale out
CPU/memory resources or if we can scale up by adding additional CPUs or memory,
Oracle RAC One Node (instead of multiple RAC RAC) may be a good way of providing HA
without the need to pay for an RAC license. RAC One Node also has the flexibility to be
easily upgraded to a full RAC solution any time there is a need to scale out to multi-node
RAC in the future.
3.
Database Consolidation Requirements: If the organization has a business requirement
to consolidate many database services together, a multi-node RAC can offer significant
advantages in terms of cost of ownership wjile providing HA and scalability to all the
databases.
