7202ICT – Database Administration

Lecture Three

Database Architecture

DATABASE WRITER (DBWR) PROCESS

UPDATE OPERATION REDO LOG BUFFER DATABASE COMMITS REDO LOG FILES CHECK POINTS ARCH PROCESS TRANSACTIONS OVERVIEW

Reading Oracle Concept Manuel Chapter 8http://www.cit.griffith.edu.au/~s106441/7202/concept.pdf

Database writer processSGA

Database Buffer CacheShared Pool

DataFiles

Server

User

DBWR

DATABASE WRITER (DBWR) PROCESS

DBWR manages the database buffer cache so that user processes can always find free buffers as needed.(picture)

The DBWR Process Writes all changed (modified) data buffers to the

appropriate data files Uses an LRU algorithm to keep the most recently used

data blocks in memory while aging out the least recently used blocks

• NB: You can start more than one DBWR process. This would be required if one DBWR process is incapable of handling the demands of the database.

DATABASE WRITER (DBWR) PROCESS

The DBWR process will wake up and begin writing dirty buffers to disk when:

The dirty list reaches a pre-defined threshold (set using database parameters DB_BLOCK_WRITE_BATCH)

A server process scans a specified number of buffers (set using database parameters DB_BLOCK_MAX_SCAN) in the LRU list without finding a free buffer (server process then signals DBWR process)

A time-out occurs (these occur about every 3 seconds) A checkpoint occurs

LOG TRANSACTIONS

• Oracle will record all changes made to the database in the redo log buffer. A background process called the LOG WRITER (LGWR) will write the information recorded in the redo log buffer to disk. Another background process called the ARCHIVER (ARCH) may optionally be used to archive all redo information.(Picture)

• The redo log buffer is a circular buffer containing information about changes made to the database. This information is stored in redo entries.

LOG TRANSACTIONS

Redo Entries

– Stores all changes made to the database in the redo entries of the redo log buffer.

– Used to reconstruct or rollback changes made to the database when database recovery is necessary due to a database crash.

• NB: ORACLE does not consider a transaction to be complete until the LGWR has written the appropriate redo logs for that transaction to disk. It is this action that determines the success of a commit statement.

Logwriter Process

Shared SQL Area

Shared Pool

SGA

Database Buffer Cache

Redo LogBuffer

Server

User

DBWR LGWR

DataFiles

Redo LogFiles

ARCH

LOGWRITER PROCESS (LGWR)

The Log Writer (LGWR) process writes redo log entries to disk.(Picture)

• LGWR writes redo log buffer entries to the redo log files when: A Commit occurs The redo log buffer pool reaches one third full threshold The DBWR needs to clean the buffer blocks for a

checkpoint A time-out occurs

LOGWRITER PROCESS (LGWR)

• N.B There is only one redo log writer per instance A commit confirmation is not issued to the user until

the transaction is recorded in the log file LGWR cannot write if the ARCH process is active on

the group that LGWR needs to write to. In this case all database actions shall queue will until the ARCH process is completed.

The user must commit a transaction to make the changes permanent in the database.

DATABASE COMMITS

Commit Operation– A user issues the commit command– A commit record is placed in the redo log buffer– LGWR flushes the redo log buffers to current log file– The user is notified that the transaction has been

committed– Resource locks are released on data and rollback blocks– The data block is marked as “pinned” (clean but out of

synch with disk)– DBWR will eventually write database block to disk

REDO LOG FILES

• Redo log files record all changes made to the database, and are used for data recovery. If the redo log files are mirrored (multiplexed), then the same redo log information is written to multiple online redo log files.(Picture)

• Redo Log Files Redo log files are written to in a circular fashion There must be at least 2 redo log groups

• Mirrored Redo Log Files Group members are updated simultaneously Mirrored redo log files protect against loss of a redo log file

REDO LOG FILES

Redo Log Files

Multiplexed Redo Log Files Group 1 Group 2 Group 3 Disk 1

Disk 2

Log File 1 Log File 2 Log File 3

Member A Member A Member A

Member B Member B Member B

LGWR

Log Switches

A log switch is when LGWR switches from one redo log file to another

A log switch occurs when LGWR has filled on log file group

A log switch can be forced by the DBA if current redo file needs to be archived

A log switch occurs when the database is shut down A checkpoint automatically occurs at a log switch

CHECKPOINTS

• During a checkpoint, DBWR writes all dirty buffers in the database buffer cache to disk, guaranteeing that all data blocks modified since the previous checkpoint are actually written to disk.

• Checkpoints Occur At every log switch A specified number of seconds

(LOG_CHECKPOINT_TIMEOUT) after the last checkpoint When a predetermined number of redo log blocks have been

written to disk since the last checkpoint At instance shutdown When forced by a DBA When a tablespace is taken off-line (ie: taking a table off-line)

CHECKPOINTS

• During a checkpoint and after the associated log switch, LGWR will update the headers of database and control files, unless the optional checkpoint (CKPT) process has been started, in which case it will perform this task.

• The parameter LOG_CHECKPOINT_TIMEOUT is used to determine the interval of time between checkpoints.

• The parameter LOG_CHECKPOINT_INTERVAL is used to determine how many redo file blocks must be filled since the previous checkpoint, before another checkpoint is initiated.

• Database checkpoints ensure that all modified database buffers are written to the database files. The database files are marked current as of a given time and the checkpoint is recorded in the control file.(Picture)

Checkpoints

– Require that instance recovery need only apply changes that have been made since the last checkpoint

– Allow an on-line redo log file to be reused by guaranteeing that all changes stored in the redo log file are also written to the appropriate data file

– Checkpoints do not halt activity on the database, nor are current transactions affected.

• CKPT Process Updates headers of data and control files after a checkpoint has been

completed More frequent checkpoints will reduce the time necessary to recover a

database from instance failure, but will degrade overall performance (tradeoff)

Checkpoints

Shared SQL Area

Shared Pool

SGA

Database Buffer Cache

Redo LogBuffer

Server

User

DBWR LGWR

DataFiles

Redo LogFiles

ARCH

CKPT

Control Files

ARCH PROCESS

• The Archiver Process (ARCH) is an optional process, which when enabled, will copy online redo log files to a designated storage area or device once they become full.(Picture)

• Archiver Process

– Redo log files are copied to tape or disk for media failure recovery (damaged disk)

ARCH operates only when a log file group switch occurs ARCH is optional and is present only when automatic archiving is

enabled, or when manually requested ARCH may write to a tape device or to a disk

Savepoints

• mark an interim point within a transaction to which a transaction can later be rolled back.

• Syntax – SAVEPOINT

– SAVEPOINT savepoint_name

• Syntax – ROLLBACK

– ROLLBACK TO savepoint_name

Savepoint Features

• Useful during interactive trial and error situations• Useful within structured programming where:

– Main program calls sub-routine– Sub-routine sets savepoint– Sub-routine processes statements– Sub-routine encounters error and rolls back to savepoint– Sub-routine returns control to main program and reports error

• Maximum number of savepoints per transaction is determined by SAVEPOINTS parameter

• Rolling back to a savepoint`– Rolls back changes since savepoint_name– Release locks acquired since savepoint_name