1 - Oracle Server Architecture OverviewOracle DatabaseData files, Control files, Redo log filesOther FilesParameter file, Password file, Archive logsOracle InstanceSGA (Shared Global Area)Buffer CacheShared PoolLibrary CacheData Dictionary CacheRedo Log BufferLarge PoolJava PoolBackground ProcessesDBWR, LGWR, SMON, PMON, CKPT, ARCHOther ProcessesUser processesServer processesPGAQuery ProcessingRollback Segments

1 - Oracle Server Architecture Overview User ProcessServer ProcessOther Files... Parameter,Password,Archive LogsPGAOracle DatabaseData filesRedo Log FilesControl FilesDatabase BufferCacheShared PoolRedoLogBufferSGA (System Global Area)DBWRLGWRSMONPMONCKPTRECOARCHLCKnPnnnDnnnSNPnOracle InstanceJava Pool(optional)Large Pool(optional)

Database Files Data filesStore the dataCan only be associated with 1 databaseForm logical units called a tablespaceRedo log filesRecord all of the changes in the databaseMust have at least 2 groupsOracle recommends each group have 2 members on separate devicesControl filesDatabase nameTime stamp of database creationName and locations of all data files and redo log files

Other Files Parameter filesStore hundreds of parameters for the Oracle InstancePassword fileAuthenticates which users are allowed to start and stop the databaseArchive redo log filesCopies of the redo log files that are saved so the database can be recovered to a single point in timeOther Files... Parameter,Password,Archive Logs

The Oracle Instance Oracle Instance is comprised of the background processes and memory structures (SGA - Shared Global Area)Database BufferCacheShared PoolRedoLogBufferSGA (System Global Area)DBWRLGWRSMONPMONCKPTRECOARCHLCKnPnnnDnnnSNPnOracle InstanceJava PoolLarge Pool

Shared Pool Shared PoolLibrary CacheStores the most recently used SQL statementsData Dictionary Cache (Row Cache)Stores definitions of objects contained in the databaseUsed to validate object names and privileges Size is set by the SHARED_POOL_SIZE parameter in the initialization file (parameter file).Database BufferCacheShared PoolRedoLogBufferSGA (System Global Area)Java PoolLarge Pool

Buffer Cache Area of memory used to store the most recently used data. Oracle knows which data is most likely to be used again by maintaining a list of recently used blocks called the LRU.OperationA request for data is madeOracle checks the buffer cache to see if it existsIf not it grabs the block from disk (physical read)Database BufferCacheShared PoolRedoLogBufferSGA (System Global Area)Java PoolLarge Pool

Sizing the Buffer Cache 8K8K8K8K8KDB_BLOCK_SIZE = 8192DB_BLOCK_BUFFERS = 58192 * 5 = 40960 Bytes (40K)

Redo Log Buffer Circular buffer that records all of the changes occurring in the databaseSizeDefined by LOG_BUFFER parameterShould be a multiple of DB_BLOCK_SIZEUsually small compared with total SGA size, small increase can significantly enhance throughputAs of Oracle 8 a 1 MB upper limit has been set on the background write threshold which limits the negative impact of a very large redo log bufferData is written from the redo log buffer to the redo log files by the log writer process

Large Pool and Java Pool Optional areas of memoryLARGE_POOL_SIZEDatabase BufferCacheShared Pool

RedoLogBufferSGA (System Global Area)DBWRLGWRSMONPMONCKPTRECOARCHLCKnPnnnDnnnSNPnOracle InstanceJava PoolLarge Pool

Background Processes 5 background processes are mandatoryDatabase Writer (DBWR)Log Writer (LGWR)System Monitor (SMON)Process Monitor (PMON)Checkpoint (CKPT)Required as of Oracle 8iDBWRLGWRSMONPMONCKPTRECOARCHLCKnPnnnDnnnSNPn

Database Writer (DBWR) Writes modified (dirty) blocks in the buffer cache to the data filesOperates in batch modeWhenThere are too many dirty blocksDB_BLOCK_MAX_DIRTY_TARGETA process scans a specified number of buffers in the LRU list without finding a free bufferA time-out occurs (every 3 seconds)A checkpoint occursYou can configure additional DBWR processes by setting the DB_WRITER_PROCESSES parameter in the parameter file

Log Writer (LGWR) Writes information in the redo log buffer to the redo logsWrites When:Every time a commit is issuedWhen redo log buffer is 1/3 fullWhen there is more than 1 MB of changesBefore DBWR (DB Writer) completes cleaning modified buffer blocks in the buffer cache by writing them to the data filesWhen a timeout occurs (every 3 seconds)

System Monitor (SMON) Automatically recovers the instance during instance failureRolls forward transactions in the redo logs that have not been written to diskOpens the database and makes locked data availableRolls back uncommitted transactions

Space Maintenance Functions:Coalesces free space De-allocates temporary segments

Process Monitor (PMON) Cleans up failed processes by handling existing transactions and recovering memoryRolls back existing transactionsReleases any locks held by the processReleases other resources held by the processChecks server and dispatcher processes and restarts them when necessary

Checkpoint (CKPT) Used to synchronize data files, mandatory in Oracle 8iIn Oracle 8 takes it handles the task of updating the data file headers instead of log writerFrequent checkpoints increase the speed of database recovery during instance failure but may hinder performanceCHECKPOINT_PROCESS = True (Before 8i)

Connecting to the Database A user process always connects to the database via a server processDatabase BufferCacheShared PoolRedoLogBufferSGA (System Global Area)DBWRLGWRSMONPMONCKPTRECOARCHLCKnPnnnDnnnSNPnOracle InstanceUser ProcessServer ProcessPGAJava PoolLarge Pool

PGA (Program Global Area) PGAUsed by only one process and is not sharedGets Created when Server Process Starts.ContentsStack spaceSession informationCursor stateSort area

User ProcessServer ProcessPGA

Query Processing ParseExecuteFetchDatabase BufferCacheShared PoolRedoLogBufferSGA (System Global Area)DBWRLGWRSMONPMONCKPTRECOARCHLCKnPnnnDnnnSNPnOracle InstanceUser ProcessServer ProcessPGAJava PoolLarge Pool

Query Processing ParseSQL statement is passed from user process to server processServer process looks in shared pool to see if SQL already existsValidates SQL by checking the syntaxChecks the data dictionary to ensure all of the objects and columns actually existLocks on objects are obtained so the definition does not changeChecks the users privilegesDetermines the execution planLoads the SQL and the plan into the shared SQL areaExecutecontinued

Query Processing ParseExecuteIdentifies the rows that are selectedFetchReturns the rows to the user process and ordered if necessary

Rollback Segments Record the before image before data is actually changed in the databasePurposeAllows user to roll back a transactionAllows other users to see the original image until the changes have been committedAllows the database to be recovered if the instance fails

The Oracle Server is comprised of the Oracle Instance and the Oracle Database.

The Oracle Instance is the combination of background processes and memory structures (SGA - Shared Global Area).

The SGA is a shared area of memory used by Oracle.

Background processes perform a variety of tasks. Many are required for the server to run. Some are optional.

Other Processes - User Processes and Server Processes

Database files - Data files, Redo Log Files, Control Files

Oracle Software - Located in $ORACLE_HOME, contains the binaries to operate and manage the server.The Oracle Server is comprised of the Oracle Instance and the Oracle Database.

The Oracle Instance is the combination of background processes and memory structures (SGA - Shared Global Area).

The SGA is a shared area of memory used by Oracle.

Background processes perform a variety of tasks. Many are required for the server to run. Some are optional.

Other Processes - User Processes and Server Processes

Database files - Data files, Redo Log Files, Control Files

Oracle Software - Located in $ORACLE_HOME, contains the binaries to operate and manage the server.

Data files - Are the actual files on disk that contain the Oracle database. A database must have at least one data file. Here is what you need to know.

1. A data file can only be associated with one database.2. Data files can be configured to grow automatically.3. One or more data files form a logical unit of data storage called a tablespace. A data file can only belong to a single tablespace but a tablespace can have many data files.

Redo logs - Contain a record of the changes made in the database. Think of them as a recorder. Every time something changes in the database it is recorded in the Redo Logs. Your database must have at least 2 redo log groups.

Control Files - The control files contain information about the database. For the time being think of the control file as the file that keeps everything in sync. The control file can tell if all of the files are consistent to a point in time. You will never, ever, never want to lose your control files! How do you avoid this? You multiplex them. Another way of saying copy them off to another secure location.

Parameter File - Contains numerous parameters that are read when the database is started. In fact you will need to know at what stage of startup that the parameter file is actually read in (MOUNT).

Password File - Used to authenticate users from the operating system. Obviously database passwords don't work if the database is not running so you need this file to authenticate users who are able to start and stop the database.Created by the ORAPWD utility that comes installed with the database software.

Archived Log Files - You already know that the Redo Log files act like a recorder. Well what happens when the recorder is full? If your database is archiving then it is copied to another location for storage and then used again. This allows you to recover your database to any single point in time. To get you started you need to know that when someone refers to the Oracle Instance they should be referring to the combination of the background processes & the SGA. An instance can only open one database at a time. The SGA can be broken in to a large number of smaller components but for now you really only need to know about 3 of them. As the other two are optional.

1. Buffer Cache - Stores the most recent data that has been used by the system. Obviously the more data you squeeze into memory the faster the database will be. This is usually the largest part of the SGA.

2. Shared Pool - Since almost all interaction with the database involves SQL it makes us to store that in memory also. SQL is stored in the shared pool. There are actual 2 components of the shared pool that will be important to distinguish. The library cache and the data dictionary cache.

Lib Cache: The library cache stores the most recently used SQL in memory. It stores the actual text of the SQL.

D.D Cache: Stores the object definitions, users and privileges in memory

3. Redo Log Buffer - We talked about the Redo Log files already and mentioned that they act as a recorder. Well before the changes in the database are recorded they have to be passed through an area of memory called the Redo Log Buffer. It is usually the smallest area of the SGA. A 1 MB Redo Log Buffer is considered pretty big.

4. Java Pool - Used to store Java code.

5. Large Pool - The large pool is an optional area in the SGA that provides large memory allocations for Oracle backup and restore operations, I/O server processes, and session memory for the multi-threaded server and Oracle XA. Oracle XA is Oracle's implementation of the X/Open Distributed Transaction Processing (DTP) XA interfaceWe discussed earlier that one component of the SGA is the shared pool. You should know that the shared pool can also be broken down into the library cache and data dictionary cache.

For performance reasons it is beneficial to store as much of the database in memory as possible. What is stored in memory needs to be segregated however because some things are more important than others. The buffer cache stores data. However the library cache and data dictionary cache store something entirely different.

The library cache stores the most recently used SQL in memory. It stores the actual text of the SQL, the parse tree (a compiled version of the statement) and the execution plan.

The data dictionary cache stores the object definitions, users and privileges in memory so they can also be accessed quickly when needed.

You size the shared pool as a whole and can not control the individual size of the library cache or data dictionary cache. It is sized by changing the SHARED_POOL_SIZE parameter in the parameter file and restarting the database.The database buffer cache is usually the largest portion of memory set aside for Oracle. It stores the most recently used data and is shared by all users. Data that is used a lot or data that has been used recently had the highest chance of being used again. That is why it is a good idea to store this data in memory where is can be accessed quickly.

You should know what the LRU is. It stands for Least Recently Used. This is the algorithm that Oracle uses to determine which pieces of data to store in the buffer cache. In most cases all of the data in the database can not be stored here so Oracle has to decide what stays and what goes. Oracle used the LRU list to determine what data will soon be overwritten with new data requests from disk.

One other thing that is a bit more advanced but important to know is that when a full table scan is performed on a table the data is moved to the least recently used end of the LRU list because it is unlikely you wanted to keep all this data in memory. A full table scan occurs when Oracle has to check every single record in a table for some data you requested. Sizing the database buffer cache is pretty easy. All you need to do is change the number of DB_BLOCK_BUFFERS in the parameter file and restart the instance to increase or decrease the amount of memory in the buffer cache. You can not change the block size once the database has been created.

In this example you can see my block size is 8K. I have 5 blocks in my buffer cache (note this is very small just for the example). If you multiply 8K * 5 blocks you get a total size of 40K.

Oracle 9i has brought us dynamic memory allocation so we will not need to restart the server to enact memory changes.You should also know about 2 optional areas of the SGA.

1. Java Pool - Used to store Java code.

2. Large Pool - When a large pool has been configured it will be used for session memory instead of the shared pool when running in MTS. It is also used to speed up backup and restore operations because the large pool is better suited than the buffer pool for the types of requests these operations incur.DBWR (Database Writer) - Writes modified (dirty) buffers from the buffer cache to disk. Operates in batch mode for greater efficiency.

LGWR (Log Writer) - Writes the data from the Redo Log Buffer to the Redo Log Files.

SMON (System Monitor) - Coalesces contiguous free space, cleans up temporary segments and performs instance recovery if required when the database is restarted.

PMON (Process Monitor) - Performs process recovery when a user process fails and makes any used resources available again.

CKPT (Checkpoint) - Updates the status of the database in the control files and the data files signaling that the modified data in the buffer cache has been successfully written to disk.

Besides know what each of these processes does you should know when and what causes them to actually perform their jobs. There are actually a lot more background processes you should know about but these are the required processes. If any of these 5 are not running the database will crash. Don't worry they start automatically when you start the database. A Checkpoint is a means of synchronizing the database buffer cache with the data files.If a instance shuts down, if for example the O/S fails.. SMON will perform instance recovery by :Rolling forward to recover data recorded in the online redo logs. In this case the data has not been written to diskBut the changes have been recorded in the redo logs.

So SMON reads the redo log files and applies changes to the data blocks.You should know how a user actually gets a connection to an Oracle database. What you need to know is that the user process is created by running some sort of tool like SQL*Plus. The user process then communicates to the server process and the server process brokers all of the requests from the user process.

In a dedicated server configuration each user process gets it's own server process. This can consume a lot of memory if you have thousands of users connecting to the database. This is why we have something called multithreaded server mode. When you are running your database in multithreaded server mode you force the server to share server processes between user processes.A PGA is created for each server process and may only be written to by code acting on behalf of the server process. The size of the PGA is fixed and operating system specific. PGA's are created and destroyed with its associated process.

Stack Space - Memory allocated to hold a sessions variables and arrays.

Session Information - Information about the session is stored in the PGA when running in dedicated server mode. If you are running in multithreaded server configuration the session information is in the SGA. Specifically it is in the large pool if you have one configured

Cursor State - State of SQL being processed by this session.

Sort area - Space used for sorts.Query processing takes place in 3 basic steps.