OCA 01 - Exploring The Database Architecture

01 - Exploring the Database Architecture
By Muhammad Asghar Khan

Reference: Apress RMAN Recipes for Oracle Database 11g by Darl Kuhn, Sam Alapati, and Arup Nanda
1/1
Agenda
Single-Instance Database Architecture

Oracle Instance Oracle Database Real Application Clusters Streams Data Guard
Distributed Systems Architectures

http://asghars.blogspot.com
1/33
Oracle database consists of two entities:
Oracle Instance
A set of processes (Unix) or single threaded process (Windows) and shared memory area or System Global Area (SGA) A collection of physical OS files or disks in case of ASM or RAW partitions
Oracle Database
Database may be mounted & opened by many instances, while an instance may mount & open a single database in its entire lifetime

(Oracle Instance Memory Structures)
2/33
Oracle Instance
System/Shared Global Area
SGA allocates & de-allocates space in units of granules (4MB, 8MB or 16MB) SGA memory is declared by the SGA_TARGET initialization parameter SGA contains:
Required

Database Buffer Cache: Buffer Pools etc. Redo Log Buffer Cache: Redo entries Shared Pool: Library Cache, Dictionary Cache Fixed SGA: Bootstrap of SGA Large Pool: Shared Server Session, RMAN backup/restore Java Pool: Java Code Streams Pool: Queue, Messages http://asghars.blogspot.com
Optional


3/33
Database Buffer Cache

The data blocks containing the data of interest are first copied into the database buffer cache Changes (INSERT,UPDATE, DELETE) are applied to copies of the data blocks in the database buffer cache When querying data the rows of interest are copies into the database buffer cache; the relevant rows are then transferred into the sessions PGA for further processing Blocks containing data that is frequently accessed will be in the database buffer cache, therefore minimizing the need for disk I/O A well-tuned database buffer cache can result in a cache hit ratio well over 90 percent


4/33
The buffer will become dirty when the block in it is updated, at which point the buffer will be clean again The write to the datafiles is done by the database writer background process The size of the database buffer cache is critical for performance An undersized cache will result in excessive disk activity An oversized cache is not so bad but can cause problems; like startup of an instance may be slower or OS is having to swap pages of virtual memory Determining the optimal size of the database buffer cache is application specific and a matter of performance tuning Short-term staging area for change vectors before they are written to the redo log on disk
Redo Log Buffer Cache


5/33
A change vector is a modification applied to something Whenever a data block is changed, the change vectors applied to the block are written out to the redo log, from where they can be extracted and applied to datafile backups if it is ever necessary to restore a datafile One write of the log buffer to disk may be a batch of many change vectors from many transactions The writes are done by the log writer background process (LGWR) Write occurs in real time, and while it is in progress, the session that issued the COMMIT will hang It is a circular buffer The commit-complete message is not returned to the session until the data blocks in the cache have been changed (which means that the transaction has been completed) and the change vectors have been written to the redo log on disk (and therefore the transaction could be recovered if necessary) The size of log buffer cache is determined by the Oracle server and is based on the number of CPUs on the server node


6/33
You cannot do DML faster than the LGWR can flush the change vectors to the online redo log files If redo generation is the limiting factor in a databases performance, the only option is to go to RAC Memory in the shared pool is allocated according to an LRU (least recently used) algorithm It is divided into dozens of substructures, all of which are managed internally by the Oracle server Four of the shared pool components are:
Shared Pool
Library Cache: Stores recently executed code, in its parsed form. In a well-designed application, it is possible that statements may be parsed once and executed millions of times Data Dictionary Cache/Row Cache: Stores recently used object definitions: descriptions of tables, indexes, users, and other metadata definitions

7/33
PL/SQL Area: Stored PL/SQL objects are stored in PL/SQL area. Anonymous PL/SQL cannot be cached SQL Query and PL/SQL Function Result Cache: The result cache is a release 11g new feature. A result cache lets the Oracle server store the results of frequent queries or PL/SQL in memory. By default, use of the SQL query and PL/SQL function result cache is disabled
Fixed SGA
Contains a set of variables that point to other components of the SGA Acts like a bootstrap section of the SGA It is fixed for each release of Oracle and cant be altered

8/33
Large Pool
Major use of the large pool is by shared server processes Large pool may also be used by the Recovery Manager Only required if your application is going to run Java-stored procedures within the database It is used for the heap space needed to instantiate the Java objects Note that Java code is not cached in the Java pool: it is cached in the shared pool Optimal size of the Java pool is dependent on the Java application
Java Pool


9/33
Streams Pool
Used by Oracle Streams In streams, change vectors from the redo log are used to reconstruct the statements that were executed These statements are executed at the remote database Stream pool is used for these operations

1.
10/33
EXERCISE 1-1: Investigate the Memory Structures of the Instance

Connect as user SYSTEM
Show the sizes of the SGA components that can be dynamically resized
1.

(Oracle Instance - Processes)
11/33
Processes
User Processes
Application program or Oracle tool creates a user process on the server Run the application or Oracle tool code
Server Processes/ Foreground Processes

Services an individual user process With each server process is associated a private non-shareable memory, called the program global area (PGA) Server process can be configured as dedicated or shared server In dedicated mode; listener spawn a new dedicated server process for each user process

12/33
In shared mode; listener handover the connection to dispatcher which connects the user process to the shared server process
Background Processes
An Oracle instance can have many background processes Each Oracle background process is in charge of a separate task Some of the BG processes can be:
Database Writer (DBWn) Log Writer (LGWR) Checkpoint (CKPT) System Monitor (SMON) Process Monitor (PMON) Manageability Monitor (MMON) Memory Manager (MMAN) Archiver (ARCn) Recoverer (RECO)

13/33
Database Writer (DBWn)
DBWn writes dirty buffers from the database buffer cache to the datafiles It is possible for an instance to have several database writers (up to a maximum of twenty), which will be called DBW0, DBW1, and so on The default number is one database writer per eight CPUs No free buffers, too many dirty buffers, a three-second timeout, or a checkpoint will cause the DBW to write A free buffer is a buffer that is neither dirty (updated, and not yet written back to disk) nor pinned (a pinned buffer is one that is being used by another session at that very moment) DBW does absolutely nothing when a transaction is committed, however; when a checkpoint occurs, all dirty buffers are written During a checkpoint, disk I/O rates will hit the roof, CPU usage may go to 100 percent, end user sessions will experience degraded performance, therefore; it must be avoided Partial checkpoints occur only when a datafile or tablespace is taken offline; when a tablespace is put into backup mode; when a tablespace is made read only

14/33
Log Writer (LGWR)

LGWR writes (flushes) the contents of the log buffer to the online log files When a session makes any change to blocks in the database buffer cache, before it applies the change to the block it writes out the change vector that it is about to apply to the log buffer When a session issues a COMMIT, the LGWR writes in real time: the session hangs, while LGWR writes the buffer to disk It is impossible to do DML faster than LGWR can write the change vectors to disk LGWR flush the log buffer to disk; on COMMIT, when the buffer is onethird full, just before DBWn writes As DBWn writes after three-second timeout, therefor, LGWR will always write before three-second timout It is necessary to know that it is perfectly possible for DBWn to write an uncommitted transaction to the datafiles, as long as the undo data is available Undo data also generates change vectors: as these will be in the redo log files before the datafiles are updated which can be used to roll back a transaction

15/33
Checkpoint (CKPT)
Checkpoint instructs DBWn to write out dirty buffers at a constant rate, so that there is always a predictable gap between DBWn (which writes blocks on a lazy algorithm) and LGWR (which writes change vectors in near real time) This is also called incremental checkpoints The current checkpoint position, also known as the RBA (the redo byte address), is the point in the redo stream at which recovery must begin in the event of an instance crash CKPT continually updates the controlfile with the current checkpoint position SMON mounts a database by locating and validating the database controlfile It then opens a database by locating and validating all the datafiles and online log files Once the database is opened and in use, SMON is responsible for various housekeeping tasks, such as collating free space in datafiles
System Monitor (SMON)

16/33
Process Monitor (PMON)
If the session (user process) is terminated in a disorderly manner (perhaps because the users PC is rebooted), then the session will be left in a state that must be cleared up If a session has terminated abnormally, PMON will destroy the server process, return its PGA memory to the operating systems free memory pool, and roll back any incomplete transaction that may have been in progress MMON regularly (by default, every hour) captures statistics (snapshots) from the SGA and writes them to the data dictionary (kept for only eight days) Every time MMON takes a snapshot, it also launches the Automatic Database Diagnostic Monitor (ADDM) The ADDM is a tool that analyses database activity using an expert system developed over many years by many DBAs
Manageability Monitor (MMON)

17/33
MMON also continuously monitors the database and the instance to check whether any alerts should be raised
Memory Manager (MMAN)
It enables the automatic management of memory allocations The DBA need to set an overall target for memory usage, and MMAN will observe the demand for PGA memory and SGA memory, and allocate memory to sessions and to SGA structures as needed The process and purpose of launching ARCn to create archive log files There can be from one to thirty, named ARC0, ARC1, and so on In order to preserve a complete history of all changes applied to the data, the online log files must be copied as they are filled and before they are reused, the ARCn is responsible for doing this Most production transactional databases will run in archive log mode, meaning that ARCn is started automatically and that LGWR is not permitted to overwrite an online log file until ARCn has successfully archived it to an archive log file If archiving fails, the database will eventually hang
Archiver (ARCn)


18/33
Recoverer (RECO)
A distributed transaction is a transaction that involves updates to two or more databases Distributed transactions are designed by programmers and operate through database links Distributed transactions require a two-phase commit If anything goes wrong anywhere between the two phases, RECO takes action to cancel the commit and roll back the work in all databases
EXERCISE 1-2: Investigate the Processes Running in Your Instance

1.
Determine what processes are running


19/33

2.
1.
20/33
Demonstrate the launching of server processes as sessions are made

Count the number of processes running that have the string oracle in their name; this will include all the session server processes (and possibly a few others)
1.
Launch a SQL*Plus session, and rerun the preceding command: use the host command to launch an operating shell from within the SQL*Plus session

Observe how the number of processes changes from 81 to 82 : the difference is the launching and terminating of the server process supporting the SQL*Plus session
21/33

(Oracle Database)
22/33
Oracle Database

As per the RDBMS standard the Oracle architecture guarantees abstraction of the logical from the physical The relationship between physical and logical structures is maintained and documented in the data dictionary , which contains metadata describing the whole database Physical Structure

Physical structures are visible to the system administrators Data Files Control Files Online Redo Log Files Archive Log Files Parameter Files Trace Files

(Oracle Database)

23/33
Alert Files Password Files Logical structures (segments) are visible to the programmers Tablespaces Segments Extents Blocks
Logical Structure


(Oracle Database - Physical)
24/33
Data Files

Datafiles are the repository for data Oracle database requires at least two data files At the operating system level, a datafile consists of a number of operating system blocks Internally, datafiles are formatted into Oracle blocks The block size is a matter for tuning and can range (with limits depending on the platform) from 2 KB up to 64 KB Many DBAs like to match the operating system block size to the Oracle block size. For performance reasons, the operating system blocks should never be larger than the Oracle blocks Within a block, there is a header section and a data area, and possibly some free space

25/33
The header section contains information such as the row directory , which lists the location within the data area of the rows in the block (if the block is being used for a table segment) and also row locking information if there is a transaction working on the rows in the block Server processes read from the datafiles; DBWn writes to datafiles It contains pointers to the rest of the database:
Control Files
Locations of the online redo log files and of the datafiles, and of the more recent archive log files if the database is in archive log mode It also stores information required to maintain database integrity: various critical sequence numbers and timestamps

26/33
Every database has one controlfile, but a good DBA will always create multiple copies of the controlfile so that if one copy is damaged, the database itself will survive All organizations should have a DBA standards handbook, which will state something like all production databases will have three copies of the controlfile It stores a continuous chain in chronological order of every change vector applied to the database If a datafile is damaged, these change vectors can be applied to datafile backups to redo the work, bringing them forward in time until the moment that the damage occurred
Online Redo Log Files


27/33
Every database has at least two online redo log files, but as with the controlfile, a good DBA creates multiple copies of each online redo log file The online redo log consists of groups of online redo log files, each file being known as a member An Oracle database requires at least two groups of at least one member each to function The size and number of your log file groups are a matter of tuning
Archive Log Files
When an online redo log file fills, the ARCn process copies it out of the database to an archive redo log file

28/33
Parameter Files
When an Oracle instance is started, the SGA structures build in memory and the background processes start according to settings in the parameter file This is the only file that needs to exist in order to start an instance There are several hundred parameters, but only one is required: the DB_NAME parameter The alert log is a continuous stream of messages regarding certain critical operations affecting the instance and the database
Alert Log and Trace Files

29/33
Trace files are generated by background processes when they detect error conditions, and sometimes to report certain actions In this file you specify the names of database users who have been granted the SYSDBA or SYSOPER privilages
Password Files

(Oracle Database-Logical)
30/33
Tablespaces
Oracle abstracts the logical storage from the physical storage by means of the tablespace A tablespace is logically a collection of one or more segments, and physically a collection of one or more datafiles Each database has five default tablespaces: system, sysaux, undo, temporary and default tablespace
Segments
Oracle uses the term segment to describe any structure that contains data like table Segment can be of type data, index or temporary
An extent is a series of blocks that are consecutively numbered within a datafile, and segments will grow by adding new extents to them These extents need not be adjacent to each other, or even in the same datafile; they can come from any datafile that is part of the tablespace within which the segment resides
Extents


(Oracle Database-Logical)
31/33
Blocks

Oracle block is the smallest unit of space allocation in Oracle Internally, datafiles are formatted into Oracle blocks The block size is a matter for tuning and can range (with limits depending on the platform) from 2 KB up to 64 KB Many DBAs like to match the operating system block size to the Oracle block size. For performance reasons, the operating system blocks should never be larger than the Oracle blocks

(Oracle Database)
32/33
EXERCISE 1-3: Investigate the Storage Structures in Your Database 1. Create a table without nominating a tablespace
2.
Identify the tablespace in which the table resides, the size of the extent, the file number the extent is in, and which block of the file the extent starts at

(Oracle Database)
3.
33/33
Identify the file by name
4.
Work out precisely where in the file the extent is, in terms of how many bytes into the file it begins
1/4
In a distributed environment, there are various possibilities for grouping instances and databases:
Real Application Clusters (RAC), where multiple instances open one database Streams, where multiple Oracle servers propagate transactions between each other Data Guard, where a primary database updates a standby database
RAC database can be configured for 100 percent uptime
Real Application Clusters
2/4
Sessions against the failed instance can be reestablished against a surviving instance without the end user being aware of any disruption There are various circumstances that make it desirable to transfer data from one database to another Streams can also be used for fault tolerance
Streams
Data Guard
A physical standby is byte-for-byte identical with the primary, for the purpose of zero data loss
3/4
A logical standby contains the same data as the primary, but possibly with different data structures
EXERCISE 1-4: Database Is Single Instance or Part of a Distributed System

1.
Determine if the instance is part of an RAC database
2.
Determine if the database is protected against data loss by a standby database
4/4

3.
Determine if Streams has been configured in the database
This return no rows, which shows Streams has never been configured

OCA 01 - Exploring The Database Architecture

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OCA 01 - Exploring The Database Architecture

Uploaded by

Copyright:

Available Formats

01 - Exploring the Database Architecture

By Muhammad Asghar Khan

Single-Instance Database Architecture

Distributed Systems Architectures

Single-Instance Database Architecture

Oracle database consists of two entities:

Single-Instance Database Architecture

System/Shared Global Area

Single-Instance Database Architecture

Database Buffer Cache

Single-Instance Database Architecture

Redo Log Buffer Cache

Single-Instance Database Architecture

Single-Instance Database Architecture

Single-Instance Database Architecture

Single-Instance Database Architecture

Single-Instance Database Architecture

Single-Instance Database Architecture

EXERCISE 1-1: Investigate the Memory Structures of the Instance

Single-Instance Database Architecture

Server Processes/ Foreground Processes

Single-Instance Database Architecture

Single-Instance Database Architecture

Database Writer (DBWn)

Single-Instance Database Architecture

Log Writer (LGWR)

Single-Instance Database Architecture

System Monitor (SMON)

Single-Instance Database Architecture

Process Monitor (PMON)

Manageability Monitor (MMON)

Single-Instance Database Architecture

Memory Manager (MMAN)

Single-Instance Database Architecture

EXERCISE 1-2: Investigate the Processes Running in Your Instance

Determine what processes are running

Single-Instance Database Architecture

Single-Instance Database Architecture

Demonstrate the launching of server processes as sessions are made

Single-Instance Database Architecture

Single-Instance Database Architecture

Single-Instance Database Architecture

Single-Instance Database Architecture

Single-Instance Database Architecture

Single-Instance Database Architecture

Online Redo Log Files

Single-Instance Database Architecture

Archive Log Files

Single-Instance Database Architecture

Alert Log and Trace Files

Single-Instance Database Architecture

Single-Instance Database Architecture

Single-Instance Database Architecture

Single-Instance Database Architecture

Single-Instance Database Architecture

Identify the file by name

Distributed Systems Architectures

Real Application Clusters

Distributed Systems Architectures

Distributed Systems Architectures

EXERCISE 1-4: Database Is Single Instance or Part of a Distributed System

Determine if the instance is part of an RAC database

Determine if the database is protected against data loss by a standby database