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

1-1

Copyright © Oracle Corporation, 1998, 20...
Oracle Documentation
http://tahiti.oracle.com/

1-2

Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
Objectives of the DBA course
Identify the various components of the
Oracle architecture.
•

•

Learn how to:
•

start and ...
Objectives of Lecture 1
• Overview of Oracle server architecture,
identifying main components.
• Presentation of English a...
The Oracle Server
Oracle server

Application/
network
server

Server
1-5

Copyright © Oracle Corporation, 1998, 2001. All ...
Oracle server
The Oracle server consists of:
•

Oracle database - physical files that store
data
•

Oracle instance - memo...
Oracle Database
An Oracle database consists of operating system
files, known as database files, that provide
the actual ph...
Oracle Database
Physical Storage Structures
Control and
redo log files
are
multiplexed

Control
files
Parameter
file
Passw...
Other Key Physical Structures

Parameter
file

Password
file

1-9

Database

Copyright © Oracle Corporation, 1998, 2001. A...
Connecting to a Database
Client

Connection
established

User
process

Server
process

Server
Session created
Oracle serve...
User Process
• Runs on the client machine
• Is spawned when a tool or an application
is invoked
• Runs the tool or applica...
Connection
Connection is a communication pathway
between a user process and an Oracle
Database instance. A communication p...
Session
Session is a specific connection of a user to an Oracle
Database instance through a user process. For example,
whe...
Server Process
• Runs on the server machine (host)
• Services a single user process in the
dedicated server configuration
...
Oracle Instance
Instance
SGA

SGA System Global Area
Background processes

An Oracle instance:
• Is a means to access an O...
Oracle Memory Structures
+ Streams
Pool in 10g
+ Result
cache in 11g

1-16

Copyright © Oracle Corporation, 1998, 2001. Al...
System Global Area (SGA)
Used to store database information that is shared by
database processes. It contains data and con...
Dynamic SGA
Dynamic SGA implements an infrastructure that
allows the SGA configuration to change without
shutting down the...
Sizing the SGA
The size of the SGA is determined by several
initialization parameters, including:
DB_CACHE_SIZE: The size ...
System Global Area (SGA)
SGA memory allocated and tracked in
granules by SGA components.
A granule is a unit of contiguous...
The Shared Pool
Shared pool
Library
cache
Data
dictionary
cache

• Size defined by SHARED_POOL_SIZE
• Library cache contai...
Resizing
The size of Shared Pool can be
dynamically resized using ALTER SYSTEM
SET. After performance analysis can be
adju...
Library Cache
1. Stores information about the most recently
used SQL and PL/SQL statements:
•
Enables the sharing of commo...
The library cache consists of two structures:
• Shared SQL: The Shared SQL stores and
shares the execution plan and parse ...
Data Dictionary Cache
It is a collection of the most recently used
definitions in the database.
It includes information ab...
Sizing the Data Dictionary
The overall size is dependent on the size of
the shared pool size and is managed
internally by ...
Database Buffer Cache

• Stores the most recently used blocks that
have been retrieved from the data files.
• DB_BLOCK_SIZ...
Multiple Block Sizes
An Oracle database can be created
with a standard block size and up to
four non-standard block sizes....
Database Buffer Cache
Consists of three independent sub-caches:
•

DEFAULT Buffer Pool - DB_CACHE_SIZE

•

KEEP Buffer Poo...
Buffer Cache Advisory Parameter
DB_CACHE_ADVICE can be set to gather
statistics for predicting different cache size
behavi...
Types of buffers
Dirty - changed and has not yet been written to the
disk.
Cold - that has not been recently used accordin...
Two lists of buffers
Write list (dirty buffer list) - buffers that are
modified and need to be written to the disk.
Least ...
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 lis...
LRU list
When an Oracle process requests data, it searches
the data in the buffer cache – if it finds, we get
cache hit. I...
Redo Log Buffer Cache

• Size defined by LOG_BUFFER
• Records changes made through the
instance
• Used sequentially
• Circ...
Redo Log Buffer Cache
• The redo log buffer cache records all
changes made to the database data blocks.
•

Its primary pur...
Result cache (11g)
The result cache buffers query results. If a
query is run that already has results in the
result cache,...
Result cache (11g)

Users can annotate a query or query fragment
with a result cache hint to indicate that results
are to ...
PL/SQL Function Result Cache
A PL/SQL function may depend on several parameters. In
some cases, the SQL statements in the ...
Large Pool
The large pool is an optional area of memory
in the SGA configured only in a shared server
environment.
It reli...
Java Pool
The Java pool services the parsing
requirements for Java commands.
Required if installing and using Java.
It is ...
Streams Pool (10g)
Oracle Streams enables information sharing.
Using Oracle Streams, each unit of shared
information is ca...
Program Global Area (PGA)
• Not shared
Contains:
• Sort area

Server
process

PGA

SORT_AREA_SIZE

Memory region that
– So...
PGA
The total memory used by all individual PGAs
is known as the total instance PGA memory,
and the collection of individu...
Summary

1-45

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

+ Management
Monitor
MMON in 11g

1-46

Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
Server process
Oracle Database creates server processes to handle the
requests of user processes connected to the instance...
Server process
Server processes (or the server portion of combined
user/server processes) created on behalf of each user's...
Database Writer (DBWn, n=0,…,19)
Instance
SGA

Shared pool

Database
buffer
cache

DBWR

Data files

1-49

Control
files

...
The server process records changes to
rollback and data blocks in the buffer
cache. Database Writer (DBWn) writes
the cold...
DBWn defers writing to the data files until
one of the following events occurs:
• Checkpoint
• The number of dirty buffers...
Log Writer (LGWR)
Instance
SGA

Shared pool

Redo log
buffer

LGWR

Data files

1-52

Control
files

Redo log
files

Copyr...
LGWR performs sequential writes from the redo log
buffer cache to the redo log file under the
following situations:
• When...
COMMIT Processing
1

Instance
SGA

Server
process

4

Database
buffer
cache

Shared pool

Redo log
buffer

LGWR

3
User
pr...
System Monitor
(SMON)

If the Oracle instance fails, any information
in the SGA that has not been written to disk
is lost....
1. Rolling forward to recover data that has not
been recorded in the data files but that has been
recorded in the online r...
Process Monitor
(PMON)

The background process PMON cleans up after
failed processes by:
• Rolling back the user’s current...
Checkpoint
Event

An event called a checkpoint :: the Oracle
background process DBWn writes all the
modified database buff...
Checkpoint Process (CKPT)
• Writes checkpoint number into the
data file headers
• Writes checkpoint number, log
sequence n...
Archiver (ARCn)

Optional background process which
automatically archives online redo
logs when ARCHIVELOG mode is set
Pre...
ARCn, is crucial to recovering a database
after the loss of a disk. As online redo log
files fill, the Oracle server begin...
NOARCHIVELOG mode
The online redo log files are
overwritten each time a log switch
occurs. LGWR does not overwrite a redo
...
Dispatcher (Dnnn)
Part of the shared server architecture. They
minimize the resource needs by handling
multiple connection...
Shared Server (Snnn)
Shared server serves multiple user processes.
When the instance starts, Oracle starts a fixed
number ...
Job Queue Processes
Job queue processes are used for batch
processing. They run user jobs. They can be
viewed as a schedul...
Logical storage
structures
• An Oracle database is a
group of tablespaces.
• A tablespace may consist of
one or more segme...
Logical/physical/recovery-related
structures of the database

1-67

Copyright © Oracle Corporation, 1998, 2001. All rights...
Types of segments
Data segments - store the table (or cluster) data.
Index segments - store the index data.
Temporary segm...
Undo (Rollback) Segment
Old
image

Table

New
image

Undo
segment
DML
statement
1-69

Copyright © Oracle Corporation, 1998...
Review of physical storage structures
Data files - contain all the database data. Each data file is
associated with one an...
Summary
Instance
SGA

Shared pool

Server
process

PGA

User
process

DBWR

Control
files

Parameter
file

Password
file

...
Upcoming SlideShare
Loading in …5
×

Resize sga

549 views

Published on

Published in: Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
549
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
32
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • There are several files, processes, and memory structures in an Oracle server; not all of them are used when processing a SQL statement. Some are used to improve the performance of the database, ensure that the database can be recovered in the event of a software or hardware error, or perform other tasks necessary to maintain the database.
  • The parameter file defines the characteristics of an Oracle instance. For example, it contains parameters that size some of the memory structures in the SGA.
    • The password file authenticates users privileged to start up and shut down an Oracle instance.
    Archived redo log files are offline copies of the redo log files that may be necessary to recover from media failures.
  • The client machine communicates the request to the server machine by using OracleNet drivers. The OracleNet listener on the server detects the request and starts a dedicated server process on behalf of the user process after veryfying the username and password.
  • 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.
    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
  • An Oracle instance is the combination of the background processes and memory structures. Every time an instance is started, a System Global Area (SGA) is allocated and Oracle background processes are started.
    Background processes perform functions on behalf of the invoking process. They consolidate functions that would otherwise be handled by multiple Oracle programs running for each user. The background processes perform input/output (I/O) and monitor other Oracle processes to provide increased parallelism for better performance and reliability.
  • At instance startup, the Oracle server allocates granule entries, one for each granule. As startup continues, each component acquires as many granules as it requires. The minimum SGA configuration is three granules:
    one granule for fixed SGA (includes redo buffers);
    one granule for buffer cache;
    one granule for shared pool.
  • The library cache size is based on the sizing defined for the shared pool. Memory is allocated when a statement is parsed or a program unit is called. If the size of the shared pool is too small, statements are continually reloaded into the library cache, which affects performance.
    The library cache is managed by a least recently used (LRU) algorithm. As the cache fills, less recently used execution paths and parse trees are removed from the library cache to make room for the new entries. If the SQL or PL/SQL statements are not reused, they eventually are aged out.
  • Caching data dictionary information into memory improves response time. Information about the database (user account data, data file names, segment names, extent locations, table descriptions, and user privileges) is stored in the data dictionary tables. When this information is needed by the database, the data dictionary tables are read, and the data that is returned is stored in the data dictionary cache.
  • When a query is processed, the Oracle server process looks in the database buffer cache for any blocks it needs. If the block is not found in the database buffer cache, the server process reads the block from the data file and places a copy in the database buffer cache. Because subsequent requests for the same block may find the block in memory, the requests may not require physical reads. The Oracle server uses a least recently used algorithm to age out buffers that have not been accessed recently to make room for new blocks in the database buffer cache.
  • Three parameters define the sizes of the buffer caches:
    DB_CACHE_SIZE: Sizes the default buffer cache size only, it always exists and cannot be set to zero.
    DB_KEEP_CACHE_SIZE: Sizes the keep buffer cache, which is used to retain blocks in memory that are likely to be reused.
    DB_RECYCLE_CACHE_SIZE: Sizes the recycle buffer cache, which is used to eliminate blocks from memory that have little chance of being reused.
  • When a buffer in the database buffer cache is modified, it is marked dirty. A cold buffer is a buffer that has not been recently used according to the least recently used (LRU) algorithm. The DBWn process writes cold, dirty buffers to disk so that user processes are able to find cold, clean buffers that can be used to read new blocks into the cache. As buffers are dirtied by user processes, the number of free buffers diminishes. If the number of free buffers drops too low, user processes that must read blocks from disk into the cache are not able to find free buffers. DBWn manages the buffer cache so that user processes can always find free buffers.
    By writing cold, dirty buffers to disk, DBWn improves the performance of finding free buffers while keeping recently used buffers resident in memory. For example, blocks that are part of frequently accessed small tables or indexes are kept in the cache so that they do not need to be read in again from disk. The LRU algorithm keeps more frequently accessed blocks in the buffer cache so that when a buffer is written to disk, it is unlikely to contain data that will be useful soon.
  • The buffers in the cache are organized in two lists: the write list and the least recently used (LRU) list. The write list holds dirty buffers, which contain data that has been modified but has not yet been written to disk. The LRU list holds free buffers, pinned buffers, and dirty buffers that have not yet been moved to the write list. Free buffers do not contain any useful data and are available for use. Pinned buffers are currently being accessed.
    When an Oracle process accesses a buffer, the process moves the buffer to the most recently used (MRU) end of the LRU list. As more buffers are continually moved to the MRU end of the LRU list, dirty buffers age toward the LRU end of the LRU list.
    The first time an Oracle user process requires a particular piece of data, it searches for the data in the database buffer cache. If the process finds the data already in the cache (a cache hit), it can read the data directly from memory. If the process cannot find the data in the cache (a cache miss), it must copy the data block from a datafile on disk into a buffer in the cache before accessing the data. Accessing data through a cache hit is faster than data access through a cache miss.
    Before reading a data block into the cache, the process must first find a free buffer. The process searches the LRU list, starting at the least recently used end of the list. The process searches either until it finds a free buffer or until it has searched the threshold limit of buffers.
    If the user process finds a dirty buffer as it searches the LRU list, it moves that buffer to the write list and continues to search. When the process finds a free buffer, it reads the data block from disk into the buffer and moves the buffer to the MRU end of the LRU list.
    If an Oracle user process searches the threshold limit of buffers without finding a free buffer, the process stops searching the LRU list and signals the DBW0 background process to write some of the dirty buffers to disk.
    When the user process is performing a full table scan, it reads the blocks of the table into buffers and puts them on the LRU end (instead of the MRU end) of the LRU list. This is because a fully scanned table usually is needed only briefly, so the blocks should be moved out quickly to leave more frequently used blocks in the cache.
    You can control this default behavior of blocks involved in table scans on a table-by-table basis. To specify that blocks of the table are to be placed at the MRU end of the list during a full table scan, use the CACHE clause when creating or altering a table or cluster. You can specify this behavior for small lookup tables or large static historical tables to avoid I/O on subsequent accesses of the table.
  • The Java pool memory is used for all session-specific Java code and data within the Java Virtual Machine (JVM)
  • 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.
    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
  • Although one database writer process (DBW0) is adequate for most systems, you can configure additional processes (DBW1 through DBW9 and DBWa through DBWj) to improve write performance if your system modifies data heavily. These additional DBWn processes are not useful on uniprocessor systems.
  • When a buffer in the database buffer cache is modified, it is marked dirty. A cold buffer is a buffer that has not been recently used according to the least recently used (LRU) algorithm. The DBWn process writes cold, dirty buffers to disk so that user processes are able to find cold, clean buffers that can be used to read new blocks into the cache. As buffers are dirtied by user processes, the number of free buffers diminishes. If the number of free buffers drops too low, user processes that must read blocks from disk into the cache are not able to find free buffers. DBWn manages the buffer cache so that user processes can always find free buffers.
    By writing cold, dirty buffers to disk, DBWn improves the performance of finding free buffers while keeping recently used buffers resident in memory. For example, blocks that are part of frequently accessed small tables or indexes are kept in the cache so that they do not need to be read in again from disk. The LRU algorithm keeps more frequently accessed blocks in the buffer cache so that when a buffer is written to disk, it is unlikely to contain data that will be useful soon.
  • Checkpoints are implemented for the following reasons:
    • Checkpoints ensure that data blocks in memory that change frequently are written to data files regularly. Because of the least recently used algorithm of DBWn, a data block that changes frequently might never qualify as the least recently used block and thus might never be written to disk if checkpoints did not occur.
    • Because all database changes up to the checkpoint have been recorded in the data files, redo log entries before the checkpoint no longer need to be applied to the data files if instance recovery is required. Therefore, checkpoints are useful because they can expedite instance recovery.
  • If you anticipate a heavy workload for archiving, such as during bulk loading of data, you can increase the maximum number of archiver processes with the LOG_ARCHIVE_MAX_PROCESSES initialization parameter. The ALTER SYSTEM statement can change the value of this parameter dynamically to increase or decrease the number of ARCn processes.
  • This diagram shows the logical, physical, and recovery-related structures of the database, and the relationships between them. Dotted horizontal lines divide the image into three sections. The top section shows logical structures, the middle section shows physical structures, and the bottom section shows recovery-related structures in the Flash Recovery Area.
    The logical structures are all tablespaces. Each tablespace points to a datafile or tempfile, which are physical structures. Other physical structures include a control file, the online redo log files, a server parameter file, and a password file.
    The flash recovery area contains the archived redo log files, which are copies of redo log files after they are filled.
  • Resize sga

    1. 1. Oracle DBA Course (9i, 10g, 11g) Lecture 1: Oracle Architectural Components 1-1 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    2. 2. Oracle Documentation http://tahiti.oracle.com/ 1-2 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    3. 3. 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. Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    4. 4. Objectives of Lecture 1 • Overview of Oracle server architecture, identifying main components. • Presentation of English and Polish Oracle server terminology. 1-4 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    5. 5. The Oracle Server Oracle server Application/ network server Server 1-5 Copyright © Oracle Corporation, 1998, 2001. All rights reserved. Users
    6. 6. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    7. 7. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    8. 8. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved. Archived log files + Backup files, trace and alert files, audit files, …
    9. 9. Other Key Physical Structures Parameter file Password file 1-9 Database Copyright © Oracle Corporation, 1998, 2001. All rights reserved. Archived log files
    10. 10. Connecting to a Database Client Connection established User process Server process Server Session created Oracle server User 1-10 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    11. 11. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    12. 12. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    13. 13. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    14. 14. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    15. 15. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    16. 16. Oracle Memory Structures + Streams Pool in 10g + Result cache in 11g 1-16 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    17. 17. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    18. 18. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    19. 19. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    20. 20. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    21. 21. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    22. 22. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    23. 23. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    24. 24. 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.
    25. 25. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    26. 26. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    27. 27. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    28. 28. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    29. 29. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    30. 30. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    31. 31. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    32. 32. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    33. 33. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    34. 34. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    35. 35. Redo Log Buffer Cache • Size defined by LOG_BUFFER • Records changes made through the instance • Used sequentially • Circular buffer 1-35 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    36. 36. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    37. 37. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    38. 38. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    39. 39. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    40. 40. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    41. 41. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    42. 42. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    43. 43. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    44. 44. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    45. 45. Summary 1-45 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    46. 46. Oracle Processes + Management Monitor MMON in 11g 1-46 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    47. 47. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    48. 48. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    49. 49. Database Writer (DBWn, n=0,…,19) Instance SGA Shared pool Database buffer cache DBWR Data files 1-49 Control files Redo log files Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    50. 50. 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. Copyright © Oracle Corporation, 1998, 2001. All rights reserved. 1-50 1-50
    51. 51. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    52. 52. Log Writer (LGWR) Instance SGA Shared pool Redo log buffer LGWR Data files 1-52 Control files Redo log files Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    53. 53. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    54. 54. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved. 1-54 blocks. Redo log files
    55. 55. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    56. 56. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    57. 57. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    58. 58. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    59. 59. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    60. 60. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    61. 61. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    62. 62. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    63. 63. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    64. 64. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    65. 65. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    66. 66. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    67. 67. Logical/physical/recovery-related structures of the database 1-67 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    68. 68. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    69. 69. Undo (Rollback) Segment Old image Table New image Undo segment DML statement 1-69 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    70. 70. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved.
    71. 71. 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 Copyright © Oracle Corporation, 1998, 2001. All rights reserved. Archived log files

    ×