Tales From A Lazy Fat DBA

Redo Log Files are used in a circular fashion.

• One log file is written in sequential fashion until it is filled, and then the second redo log begins to fill.  This is known as a Log Switch.
• When the last redo log is written, the database begins overwriting the first redo log again.

• The Redo Log file to which LGWR is actively writing is called the current log file.
• Log files required for instance recovery are categorized as active log files.
• Log files no longer needed for instance recovery are categorized as inactive log files.

·        Active log files cannot be overwritten by LGWR until ARCn has archived the data when archiving is enabled.

Log Writer Failure

What if LGWR cannot write to a Redo Log File or Group?  Possible failures and the results are:

1. At least one Redo Log File in a Group can be written – Unavailable Redo Log Group members are marked as Invalid, a LGWR trace file is generated, and an entry is written to the alert file – processing of the database proceeds normally while ignoring the invalid Redo Log Group members.
2. LGWR cannot write to a Redo Log Group because it is pending archiving – Database operation halts until the Redo Log Group becomes available (could be through turning off archiving) or is archived.
3. A Redo Log Group is unavailable due to media failure – Oracle generates an error message and the database instance shuts down.  During media recovery, if the database did not archive the bad Redo Log, use this command to disable archiving so the bad Redo Log can be dropped:

ALTER DATABASE CLEAR UNARCHIVED LOG

1. A Redo Log Group fails while LGWR is writing to the members – Oracle generates an error message and the database instance shuts down.  Check to see if the disk drive needs to be turned back on or if media recovery is required.  In this situation, just turn on the disk drive and Oracle will perform automatic instance recovery.

Sometimes a Redo Log File in a Group becomes corrupted while a database instance is in operation.

• Database activity halts because archiving cannot continue.
• Clear the Redo Log Files in a Group (here Group #2) with the statement:

ALTER DATABASE CLEAR LOGFILE GROUP 2;

Minimum size for an On-line Redo Log File is 4MB.

Maximum number of Archiver (ARCn) processes allowed in Oracle 11g DB id 1-30.  Let’s try and check changing the parameter  log_archive_max_processes

SQL> alter system set log_archive_max_processes=35;
alter system set log_archive_max_processes=35
*
ERROR at line 1:
ORA-00068: invalid value 35 for parameter log_archive_max_processes, must be
between 1 and 30

Maximum number of Database Writer (DBWRn)

DB_WRITER_PROCESSES = 2 * number of CPU
Range of value in Oracle 10g- 1 to 20 but in Oracle 11g – 1 to 36.

SQL> alter system set db_writer_processes=20 scope=spfile sid=’orcl’;
System altered.

SMON
The System Monitor carries out a crash recovery when a crashed instance is started up again. It also cleans temporary segments. SMON checks the SCN in all datafile headers when the database is started. Everything is OK if all of these SCNs matches the SCN found in the controlfile. If the SCNs don’t match, the database is in an inconsistent state. SCN Number is the System Change Number provided by Oracle for each committed transaction. When the database in inconsistent state while the database is opened, crash recovery is done. Crash recovery is the recovery of a database in a single-instance configuration or an Oracle Real Application Clusters configuration in which all instances have crashed. In contrast, instance recovery is the recovery of one failed instance by a live instance in an Oracle Real Application Clusters configuration. SMON wakes up every 5 minutes to perform housekeeping activities. SMON must always be running for an instance. If not, the instance will terminate.

SMON_SCN_TIME is the metadata table populated for every five minutes by SMON, If column_tracking_level is set to 1 SMON also updates sys.col_usage$ another metadata table.

PMON
The Process Monitor checks if a user process fails and if so, do all cleaning up of resources that the user process has acquired. In the case of shared server configuration, PMON checks dispatchers and server processes and restarts them if they have failed. It also does another important thing. During service registration, PMON provides the listener with Names of the database services provided by the database. However, if there is no listener at startup, PMON can obviously not register those information. Therefore, PMON tries then periodically to register with the listener, which might take up to 60 seconds. During service registration it provides listener with the following information:

– Name of the associated instance
– Current load and maximum load on instance
– Names of DB services provided by database.
– Information about dedicated servers and dispatchers (depends on database server mode i.e dedicated/shared server mode)

PMON process wakes up at every 60 seconds and provide information to the listener. If any problem arises and your PMON process fails then it’s not possible to register information to listener periodically. In this case you can do ‘Manual service registration’ using command:

ALTER SYSTEM REGISTER;

This command forces the registration of database information to the listener.

MMAN (Memory Manager) is a background process that manages the dynamic resizing of SGA memory areas as the workload increases or decreases.
This process was introduced in Oracle 10g.

DBWR

The Database Writer writes dirty blocks from the database buffer to the datafiles. is determined by the Initialization parameter Initialization parameter DB_WRITER_PROCESSES determines on how many DBWn Processes are started . DBWR also writes the actual SCN with the Block and flushes datafile blocks.

LGWR
The Log Writer writes the redo log buffer from the SGA to the online redo log file. It wakes up for every three seconds to flush from the redo log buffer to the online redo logs or Whenever the redo log buffer is filled up to _log_io_size defaults to 1/3 of the log buffer size) and LGWR is not currently writing. This parameter is defined in units measured in physical operating system blocks, not DB blocks. The operating system block size is (obviously) OS dependent. It can be retrieved through x$kccle. This is called X$ table owned by SYS. The entire X$ tables are memory structures generated by Oracle when instance is spawned. They die with Instance. This is a separate discussion which we do later at another point of time.

RECO
The Distributed Transaction Recovery Process finds pending (distributed) transaction and resolves them.

CKPT
The Checkpoint Process regularly initiates a checkpoint, which uses DBWR to write all dirty blocks back to the datafiles, thus ensuring a consistent state to the database. Since a Checkpoint records the current SCN, in a recovery only redo records with a SCN higher than that of the last checkpoint need to be applied. The ckpt process also updates the datafile headers. The ckeckpoint process was optional in Oracle 7 (set CHECKPOINT_PROCESS=TRUE) and could be enabled to speed-up checkpointing on databases with a large number of files. Starting with Oracle 8i, the checkpoint process is automatically started with the other Oracle processes at instance startup.

ARCH
The Archiver Process archives redo log files if ARCHIVELOG is enabled. This means you have the capability of Media Recovery in case of failure.
Dnnn
The Dispatcher Process is used in a shared server environment. Dispatcher Processes, suppor multi-threaded configuration by allowing user processes to share limited number of server processes.

Snnn
The Shared Server Process is used in a shared server environment. shared Server Processes serve multiple client requests in the multi-threaded server configuration

LMON
The lock manager.

LMD0
AQ Time Manager

TRWR
Trace writer. The System Tracking process.

WMON
The wakeup monitor process.

LCKnnn
Inter-instance locking process.

SNPnnn
The snapshot process.

Qmnn (Queue Monitor)
Optional for Oracle Advanced Queuing which monitors the message queues. Used by Oracle Streams Advanced Queuing.
MMON
It makes snapshots of the database health (statistics) and stores this information in the automatic workload repository. MMON is also responsible for issuing alerts for metrics that exceed their thresholds.  This process was introduced in Oracle 10g.

Automated Storage Management ASM Instance Background Processes(10g)
Below provided are some new background processes added for an ASM instance

RBAL
This processes coordinates re-balance activity for disk groups. In an ASM instance coordinated rebalancing operations. In a DB instance, opens and mount diskgroups from the local ASM instance.

ARBx – Oracle backgroud processes. In an ASM instance, a slave for rebalancing operations

GMON – Oracle backgroud processes. In an ASM instance, diskgroup monitor.

ASMB – Oracle backgroud process. In an DB instance, keeps a (bequeath) persistent DB connection to the local ASM instance. Provides hearthbeat and ASM statistics. During a diskgroup rebalancing operation ASM communicates to the DB AU changes via this connection.

list of the new background processes in Oracle 11g:

VKTM
The virtual keeper of time provides wall-clock time and reference time for other sessions/processes.

FBAR  
The flashback data archiver writes old row-versions of tables with ‘flashback archive’ enabled into flashback data archives on commit.

DIAG
The diagnosibility process (DIAG) runs oradebug commands and triggers diagnostic dumps as part of the new ADR (automatic diagnostic repository) feature.

DIA0
The “other” diagnosibility process detects hangs then triggers DIAG do take diagnostics.

SMCO/Wnnn
The space management coordinator and slaves perform space allocation and reclamation.

There are many more. Please check below link to check various other back-end processes.

http://docs.oracle.com/cd/E14072_01/server.112/e10820/bgprocesses.htm