PGA(Program Global Area)

Oracle instance consists of SGA and oracle processes. Oracle processes can be divided into server processes and background processes. Oracle database uses background processes to perform overall database operations, for example, database writer process writes dirty buffer from database buffer cache to datafiles. Oracle creates one or more Server Processes for users connected to database. Each oracle process is assigned a memory area to contain data and control information. This memory area is called Program Global Area (PGA).

The Program Global Area (PGA) is a private memory region that contains the data and control information for a server process. Only a server process can access the PGA. Oracle Database reads and writes information in the PGA on behalf of the server process. it will allocate depend upon connection type :
Dedicated Server environment – the Private SQL Area is located in the Program Global Area (PGA).
Shared Server environment – the Private SQL Area is located in the System Global Area (SGA).

A PGA is:

• a non-shared memory region that contains data and control information exclusively for use by an Oracle process.
• One PGA exists for each Server Process and each Background Process. It stores data and control information for a single Server Process or a single Background Process.
• PGA is the memory reserved for each user process connecting to an Oracle Database and is allocated when a process is created and deallocated when a process is terminated.
• This is NOT a shared part of memory – one PGA to each process only.
• The collection of individual PGAs is the total instance PGA, or instance PGA.

Contents of  PGA:-

Oracle database creates server processes to mange requests of user process. All user process issues SQL statements, it is the responsibility of Server process to execute these statements and return results to user process. Each server process has one PGA. PGA is memory where server process executes statements and stores information.

PGA consists of:

• Private SQL Area
• session memory
• SQL work Areas

Private SQL Area: Contains data such as bind information and run-time memory structures. It contains Persistent Area which contains bind information and is freed only when the cursor is closed and Run time Area which is created as the first step of an execute request. This area is freed only when the statement has been executed. The number of Private SQL areas that can be allocated to a user process depends on the OPEN_CURSORS initialization parameter. The location of a private SQL area depends on the type of connection established for a session. If a session is connected through a dedicated server, private SQL areas are located in the server process's PGA. However, if a session is connected through a shared server, part of the private SQL area is kept in the SGA.

Session Memory: Consists of memory allocated to hold a session’s variable and other info related to the session information for example session variables and logon information

SQL Work Areas: Used for memory intensive operations such as: Sort-based operators (order by, group-by, rollup, window function) ,Hash-join, Bitmap merge, Bitmap Create

ARCN (Archiver Process)

The archiver process (ARCn) copies redo log files to a designated storage device after a log switch has occurred. ARCn processes are present only when the database is in ARCHIVELOG mode, and automatic archiving is enabled ARCn Responsible for copying online redo log to archival storage before being reused. Runs only when database is in Archivelog Mode.When a Redo Log File fills up, Oracle switches to the next Redo Log File.

• If all Redo Log Files fill up, then Oracle switches back to the first one and uses them in a round-robin fashion by overwriting ones that have already been used.
• Overwritten Redo Log Files have information that, once overwritten, is lost forever.

ARCHIVELOG Mode:

• If ARCn is in what is termed ARCHIVELOG mode, then as the Redo Log Files fill up, they are individually written to Archived Redo Log Files.
• LGWR does not overwrite a Redo Log File until archiving has completed.
• Committed data is not lost forever and can be recovered in the event of a disk failure.
• Only the contents of the SGA will be lost if an Instance fails.

 NOARCHIVELOG Mode:

• The Redo Log Files are overwritten and not archived.
•  Recovery can only be made to the last full backup of the database files.
• All committed transactions after the last full backup are lost, and you can see that this could cost the firm a lot of $$$.

When running in ARCHIVELOG mode, the DBA is responsible to ensure that the Archived Redo Log Files do not consume all available disk space! Usually after two complete backups are made, any Archived Redo Log Files for prior backups are deleted.

RECO (Recoverer Process)

The Recoverer Process (RECO) is used to resolve failures of distributed transactions in a distributed database.
Consider a database that is distributed on two servers – one in India and one in Chicago.
Further, the database may be distributed on servers of two different operating systems, e.g. LINUX and Windows.
The RECO process of a node automatically connects to other databases involved in an in-doubt distributed transaction.
When RECO reestablishes a connection between the databases, it automatically resolves all in-doubt transactions, removing from each database's pending transaction table any rows that correspond to the resolved transactions.
Recoverer is responsible for recovering failed distributed transactions in a distributed database.
If the RECO process fails to connect with a remote server, RECO automatically tries to connect again after a timed interval. However, RECO waits an increasing amount of time (growing exponentially) before it attempts another connection. The RECO process is present only if the instance permits distributed transactions. The number of concurrent distributed transactions is not limited.

CKPT (checkpoint)

 A checkpoint is a data structure that defines a system change number (SCN) in the redo thread of a database. Checkpoints are recorded in the control file and in each data file header. They are a crucial element of recovery.

When a checkpoint occurs, Oracle Database must update the headers of all data files to record the details of the checkpoint. This is done by the CKPT process. The CKPT process does not write blocks to disk; DBWn always performs that work. The SCNs recorded in the file headers guarantee that all changes made to database blocks prior to that SCN have been written to disk.

• A checkpoint identifies a point in time with regard to the Redo Log Files where instance recovery is to begin should it be necessary.
• A checkpoint is taken at a minimum, once every three seconds.
• An event called a checkpoint occurs when the Oracle background process DBWn writes all the modified database buffers in the SGA, including both committed and uncommitted data, to the data files

How works CKPT:

Think of a checkpoint record as a starting point for recovery. DBWn will have completed writing all buffers from the Database Buffer Cache to disk prior to the checkpoint, thus those records will not require recovery.
This does the following:

• Ensures modified data blocks in memory are regularly written to disk – CKPT can call the DBWn process in order to ensure this and does so when writing a checkpoint record.
•  Reduces Instance Recovery time by minimizing the amount of work needed for recovery since only Redo Log File entries processed since the last checkpoint require recovery.
• Causes all committed data to be written to datafiles during database shutdown
• When checkpointing occurs ,its generate SCN (System Change Number) number and its recorded every datafiles header and control files .

If a Redo Log File fills up and a switch is made to a new Redo Log File , the CKPT process also writes checkpoint information into the headers of the datafiles.
Checkpoint information written to control files includes the system change number (the SCN is a number stored in the control file and in the headers of the database files that are used to ensure that all files in the system are synchronized), location of which Redo Log File is to be used for recovery, and other information.
CKPT does not write data blocks or redo blocks to disk – it calls DBWn and LGWR as necessary.