This is an excerpt from the bestselling book
Oracle Grid & Real Application Clusters. To get immediate
access to the code depot of working RAC scripts, buy it
directly from the publisher and save more than 30%.
There are many applications that
are designed in such a way that the user connections or application
instances act on different sets of data blocks. This kind of
situation provides good scalability. There is minimum contention for
the data blocks. At the same time, many of the applications need
The following section will show
how each of the categories that use the RAC database uses the
OLTP Applications Using
Exclusive or Specific Data
In this type of application, the
RAC system gives almost linear scalability. Instead of using a
stand-alone database with limited resources, the RAC database
provides more than one database instance, allowing applications to
connect to any of the instances. For example, a bank branch is
accessing the central database system. Any particular branch usually
inserts or updates only the data pertaining to it. It rarely needs
to access another branch?s data. This kind of arrangement allows a
set of branches to be grouped by region or load, say, on instance
one. Another group of branches accesses instance two, and so on.
Since the data blocks of one branch are rarely spread across
multiple instances, scalability is almost linear, with nearly zero
cross instance transfers.
Extending the analogy explained
above, assume that there are many functional entities or departments
accessing a common RAC database system. For example, human
resources, sales, distribution, manufacturing, and finance all
access the same database system. Each of these functional units has
a set of data. It is very rare that the data pertaining to one
department is needed for another department.
In this case, access can easily
be vertically partitioned. For example, sales and distribution can
access through instance one, human resources and finance can access
through instance two, and manufacturing can access through instance
three. All these applications modify different sets of tables.
Conflicts and cross instance block transfers are minimized.
Data Warehousing Applications
DW applications involve large
and complex queries against a huge database. Data warehouses are
designed to accommodate ad hoc queries. It might not be possible to
anticipate the workload of a data warehouse in advance, so a data
warehouse should be optimized to perform well for a wide variety of
possible query operations.
DW is updated on a regular basis
by the ETL process, which is run nightly or weekly, using bulk data
modification techniques. ETL stands for extraction, transformation,
and loading. The end users of a data warehouse do not directly
update the data warehouse. During the data loading, SQL queries
accessing the data may experience poor response times owing to low
Compared to a typical OLTP
operation, which accesses only a handful of records, a typical data
warehouse query scans thousands or millions of rows or data blocks.
For example, a DW query may be asking to find the total sales for
all customers last month or analyze the stock price of the airline
industry during the current year.
To meet these kinds of
challenges, parallel processing is an apt solution. Oracle?s
parallel execution feature uses multiple processes to execute SQL
statements on one or more CPUs. Parallel execution is available on
both single instance and Real Application Clusters databases.
Real Application Clusters takes
full advantage of parallel execution by distributing parallel
processing to all the nodes in the cluster. The number of processes
that can participate in parallel operations depends on the degree of
parallelism (DOP) assigned to each table or index.
Since the RAC solution provides
multiple instances, the instance that uses SQL queries can
effectively be separated from the instance that is specialized for
data loading and ETL processing.
Applications Requiring HA
Many mission critical
applications, like brokerage trading systems, airline traffic
movement, credit card sales, online shopping, and retail banking,
etc., cannot afford to have any downtime. All these applications are
heavily dependent on the database systems.
The RAC database provides an
ideal solution to withstand node or host failures. With multiple
nodes, redundancy is built into the database system.