Executive Summary
RAC (Real Application Clusters) provides businesses with some
outstanding benefits. Not
only is nearly 100% uptime possible, but scalability is possible using
lower priced hardware.
These things come with a cost:
increased licensing cost, training, consultants, software,
hardware, and other components of a RAC system.
In addition, RAC only provides support for part of the
availability spectrum.
Other costs will have to be endured to provide a Maximum Availability
Architecture
(MAA).
It is important for managers to understand these concepts before
embarking on the RAC quest; remember that although one's employees are
hopefully top notch and know what they are doing, it is the manager's
credibility if one jumps into a project without having a full view of
its possible repercussions.
What is RAC?
In many ways, RAC seems too good to be true.
RAC offers 24 x 7 database availability, true scalability, and
high performance all on low cost commodity servers.
The Oracle System
The Oracle system is formed of two parts: the database and the
instance.
Component 1: The Database
The database is simply the files on disk.
An Oracle database consists of three specific required file
types:
-
Datafiles
-
Control Files
-
Redo Logs
Datafiles
Oracle datafiles are the final storage location of the data.
All data that is inserted, updated, or deleted will make its
way to the datafiles once the change is committed.
These files are physically stored on disk resources.
Datafiles are grouped into tablespaces.
A tablespace is a logical disk area that Oracle objects (tables
and indexes) can be stored in.
When a user creates an object, the object is placed logically
in the tablespace and physically in the data file.
In Oracle 11g, there are two tablespaces that are required: the SYSTEM
and SYSAUX tablespaces.
Control Files
The control file is the record keeper of the Oracle Database.
It keeps track of the current state of the datafiles and redo
logs, archive logs, and the database.
Multiplexing the control file is highly recommended.
The control file is a required file on non-RAC and RAC systems.
Losing a control file will cause an instance crash.
Redo Logs
Redo logs act like a tape recorder that records every change in the
Oracle database. As
changes occur, they are regularly recorded in the online redo logs.
Oracle can replay the saved transactions in the redo logs and re-apply
lost transactions back into the database.
Many times, this means that Oracle can recover from a crash
without the DBA having to do anything other than just telling the
database to start up.
At a minimum, Oracle requires two redo logs.
Oracle will write redo to the first log and when the first log
is full, Oracle will switch to the second log and write the same redo.
Each of these individual online redo logs is known as an online
redo log group.
Like control files, it is a good idea to have multiplexed copies of
the online redo files in each group.
Also like control files, it is a good idea to have multiplexed
copies of the redo logs.
Each copy of the redo log file within a log group is called a redo log
member. Each redo log
group can have one or more members.
Component 2: The Instance
The Oracle Instance is the runtime component of Oracle.
The instance is made up of the following parts:
Binary Processes
Oracle runs five critical binary processes that are activated when the
instance is started.
-
SMON
- The System Monitor.
SMON is primarily used to recover a crashed instance.
-
PMON
- The Process Monitor.
PMON cleans up dead processes and registers network
services for the instance.
-
DBWR
- Database Writer.
DBWR is used to write blocks to datafiles (transition from
instance to database).
-
LGWR
- Log Writer. LGWR
writes redo information to the redo log files.
-
CKPT
- Checkpoint. CKPT assists in keeping all files in sync.
If any of these processes fail, the entire instance of Oracle crashes.
In a single instance environment, this results in downtime.
Note that on Microsoft Windows, these five processes are threaded
under a single process called ORACLE.EXE.
RAM
Oracle stores data in RAM in an area called the System Global Area
(SGA). The SGA is broken
down into pools where data can be temporarily stored before being
discarded, overwritten, or flushed to disk.
These pools or memory areas are:
-
Buffer Cache
- Stores cached blocks of data from Oracle datafiles when queried.
Also stores data written with inserts, updates, and deletes
called Data Manipulation Language, or DML.
Data is flushed from this pool via DBWR to the datafiles.
The buffer cache is very important to RAC.
-
Shared Pool
- Caches the means by which SQL can be executed, called an
execution plan. When
SQL is run, it must be parsed; if the execution plan is cached in
the shared pool, the parse phase is sped up considerably.
-
Log Buffer
- Stores change data to be flushed to the current redo log file.
Flushing occurs every commit,
every three seconds, when the buffer is one third full, when it
reaches 1MB, on checkpoint, or when required by DBWR.
