Resize sga

Oracle DBA Course
(9i, 10g, 11g)
Lecture 1:
Oracle Architectural Components

1-1

Copyright © Oracle Corporation, 1998, 2001. All rights reserved.

Oracle Documentation
http://tahiti.oracle.com/

1-2


Objectives of the DBA course
Identify the various components of the
Oracle architecture.
•

•

Learn how to:
•

start and shut down an Oracle database,

•

create an operational database,

• manage Oracle control files, redo log
files, database files, tablespaces,
segments, extents,
• manage users, privileges, and
resources,
•
1-3

use Globalization Support features.

Objectives of Lecture 1
• Overview of Oracle server architecture,
identifying main components.
• Presentation of English and Polish Oracle
server terminology.

1-4


The Oracle Server
Oracle server

Application/
network
server

Server
1-5


Users

Oracle server
The Oracle server consists of:
•

Oracle database - physical files that store
data
•

Oracle instance - memory structures and
Oracle processes used to access data (from the
physical database files)

1-6


Oracle Database
An Oracle database consists of operating system
files, known as database files, that provide
the actual physical storage for database
information. The database files are used to
ensure that the data is kept consistent and can
be recovered in the event of a failure of the
instance.
Usually there is only one Oracle instance
accessing a database. In the Real Application
Cluster configuration multiple instances access
a single database.
1-7


Oracle Database
Physical Storage Structures
Control and
redo log files
are
multiplexed

Control
files
Parameter
file
Password
file

Data files

Redo log
files

Database

1-8


Archived
log files
+ Backup files,
trace and alert
files, audit files,
…

Other Key Physical Structures

Parameter
file

Password
file

1-9

Database


Archived
log files

Connecting to a Database
Client

Connection
established

User
process

Server
process

Server
Session created
Oracle server

User

1-10


User Process
• Runs on the client machine
• Is spawned when a tool or an application
is invoked
• Runs the tool or application (SQL*Plus,
Oracle Enterprise Manager, OracleForms)
• Generates calls to the Oracle server

1-11


Connection
Connection is a communication pathway
between a user process and an Oracle
Database instance. A communication pathway
is established using:
1. available interprocess communication
mechanisms (on a computer that runs both
the user process and Oracle Database) or
2. network software (when different computers
run the database application and Oracle
Database, and communicate through a
network).
1-12


Session
Session is a specific connection of a user to an Oracle
Database instance through a user process. For example,
when a user starts SQL*Plus, the user must provide a
valid user name and password, and then a session is
established for that user. A session lasts from the time
the user connects until the time the user disconnects or
exits the database application.
Multiple sessions can be created and exist concurrently
for a single Oracle Database user using the same user
name.
• For example, a user with the user name/password of
SCOTT/TIGER can connect to the same Oracle Database instance
several times.
1-13


Server Process
• Runs on the server machine (host)
• Services a single user process in the
dedicated server configuration
• Uses an exclusive Program Global Area
(PGA)
• Processes calls generated by the client
• Returns results to the client

1-14


Oracle Instance
Instance
SGA

SGA System Global Area
Background processes

An Oracle instance:
• Is a means to access an Oracle
database
• Always opens one and only one
database
1-15


Oracle Memory Structures
+ Streams
Pool in 10g
+ Result
cache in 11g

1-16


System Global Area (SGA)
Used to store database information that is shared by
database processes. It contains data and control
information for the Oracle server and is allocated in
the virtual memory of the computer where Oracle
resides.
SHOW SGA;
Total System Global Area 36437964 bytes
Fixed Size 6543794 bytes
Variable Size 19521536 bytes
Database Buffers 16777216 bytes
Redo Buffers 73728 bytes
1-17


Dynamic SGA
Dynamic SGA implements an infrastructure that
allows the SGA configuration to change without
shutting down the instance. This then allows
the sizes of the database buffer cache, shared
pool, and large pool to be changed without
shutting down the instance. Conceivably, they
could be initially under configured and would
grow and shrink depending upon their
respective work loads, up to a maximum of
SGA_MAX_SIZE.
1-18


Sizing the SGA
The size of the SGA is determined by several
initialization parameters, including:
DB_CACHE_SIZE: The size of the default cache of
database blocks.
LOG_BUFFER: The number of bytes allocated for
the redo log buffer cache.
SHARED_POOL_SIZE: The size in bytes of the
area devoted to shared SQL and PL/SQL.
LARGE_POOL_SIZE: The size of the large pool;
the default is zero.
1-19


System Global Area (SGA)
SGA memory allocated and tracked in
granules by SGA components.
A granule is a unit of contiguous
virtual memory allocation. The size of a
granule depends on the parameter
SGA_MAX_SIZE:
– 4 MB if estimated SGA size is < 128 MB
– 16 MB otherwise
1-20


The Shared Pool
Shared pool
Library
cache
Data
dictionary
cache

• Size defined by SHARED_POOL_SIZE
• Library cache contains statement text,
parsed code, and an execution plan
• Data dictionary cache contains table
and column definitions and privileges
1-21


Resizing
The size of Shared Pool can be
dynamically resized using ALTER SYSTEM
SET. After performance analysis can be
adjusted (but the total SGA size cannot
exceed SGA_MAX_SIZE):
ALTER SYSTEM SET
SHARED_POOL_SIZE = 64M;

1-22


Library Cache
1. Stores information about the most recently
used SQL and PL/SQL statements:
•
Enables the sharing of commonly used
statements
2.

Consists of two structures:
•

Shared SQL area

•

Shared PL/SQL area

3. Has its size determined by the shared pool
sizing
1-23


The library cache consists of two structures:
• Shared SQL: The Shared SQL stores and
shares the execution plan and parse tree for
SQL statements run against the database. The
second time that an identical SQL statement
is run, it is able to take advantage of the
parse information available in the shared SQL
to expedite its execution. To ensure that SQL
statements use a shared SQL area whenever
possible, the text, schema, and bind
variables must be exactly the same.
• Shared PL/SQL: The shared PL/SQL area
stores and shares the most recently executed
PL/SQL statements. Parsed and compiled
program units and procedures (functions,
packages, and triggers) are Allstored in this
Copyright © Oracle Corporation, 1998, 2001.
rights reserved.
1-24
area.

Data Dictionary Cache
It is a collection of the most recently used
definitions in the database.
It includes information about database files,
tables, indexes, columns, users, privileges,
and other database objects.
During the parse phase, the server process
looks at the data dictionary for information
to resolve object names and validate access.
Caching the data dictionary information into
memory improves response time on queries.
Size is determined by the shared pool sizing.
1-25


Sizing the Data Dictionary
The overall size is dependent on the size of
the shared pool size and is managed
internally by the database. If the data
dictionary cache is too small, then the
database has to query the data dictionary
tables repeatedly for information needed by
the database. These queries are called
recursive calls and are slower than the
queries that are handled by the data
dictionary cache.

1-26


Database Buffer Cache

• Stores the most recently used blocks that
have been retrieved from the data files.
• DB_BLOCK_SIZE determines the primary
block size.
1-27


Multiple Block Sizes
An Oracle database can be created
with a standard block size and up to
four non-standard block sizes. Nonstandard block sizes can have any
power-of-two value between 2 KB and
32 KB.

1-28


Database Buffer Cache
Consists of three independent sub-caches:
•

DEFAULT Buffer Pool - DB_CACHE_SIZE

•

KEEP Buffer Pool - DB_KEEP_CACHE_SIZE

•

RECYCLE Buffer Pool - DB_RECYCLE_CACHE_SIZE

Database buffer cache can be dynamically
resized to grow or shrink using ALTER SYSTEM
ALTER SYSTEM SET DB_CACHE_SIZE = 96M;

1-29


Buffer Cache Advisory Parameter
DB_CACHE_ADVICE can be set to gather
statistics for predicting different cache size
behavior (values: OFF, READY, ON).
The information provided by these statistics
can help DBA size the buffer cache optimally
for a given workload.
The buffer cache advisory information is
collected and displayed through the
V$DB_CACHE_ADVICE view.

1-30


Types of buffers
Dirty - changed and has not yet been written to the
disk.
Cold - that has not been recently used according to
the least recently used (LRU) algorithm.
Free - contain no data or are free to be overwritten.
Pinned - currently being accessed or explicitely
retained for future use (e.g. the KEEP buffer pool).
1-31


Two lists of buffers
Write list (dirty buffer list) - buffers that are
modified and need to be written to the disk.
Least recently used list (LRU) - free buffers,
pinned buffers and the dirty buffers that have
not yet been moved to the Write List. The most
recently accessed blocks are always in the front
(MRU end); the least recently accessed blocks,
in the end (LRU end).

1-32


LRU list
The least-used blocks are thrown out of the list
when new blocks are accessed and added to the
MRU end of the list. With one exception – when a
full table is scanned – the blocks are written to the
LRU end of the list.
When an Oracle process accesses a buffer, it
moves the buffer to the MRU end of the list so that
the most frequently accessed data is available in
the buffers.
1-33


LRU list
When an Oracle process requests data, it searches
the data in the buffer cache – if it finds, we get
cache hit. If not – cache miss – data needs to be
copied from disk to the buffer.
The server process searches (from the LRU end)
until it finds a free buffer or until it has searched a
threshold limit of buffers. It moves encountered
dirty buffers to the write list. If it does not find a
free buffer – DBWn writes some buffers from write
list to disk – making available free buffers for the
server process.
1-34


Redo Log Buffer Cache

• Size defined by LOG_BUFFER
• Records changes made through the
instance
• Used sequentially
• Circular buffer
1-35


Redo Log Buffer Cache
• The redo log buffer cache records all
changes made to the database data blocks.
•

Its primary purpose is recovery.

• Changes recorded within are called redo
entries.
• Redo entries contain information to
reconstruct or redo changes.

1-36


Result cache (11g)
The result cache buffers query results. If a
query is run that already has results in the
result cache, the database returns results from
the result cache instead of rerunning the query.
This speeds up the execution of frequently run
queries.
The database automatically invalidates a
cached result whenever a transaction modifies
the data or metadata of any of the database
objects used to construct that cached result.
1-37


Result cache (11g)

Users can annotate a query or query fragment
with a result cache hint to indicate that results
are to be stored in the SQL query result cache.
You can set the RESULT_CACHE_MODE
initialization parameter to control whether the
SQL query result cache is used for all queries
(when possible), or only for queries that are
annotated.
1-38


PL/SQL Function Result Cache
A PL/SQL function may depend on several parameters. In
some cases, the SQL statements in the function body
access data (for example, the catalog of wares in a
shopping application) that changes very infrequently
compared to the frequency of calling the function.
The look-up key for the cache is the combination of
actual arguments with which the function is invoked.
When a particular invocation of the result-cached
function is a cache hit, then the function body is not
executed; instead, the cached value is returned
immediately.
1-39


Large Pool
The large pool is an optional area of memory
in the SGA configured only in a shared server
environment.
It relieves the burden placed on the shared
pool.
This configured memory area is used for
session memory (UGA), I/O slaves, and backup
and restore operations.
Unlike the shared pool, the large pool does
not use an LRU list.
Sized by LARGE_POOL_SIZE
ALTER SYSTEM SET LARGE_POOL_SIZE = 64M;

1-40


Java Pool
The Java pool services the parsing
requirements for Java commands.
Required if installing and using Java.
It is sized by the JAVA_POOL_SIZE parameter.
In Oracle9i, the default size of the Java Pool
is 24M.

1-41


Streams Pool (10g)
Oracle Streams enables information sharing.
Using Oracle Streams, each unit of shared
information is called a message, and you can
share these messages in a stream. The stream
can propagate information within a database or
from one database to another. The stream
routes specified information to specified
destinations. They are used for distributed
databases, applications and data warehouses.
The size of the Streams pool starts at zero.
The pool size grows dynamically as needed.
1-42


Program Global Area (PGA)
• Not shared
Contains:
• Sort area

Server
process

PGA

SORT_AREA_SIZE

Memory region that
– Sort area size can growcontains data and control
depending on the need.information for a single
server process or a single
• Session information background process. The
PGA is allocated when a
• Cursor state
process is created and
• Stack space
deallocated when the
process is terminated.
1-43


PGA
The total memory used by all individual PGAs
is known as the total instance PGA memory,
and the collection of individual PGAs is
referred to as the total instance PGA, or just
instance PGA. With Oracle Enterprise Manager
Database Control, you set the size of the
instance PGA, not individual PGAs.

1-44


Summary

1-45


Oracle Processes

+ Management
Monitor
MMON in 11g

1-46


Server process
Oracle Database creates server processes to handle the
requests of user processes connected to the instance. In
some situations when the application and Oracle
Database operate on the same computer, it is possible to
combine the user process and corresponding server
process into a single process to reduce system
overhead.
However, when the application and Oracle Database
operate on different computers, a user process always
communicates with Oracle Database through a separate
server process.
1-47


Server process
Server processes (or the server portion of combined
user/server processes) created on behalf of each user's
application can perform one or more of the following:
• Parse and run SQL statements issued through the
application
• Read necessary data blocks from datafiles on disk into
the shared database buffers of the SGA, if the blocks are
not already present in the SGA
• Return results in such a way that the application can
process the information
1-48


Database Writer (DBWn, n=0,…,19)
Instance
SGA

Shared pool

Database
buffer
cache

DBWR

Data files

1-49

Control
files

Redo log
files


The server process records changes to
rollback and data blocks in the buffer
cache. Database Writer (DBWn) writes
the cold, dirty buffers from the
database buffer cache to the data
files. It ensures that a sufficient
number of free buffers — buffers that
can be overwritten when server
processes need to read in blocks from
the data files —are available in the
database buffer cache. Database
performance is improved because server
processes make changes only in the
buffer cache.
1-50
1-50

DBWn defers writing to the data files until
one of the following events occurs:
• Checkpoint
• The number of dirty buffers reaches a
threshold value
• A process scans a specified number of blocks
when scanning for free buffers and cannot find
any.
• Placing a tablespace in read only or offline
mode.
• Dropping or truncating a table.
• ALTER TABLESPACE tablespace_name BEGIN BACKUP;
1-51


Log Writer (LGWR)
Instance
SGA

Shared pool

Redo log
buffer

LGWR

Data files

1-52

Control
files

Redo log
files


LGWR performs sequential writes from the redo log
buffer cache to the redo log file under the
following situations:
• When a transaction commits
• When the redo log buffer cache is one-third full
• When there is more than a megabyte of changes
records in the redo log buffer cache
• Before DBWn writes modified blocks in the
database buffer cache to the data files
• Every 3 seconds.
Because the redo is needed for recovery, LGWR
confirms the commit only after the redo is written
to disk.
1-53


COMMIT Processing
1

Instance
SGA

Server
process

4

Database
buffer
cache

Shared pool

Redo log
buffer

LGWR

3
User
process

2
Data files

Control
files

SCN - System Change Number Database
represents the state of data after
the COMMIT - assigned to data
1-54
blocks.

Redo log
files

System Monitor
(SMON)

If the Oracle instance fails, any information
in the SGA that has not been written to disk
is lost. For example, the failure of the
operating system causes an instance failure.
After the loss of the instance, the
background process SMON automatically
performs instance recovery when the database
is reopened.
1-55


1. Rolling forward to recover data that has not
been recorded in the data files but that has been
recorded in the online redo log. This data has not
been written to disk because of the loss of the
SGA during instance failure. During this process,
SMON reads the redo log files and applies the
changes recorded in the redo log to the data
blocks. Because all committed transactions have
been written to the redo logs, this process
completely recovers these transactions.
2. Opening the database so that users can log on.
Any data that is not locked by unrecovered
transactions is immediately available.
3. Rolling back uncommitted transactions. They are
rolled back by SMON or by the individual server
processes as they access locked data.
1-56


Process Monitor
(PMON)

The background process PMON cleans up after
failed processes by:
• Rolling back the user’s current transaction
• Releasing all currently held table or row
locks
• Freeing other resources currently reserved
by the user
1-57


Checkpoint
Event

An event called a checkpoint :: the Oracle
background process DBWn writes all the
modified database buffers in the SGA,
including both committed and uncommitted data,
to the data files. Helps to reduce the time
required for instance recovery.
1-58


Checkpoint Process (CKPT)
• Writes checkpoint number into the
data file headers
• Writes checkpoint number, log
sequence number, archived log names,
and system change numbers into the
control file.
CKPT itself does not write data blocks
to disk or redo blocks to the online
redo logs - DBWn does.
1-59


Archiver (ARCn)

Optional background process which
automatically archives online redo
logs when ARCHIVELOG mode is set
Preserves the record of all changes
made to the database

1-60


ARCn, is crucial to recovering a database
after the loss of a disk. As online redo log
files fill, the Oracle server begins writing
to the next online redo log file. The process
of switching from one redo log to another is
called a log switch. The ARCn process
initiates backing up, or archiving, of the
filled log group at every log switch. It
automatically archives the online redo log
before the log can be reused, so that all of
the changes made to the database are
preserved. This enables the DBA to recover the
database to the point of failure, even if a
disk drive is damaged.
1-61


NOARCHIVELOG mode
The online redo log files are
overwritten each time a log switch
occurs. LGWR does not overwrite a redo
log group until the checkpoint for that
group is complete. This ensures that
committed data can be recovered if
there is an instance crash. During the
instance crash, only the SGA is lost.
There is no loss of disks, only memory.
For example, an operating system crash
causes an instance crash.
1-62


Dispatcher (Dnnn)
Part of the shared server architecture. They
minimize the resource needs by handling
multiple connections to the database using a
limited number of server processes.
When a user makes a request, the dispatcher
places the request on the request queue.

1-63


Shared Server (Snnn)
Shared server serves multiple user processes.
When the instance starts, Oracle starts a fixed
number of server processes working in a roundrobin fashion to serve requests from the user
processes - placed by the dispatcher into the
request queue.
The results are put into the response queue, to
be taken by the dispatcher.
1-64


Job Queue Processes
Job queue processes are used for batch
processing. They run user jobs. They can be
viewed as a scheduler service that can be used
to schedule jobs as PL/SQL statements or
procedures on an Oracle Database instance.
Given a start date and an interval, the job queue
processes try to run the job at the next
occurrence of the interval.

1-65


Logical storage
structures
• An Oracle database is a
group of tablespaces.
• A tablespace may consist of
one or more segments. At
least: SYSTEM (in 10g also
SYSAUX).
• A segment is made up of extents.
• An extent is made up of logical contiguous
blocks allocated in one chunk.
• A block is the smallest unit for read and write
operations - a multiple of the SO block size.
1-66


Logical/physical/recovery-related
structures of the database

1-67


Types of segments
Data segments - store the table (or cluster) data.
Index segments - store the index data.
Temporary segments - temporary work area e.g.
for sorting, executing SQL statements.
Undo (rollback) segments - store undo
information. When you roll back changes made
to the database, undo records in the undo
tablespace are used to undo the changes.
1-68


Undo (Rollback) Segment
Old
image

Table

New
image

Undo
segment
DML
statement
1-69


Review of physical storage structures
Data files - contain all the database data. Each data file is
associated with one and only one tablespace.
Redo log files - record changes made to data. There must
be at least 2 redo log files because of a circular fashion of
using them. If a failure prevents the database change from
being written to a data file, the changes can be obtained
from the redo log files. Multiplexing of redo logs maintaining mutiple copies of redo log files (preferably on
distinct disks) - called a redo log group.
Control files - basic information about the physical
structure of the database such as the database name,
locations of every data file and redo log file (usually
multiplexed).
1-70


Summary
Instance
SGA

Shared pool

Server
process

PGA

User
process

DBWR

Control
files

Parameter
file

Password
file

LGWR

Redo log
files

Data files

Database
1-71


Archived
log files

Resize sga

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Resize sga

Similar to Resize sga (20)

More from Hitesh Kumar Markam

More from Hitesh Kumar Markam (18)

Recently uploaded

Recently uploaded (20)

Resize sga

Editor's Notes