Database Reference
In-Depth Information
Planned downtime for an Oracle database may be scheduled for a system upgrade or migration. The database
system upgrade can be a hardware upgrade to servers, network, or storage; or a software upgrade to the OS, or
Oracle Database patching and upgrade. The downtime for the upgrade will vary depending on the nature of the
upgrade. One way to avoid database downtime for system upgrades is to have a redundant system which can take
over the database workloads during the system upgrade without causing a database outage. Migration maintenance
is sometimes necessary to relocate the database to a new server, a new storage, or a new OS. Although this kind of
migration is less frequent, the potential downtime can be much longer and has a much bigger impact on the business
application. Some tools and methods are designed to reduce database migration downtime: for example, Oracle
transportable tablespace, Data Guard, Oracle GoldenGate, Quest SharePlex, etc.
In this chapter, I focus on a specific area of Oracle Database HA: server availability. I will discuss how to reduce
database service downtime due to server failure and system upgrade with Oracle RAC. For all other solutions to
reduce or minimize both unplanned and planned downtime of Oracle Database, we can use the Oracle Maximum
Availability Architecture (MAA) as the guideline. Refer to the Oracle MAA architecture page,
www.oracle.com/
technetwork/database/features/availability/maa-090890.html
, for the latest developments.
Database Scalability
In the database world, it is said that one should always start with application database design, SQL query tuning, and
database instance tuning, instead of just adding new hardware. This is always true, as with a bad application database
design and bad SQL queries, adding additional hardware will not solve the performance problem. On the other hand,
however, even some well-tuned databases can run out of system capacity as workloads increase.
In this case, the database performance issue is no longer just a tuning issue. It also becomes a scalability issue.
Database scalability is about how to increase the database throughput and reduce database response time, under
increasing workloads, by adding more computing, networking, and storage resources.
The three critical system resources for database systems are CPU, memory, and storage. Different types of
database workloads may use these resources differently: some may be CPU bound or memory bound, while others
may be I/O bound. To scale the database, DBAs first need to identify the major performance bottlenecks or resource
contentions with a performance monitoring tool such as Oracle Enterprise Manager or AWR (Automatic Workload
Repository) report. If the database is found to be I/O bound, storage needs to be scaled up. In Chapter 5, we discuss
how to scale up storage by increasing storage I/O capacity such as IOPs (I/O operations per second) and decrease
storage response time with ASM striping and I/O load balancing on disk drives.
If the database is found to be CPU bound or memory bound, server capacity needs to be scaled up. Server
scalability can be achieved by one of the following two methods:
•
Scale-up or vertical scaling: adding additional CPUs and memory to the existing server.
•
Scale-out or horizontal scaling: adding additional server(s) to the database system.
The scale-up method is relatively simple. We just need to add more CPUs and memory to the server. Additional
CPUs can be recognized by the OS and the database instance. To use the additional memory, some memory settings
may need to be modified in OS kernel, as well as the database instance initialization parameters. This option is more
useful with x86 servers as these servers are getting more CPUs cores and memory (up to 80 cores and 4TB memory per
server of the newer servers at the time of writing). The HP DL580 and DL980 and Dell R820 and R910 are examples of
these powerful X86 servers. For some servers, such as those which are based on Intel's Sandybridge and Northbridge
architectures, adding more memory with the older CPUs might not always achieve the same memory performance.
One of the biggest issues with this scale-up method is that it can hit its limit when the server has already reached the
maximal CPU and memory capacity. In this case, you may have to either replace it with a more powerful server or try
the scale-out option.
The scale-out option is to add more server(s) to the database by clustering these servers so that workloads can be
distributed between them. In this way, the database can double or triple its CPU and memory resources. Compared to
the scale-up method, scale-out is more scalable as you can continue adding more servers for continuously increasing
workloads.
