 |
|
Oracle Tips by Burleson |
RAC Database Instance Tips
RAC Database has multiple database instances to
access and manage a single database system. With the shared disk
architecture, Database consists of a single set of physical data
files for data and they can be accessed by multiple database
instances. As shown in the Fig. 4.2, each of the instances resides
on a separate host and forms its own set of background processes and
memory buffers. Thus, RAC enables access to a single database via
multiple database instances.
When the database is not a RAC system, it has
one instance and one database. Sometimes, instance and database are
construed to be the same. In that case, it is called stand-alone
database system.
As an example,
Database Name
: NYDB50
Instance-1
Name : NYDB51
Instance-2 Name : NYDB52
Instance-3 Name : NYDB53
The parameter DB_NAME will have the value of
NYDB50 and this represents the name of the database. Moreover, the
parameter instance_name will be one of the above names. All these
instances provide access to the same database, which is name NYDB50.
Figure 4.2 Multi-Instance RAC Database System – At a Glance
Let's start our examination of the Oracle
Architecture by looking at the memory pools and the background
processes in a single-instance database. Then we will extend the
study to look at the extra processes and structures that are formed
in case of a RAC configuration.
Database Instance
A typical RAC database instance is very much
like a stand-alone database system. It has all frills and bells of a
typical database instance. However, it has some extra processes,
memory structures and logical structures. Since the RAC database
system has to maintain concurrency of data across multiple
instances, it creates additional structures to manage and coordinate
the resources.
The Oracle Instance has various components to
support the database processing. The memory components are broadly
categorized as System Global Area (SGA) and Program Global Area (PGA).
System Global Area (SGA)
The system global area (SGA) consists of
various memory components. A component represents a pool of memory
used to satisfy a particular class of memory allocation requests.
The most commonly configured memory components include the database
buffer cache, shared pool, java pool, large pool, streams pool, data
dictionary cache and redo log buffer. PGA consists of session
specific information that contains data and control structures.
RAC
System Global Area
The size of the SGA is determined by several
initialization parameters. The following shows the parameters that
influence the SGA size. However, when the initialization parameter
‘sga_target’ is set to greater than zero, the automatic SGA
configuration kicks in. We will cover more details in a later part
of this chapter.
Parameter |
Remark / Description |
DB_CACHE_SIZE |
The
size of the cache of standard blocks |
LOG_BUFFER |
The
number of bytes allocated for the redo log buffer |
SHARED_POOL_SIZE |
The
size in bytes of the area devoted to shared SQL and PL/SQL
statements. |
LARGE_POOL_SIZE |
Size of
the large pool; the default is 0. |
JAVA_POOL_SIZE |
The
size of the Java pool |
Database Block Buffers
The database buffer cache holds copies of the
data blocks read from the data files. The term ‘data block’ is used
to describe a block containing table data, index data, clustered
data, and so on. Basically, it is a block that contains data. All
user processes concurrently connected to the instance share access
to the database buffer cache. The database buffer cache is logically
segmented into multiple sets, which reduces contention on
multiprocessor systems.
This area of the SGA contains only the buffers
themselves and not their control structures. For each buffer, there
is corresponding buffer header in the variable area of the SGA.
From Oracle8 release onwards, the buffer cache
contains three buffer pools for different type of data usage. They
are DEFAULT, KEEP, and RECYCLE. These three buffer pools have
separate allocations of buffers and LRU lists that manage buffers.
-
RECYCLE buffer pool is used to store blocks
that are virtually never used after the initial read. This pool
eliminates the data blocks from the memory in next to no time
when longer needed. This is more like a work area for the
blocks.
-
The KEEP pool is for the allocation of
buffers for the objects that are accessed with medium frequency
or those for which a consistent response time is desirable. This
buffer pool retains the schema object’s data blocks in memory.
-
The DEFAULT buffer pool contains data
blocks from schema objects that are not assigned to any buffer
pool and as well as for the schema objects that are explicitly
assigned to the DEFAULT pool.
The database block buffers act as the holding
area for data used by the user and DBWR processes. Any data that
gets to the user from the database files, or data that goes into the
database files from the user or other processes, passes through the
database block buffers (unless direct insert or direct read is used
for data loading, sorting, or hashing operations).
The database block buffers in releases prior to
Oracle9i had to be of uniform size, 2, 4, 8, 16, or for 64 bit OS,
the 32 kilobytes in size. From Oracle9i, the database has a default
database cache block size, but other sizes (2K, 4K, 8K, 16K, or 32K)
can also be specified. Based on the tablespace size, appropriate
Cache is employed to retrieve and manage the buffers in the SGA.
In the RAC database system, the database block
buffers from each of the participating instance, through the process
of ‘cache fusion’, are merged to form a logical database block
buffer area that becomes many times larger than could be supported
in a single instance.
Cache Fusion and Inter-Instance database buffer
transfers are fully covered in Chapter-9, Cache Fusion and
Inter-Instance Coordination.
The above text is
an excerpt from:
Oracle 10g Grid & Real Application
Clusters
Oracle 10g
Grid
Computing with RAC
ISBN 0-9744355-4-6
by Mike Ault, Madhu Tumma
Oracle Consulting Services
Burleson Oracle Consulting offers Senior Oracle consultants which are available
for all areas of Oracle support. Common Oracle consulting support
activities include short-term Oracle tuning, Oracle database troubleshooting,
Oracle9i and Oracle10g migration,
Oracle9iAS App Server
consulting, Oracle design reviews and
Oracle requirements evaluation support. Oracle support and Oracle consulting
services are priced by the hour, so you only pay for what you need. These
one-time Oracle consulting services commonly include:
-
Answering questions from your Oracle DBA technical staff
-
Repairing down production Oracle database systems
-
One-time Oracle tuning evaluation
-
Guru support for your Oracle DBA
-
Installation of Oracle application packages
For more information, please visit
www.dba-oracle.com
or email
info@remote-dba.net.

|