Oracle Architecture and Administration

1.1 Duties of a database administrator

Now that we have we fairly good understanding about what the Oracle 10g database is used for and how
users can interact with it. We now move on to what this book aims to teach you, i.e. basic administration of
the Oracle 10g database.
A database administrator is a user of the database who has responsibilities that other regular users may
not be concerned with. Every database requires at least one database administrator (DBA). If the database
is large and needs to handle many thousands of users a group of administrators maybe required.
Since managing the database is such an important and responsible task, being an administrator is not
always easy. The individual in addition to being able to administer the database should have certain
personal strengths such as being proactive, organized and being able to handle well under stressful
situations. A DBA should also be able to communicate well. To effectively manage enterprise databases, a
DBA must understand business reasons for storing the data in the database and the technical details of
how the data is structured and stored.
Given below is a list of tasks which the administrator may need to do:
Install, Upgrade and configure the Oracle Database server based on the organizational requirements.
Since systems are not static, the DBA must be able predict growth based on application and data
usage patterns.
Understand the logical and physical structure of the particular database.
Ensuring the database is available to the users with minimum or no downtime, by taking backups
regularly and creating well-tested recovery strategies.
Helping and creating primary objects such as tables, views and indexes based on the needs of the
application developments.
The DBA must be able to design a database that holds accurate and valid data at all times.
Managing users and ensuring the database is accessible to only valid users.
Granting the users the privileges they need to perform various actions in the database.
Monitoring and optimizing the performance of the database.
The DBA must be able to design, debug, implement and maintain stored procedures, triggers and user
defined functions that are stored.
Security is becoming increasing important with the need for data to be available across the internet.
The DBA should ensure that the data is secure and implement rigorous security schemes for the
databases to ensure that only authorized users have access to the data.
The list above broadly covers various aspects of the administrators work responsibilities. By now you should
have gathered that the responsibilities of an administrator are not easy. However, companies like Oracle
Corporation are making this job easier with each new release. Oracle Database 10g is particularly popular
for its introduction of new automated and intelligent features that remove and simplify some the burden on
the DBA.
1.2 The Oracle Architecture
A database is a centralized repository of organizational data. The Oracle 10g Database Server allows you
to create, store, manage and retrieve the data in the database. A database administrator who is responsible
for administering a database should have a complete and thorough understanding of the architecture of the
database.
An analogy could be a service technician trying to fix a car that is having a problem. The technician wouldnt
know where to start unless he knows very clearly what the various components of the car are, what they
do, how they function and how they interact with each other. This is absolutely essential before he can start
to find a solution to the problem. The same goes for a database. If a user comes to an administrator with a
certain problem, the DBA cannot come up with the right solution unless he knows everything he possibly
can about the database.
The Oracle server consists of physical files and memory components. The Oracle 10g Database product is
made up three main components namely:
The Oracle Server This is the Oracle database management system that is able to store, manage and
manipulate data. It consists of all the files, structures, processes that form Oracle Database 10g. The
Oracle server is made up of an Oracle instance and an Oracle database.
 The Oracle Instance Consists of the memory components of Oracle and various background processes.
The Oracle database This is the centralized repository where the data is stored. It has a physical
structure that is visible to the Operating system made up of operating system files and a logical structure
that is recognized only the Oracle Server.
The figure below displays the architecture of the Oracle Database 10g. It is broadly divided into the memory
components which form the Oracle instance and the physical database components where different kinds
of data are stored.
Fig 3.1: Oracle Database Architecture

PHYSICAL FILES OF THE DATABASE

The Oracle Instance
The Oracle instance is made up of a number of memory-related components and background processes.
The instance is the created in memory every-time the database is started. The instance is associated to
only a single database at any time. The memory components of the Oracle Database 10g are also known
as the System Global Area (SGA).
The instance and its components are configured using a file known as the Parameter file. In Oracle 10g
there are two types of initialization files namely the Server Parameter files (spfile) and The Parameter file
(pfile). The parameter files hold parameters that can set the sizes of the various buffers and pools of the
SGA. You can also specify the name of the instance, the name of the database and other size-related
parameters needed by the Oracle instance.
A typical parameter setting would be parameter_name = parameter_value
For e.g. DB_NAME=moviedb
Here the name of the database is movie
Memory Components of the SGA
 The Oracle Instance is made up of the System Global area (SGA) and the background processes. The
SGA is made up of the
Redo Log Buffer
The Database Buffer cache
The Shared Pool
The Java Pool
The Large Pool
The Streams Pool
Redo Log Buffer A circular buffer that stores all changes made in the database. It contains are
transferred periodically from memory to the online redo log files on disk by the Log Writer (LGWR)
background process. The contents of the redo log buffer are essential for instance recovery purposes. The
size of the redo log buffer is determined by the LOG_BUFFER initialization parameter.
The Database Buffer Cache An area in memory that holds all the blocks read in from disk for
query or modification. Blocks that need to be modified, are modified in memory and are written back to disk
periodically. Modified blocks that have not yet been written to disk are known as dirty blocks. This buffer is
managed in a manner that free blocks are always made available for new blocks being read into memory.
The contents of the database buffer cache are shared by multiple user processes. The contents of the
database buffer cache are written to datafiles on disk by the
Database Writer (DBWR) background process. The size of the default database buffer cache is sized by
the DB_CACHE_SIZE initialization parameter. The blocks that are part of the Database buffer cache are
sized by the DB_BLOCK_SIZE initialization parameter. This is the default buffer cache.
Other caches that can be created in addition to the default database buffer cache. They are the Keep and
Recycle cycle buffers. Oracle uses the technique known as LRU algorithm, to create space for new in-
coming blocks that need room in buffer cache. The oldest blocks are the first ones to leave. There maybe
certain blocks that should be retained in memory for a longer period of time, since they are frequently
accessed. The Keep cache is used to hold such. Though they are also subject to the LRU algorithm, blocks
are not released as quickly as they would have in the default cache. Blocks from standard and frequently
accessed packages should be placed in the keep cache. The size of the Keep cache can be specified by
the DB_KEEP_CACHE_SIZE initialization parameter. The Recycle cache on the otherhand is used to hold
blocks of objects that should be released as soon as they are used if it is unlikely that they will be reused.
You can specify which cache will be used by an object when the object is created.
The Shared Pool The contents of this memory area are shared by multiple users and hence the
name shared pool. Two specific caches form the shared pool. The sizes of the two caches are not set
individually and are automatically determined by the Oracle Server. However it is possible to set the overall
size of the Shared pool by using the SHARED_POOL_SIZE initialization parameter.
Library Cache It is responsible for storing and reusing frequently used SQL statements, their
execution plans and stored procedures. This cache prevents SQL statements from being repeatedly
parsed thus improving performance during execution of SQL statements. When a statement is executed,
Oracle looks for an identical statement / execution plan in the library cache. If one is found it is reused,
if not a new parse tree and execution plan are created. The library cache also holds frequently accessed
PL/SQL blocks.
The Data Dictionary Cache Sometimes referred to as the Row Cache. The cache consists of
blocks that hold data dictionary information read in from the datafiles. Reads that are made to the data
dictionary information in the datafiles are also called recursive reads. Typical information stored in this
cache is user account information, table, index and other object definitions, privileges and other relevant
information that is frequently accessed. This cache is also managed using the Least Recently Used
(LRU) Algorithm, which is on a first-in first-out basis.
The Large Pool This is an optional pool. The size of this memory area is determined by the
LARGE_POOL_SIZE initialization parameter. It is used for handling large I/O requests of server processes.
Its main functions are to provide memory for session memory (UGA) for the shared server environment,
parallel execution message buffers (when PARALLEL_AUTOMATIC_TUNING is set to TRUE). It is also
used by the Recovery Manager (RMAN) for its functioning when the BACKUP_DISK_IO =n and
BACKUP_TAPE_IO_SLAVE=TRUE initialization parameters have been set. This pool does not use the
LRU algorithm.
The Java Pool This memory area is used by all session-specific Java code and data within the
Java Virtual Machine (JVM). Its size is determined by the JAVA_POOL_SIZE initialization parameter.
The Streams Pool This memory area is used by the Oracle Streams Product for its functioning.
Automatic Shared Memory Management
In Oracle 10g, a new feature known as Automatic Shared Memory Management has been introduced.
Using this feature all you need to specify is the total amount of memory that will be used by all the SGA
components. The database then uses this value to redistribute memory between the various memory
components based on the current workload. The parameter that needs to be configured for automatic
shared memory management is the SGA_TARGET initialization parameter. In Oracle 10g, the
SHARED_POOL_SIZE, LARGE_POOL_SIZE, JAVA_POOL_SIZE and DB_CACHE_SIZE are known as
the auto-tuned SGA parameters. If you set the value for SGA_TARGET to a value greater than zero then
the total amount of memory to be allocated for the auto-tuned parameters is obtained by subtracting the
SGA_TARGET value from the total amount of memory for manual SGA parameters.
Setting the SGA_TARGET to a value of zero will result in disabling automatic shared memory management.
The ASSM feature uses the MMAN background process, which is responsible for coordinating the sizes of
the various pools dynamically based on the current workload in the database.
Background Processes
The background processes of the Oracle instance are responsible for performing asynchronous I/O
functions between the Oracle Instance and the physical files of the Oracle database that exist on disk.
There are 5 mandatory background processes in Oracle 10g. These are the Database Writer (DBWR),
the Log Writer (LGWR), the Checkpoint process (CKPT), the System Monitor (SMON) and the Process
Monitor (PMON). Other background processes can be started based on certain additional functionality
required in the database. Given below is a list of the most commonly started background process and the
actions they are responsible for in the database.
Background Process Description and Function

This background process is mandatory. Its function is to

transfer modified blocks from the database buffer cache to the
datafiles. The DBWR writes to the datafiles when one of the following
events occur in the database:
Normal or incremental checkpoint
The number of dirty buffers reaches a pre-defined threshold value
The server process scans a pre-defined number of blocks looking
Database Writer
for free space needed by new blocks being read in.
(DBWR)
Timeout occurs
Tablespace is taken offline in normal or immediate mode.
Tablespace is made read-only
Dropping or truncating a table
Online backup is done on a tablespace using ALTER
TABLESPACE BEGIN BACKUP
command.

This background process is mandatory. It transfers redo

Log Writer (LGWR)
entries that have been written to the redo log buffer to the online redo
log files present on disk. The LGWR writes to the online redo log files
when one of the following events occur
in the database:
A commit is issued.
The Redo Log Buffer is one-third full.
 More than 1MB of changes (updations) has been made in the
database.
Every three seconds
Just before the DBWR writes from the database buffer cache to the
datafiles.

This background process is mandatory. When the contents of the

database buffer cache are transferred to the datafiles by the DBWR
background process, the event is referred to as a CHECKPOINT.
Checkpoint (CKPT) When a checkpoint occurs the Checkpoint (CKPT) background
process updates the headers of the datafiles and control files to
indicate the most recent checkpoint. This process is therefore
responsible for synchronizing the database.

This background process is mandatory. It is responsible for performing

recovery in the event of an instance failure. Instance failure occurs
during an abnormal shutdown of the database, such as if a shutdown
is performed using the ABORT option. During instance recovery the
SMON process performs a roll forward operation. During this step all
committed transactions that were not written out to the datafiles at the
System Monitor
time of failure were be completed. This step maybe followed by a
(SMON)
rollback during which time either the SMON or individual user
processes undo all the changes that were uncommitted during the time
of failure.
Certain additional functions performed by the System Monitor involve
coalescing of free space in dictionary-managed datafiles and releasing
temporary segments that are created in the datafiles.

This background process is mandatory. Users connect to the

Process Monitor database to access data. When a user connects to the database, a
(PMON) process known as a User process is started on behalf of the user on
the client machine. If the user terminates his/her session abnormally,
resources that were being used by the user session continue to remain
attached until the PMON background process cleans it up. The PMON
background process is responsible for cleaning the resources such
 locks on tables being held by failure user processes. The process also
restarts dead dispatcher processes.

This is an optional background process. It can be started when you

wish to operate the database in an archivelog mode. This mode of
database operation allows for complete recovery of the database in an
Archiver (ARCH)
event of a failure. The ARCH background process transfers the
contents of the online redo log files to archival media which could be
disk or tape.

The other optional processes in Oracle 10g are the :

CJQ0 Coordinator Job Queue background process
Dnnn Dispatcher process Pnnn Parallel Query Slaves QMNn Advanced Queuing RECO
Recoverer

Snnn Shared Server Processes

MMON Memory Monitor
MMAN and MMNL.

User Processes
A user trying to access data in the database needs to make a connection with the database using an
appropriate tool such as SQL*Plus, iSQL*Plus and a front-end database interface tool. A connection is a
communication pathway created between a user process and the Oracle Server. The user has to first supply
proper authentication credentials. Once the users credentials are validated a user session is established
and a user process is created on the client-side to act on behalf of the user. This process remains active
till the user completes the session. In the event that a user process is terminated abnormally the PMON
background process cleans up the resources that were held by the user process.
Server Processes
Server processes are created in Oracle to handle requests made by user processes. Server processes are
always started on the Server side. They are responsible for responding to the user process with appropriate
results. Based on the mode in which a database operates either a 1:1 ratio or m:n exists between user and
server processes. In Oracle, the instance can operate in one of two modes:
Dedicated server mode: Once a user process is started, a server process is created on behalf of the user
process. A one-to-one ratio is maintained between user and server processes. The server process
remains attached to the user process as long as the user process is active. The server process remains
idle during periods of inactivity. The server process is responsible for satisfying all requests made by the
user process and responding with appropriate results. The server process communicates with the Oracle
server using the Oracle Program Interface (OPI). The disadvantage of this is that in an OLTP
environment where there can be many thousands of users accessing the database simultaneously, a
large number of server processes would need to be active.
Shared Server Mode: In this environment a pool of shared server processes satisfy the required of user
processes. A one-to-one ratio is not maintained as in the dedicated server mode. A user process can be
serviced by any available server process. This mode of operating is particularly useful in large multi-user
online transaction processing (OLTP) environments, where many users concurrently access the
 database using short transactions. The shared server environment is discussed as a separate chapter
in this book.
The Program Global Area (PGA)
This is memory area that is associated with a server process. It contains data and control information held
by a single server process or background process. It is created when a user process is created and is
released when the user process is terminated. This memory area is not shared by server processes. The
contents of the PGA however vary in dedicated and shared server environments. The PGA is used to
process SQL statements and to hold logon and other session information. The contents of the PGA include:
Private SQL area contains bind information and runtime memory structures.
Each session that issues a SQL statement has a private SQL area. The private SQL area is in turn made
up the Persistent area that contains bind information and a Runtime area that is created as soon as an
execute request is initia In a dedicated server environment the Private SQL area is created in the
Program Global Area (PGA) of their server process. In a shared server environment, it is located in the
System Global area. The number of private SQL areas that a user process can allocate is limited to the
OPEN_CURSORS initialization parameter that takes a default value of 50.
Session Memory This is a memory area that holds a sessions variables and session-related inform In
a shard server environment, this memory area is located in the SGA and is shared by server processes.
SQL Work area This memory area is used for operations such as Sorting, Hash- joins, Bitmap Merge
and Bitmap Create operatio.
LAB SESSION
1)How to know the sga parameters values?
SQL>show parameter sga;
2)how to know the pga parameters values?
SQL>show parameter pga;
NOTE: Here ps means process status , e means extxa option , f means full list and grep menas PICK.
3)how to know the database is up or not from the root level?
SQL>ps ef | grep smon*;
4)how to know which users are connected to database?
SQL>ps ef | grep pmon*;
5) how to display all oracle background processes?
SQL>ps ef | grep ora_; (it displays all backgroung processes)
6)how to identify the sga&pga?
SQL>set wrap off
SQL>select * from v$sgastat;
7) How to identify the dispatcher threads?
SQL>show parameter dispatchers;
8) How to identify shared server processes?
SQL>show parameter shared_server_processes;