tape_size: Storage size in gigabytes (G), megabytes (M) or kilobytes (K) for the tapes that will be used for backups and for archiving redo log files.
remote_host: this parameter is to specify the name of the remote host, if you want to make a backup to a remote disk
volume_archive: This parameter is used by BRARCHIVE to identify the volume/directory to be used for the archive of the offline redo log files
volume_backup: This parameter is used by BRBACKUP to identify the volume/directory to be used for the backup of the database or non-database files
backup_dev_type: Determines the backup medium that you want to use .It may be a disk, tape etc
Database Buffer Cache:
Is a fairly large memory object that stores the actual data blocks that are retrieved from datafiles by system queries and other data manipulation language commands
The buffers in the cache are organized in two lists:
–The write list and,
–Theleast recently used (LRU) list.
The write list holds dirty buffers – these are buffers that hold that data that has been modified, but the blocks have not been written back 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
Redo Log buffer Cache:
The Redo Log Buffer memory object stores images of all changes made to database blocks. As you know, database blocks typically store several table rows of organizational data. This means that if a single column value From one row in a block is changed, the image is stored. Changes include insert, update, delete, create, alter, or drop.
Data dictionary Cache:
The Data Dictionary Cache is a memory structure that caches data dictionary information that has been recently used. This includes user account information, datafile names, table descriptions, user privileges, and other information.The database server manages the size of the Data Dictionary Cache internally and the size depends on the size of the Shared Pool in which the Data Dictionary Cache resides. If the size is too small, then the data dictionary tables that reside on disk must be queried often for information and this will slow down performance.
Different Processes of Oracle :
DBWn:
Writes to datafiles when one of these events occurs that is illustrated in the figure below.
LGWR:
The Log Writer (LGWR) writes contents from the Redo Log Buffer to the Redo Log File that is in use. These are sequential writes since the Redo Log Files record database modifications based on the actual time that the modification takes place. LGWR actually writes before the DBWn writes and only confirms that a COMMIT operation has succeeded when the Redo Log Buffer contents are successfully written to disk. LGWR can also call the DBWn to write contents of the Database Buffer Cache to disk. The LGWR writes according to the events illustrated in the figure shown below:
SMON:
The System Monitor (SMON) is responsible for instance recovery by applying entries in the online redo log files to the datafiles. It also performs other activities as outlined in the figure shown belowIf an Oracle Instance fails, all information in memory not written to disk is lost. SMON is responsible for recovering the instance when the database is started up again. It does the following:
Rolls forward to recover data that was recorded in a Redo Log File, but that had not yet been recorded to a datafile by DBWn. SMON reads the Redo Log Files and applies the changes to the data blocks. This recovers all transactions that were committed because these were written to the Redo Log Files prior to system failure
Opens the database to allow system users to logon.
Rolls back uncommitted transactions.
SMON also does limited space management. It combines (coalesces) adjacent areas of free space in the database's datafiles for tablespaces that are dictionary managed.
•It also deallocates temporary segments to create free space in the datafiles.
PMON:
The Process Monitor (PMON) is a cleanup type of process that cleans up after failed processes such as the dropping of a user connection due to a network failure or the abend of a user application program. It does the task shown in the figure below:
CKPT:
The Checkpoint (CKPT) process writes information to the database control files that identifies the point in time with regard to the Redo Log Files where instance recovery is to begin should it be necessary. This is done at a minimum, once every three seconds.
checkpoint records 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 record 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
If a Redo Log File fills up and a switch is made to a new Redo Log File (this is covered in more detail in a later module), 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
Logical Structure:
It is helpful to understand how an Oracle database is organized in terms of a logical structure that is used to organize physical objects.
Tablespace:
A tablespace is a logical storage facility (a logical container) for storing objects such as tables, indexes, sequences, clusters, and other database objects. Each tablespace has at least one physical datafile that actually stores the tablespace at the operating system level. A large tablespace may have more than one datafile allocated for storing objects assigned to that tablespace, belongs to only one database.Tablespaces can be brought online and taken offline for purposes of backup and management, except for the SYSTEM tablespace that must always be online. Tablespaces can be in either read-only or read-write status.
Datafile:
Tablespaces are stored in datafiles which are physical disk objects. A datafile can only store objects for a single tablespace, but a tablespace may have more than one datafile – this happens when a disk drive device fills up and a tablespace needs to be expanded, then it is expanded to a new disk drive.The DBA can change the size of a datafile to make it smaller or later. The file can also grow in size dynamically as the tablespace grows.
Segment:
When logical storage objects are created within a tablespace, a segment is allocated to the object. Obviously a tablespace typically has many segments. A segment cannot span tablespaces but can span datafiles that belong to a single tablespace
Extent:
Each object has one segment which is a physical collection of extents. Extents are simply collections of contiguous disk storage blocks. A logical storage object such as a table or index always consists of at least one extent – ideally the initial extent allocated to an object will be large enough to store all data that is initially loaded.As a table or index grows, additional extents are added to the segment. A DBA can add extents to segments in order to tune performance of the system.An extent cannot span a datafile.
Block:
The Oracle Server manages data at the smallest unit in what is termed a block or data block. Data are actually stored in blocks.