oracle architecture

76. Name the ORACLE Background Process ?

DBWR - Database Writer.

LGWR - Log Writer

CKPT - Check Point

SMON - System Monitor

PMON - Process Monitor

ARCH - Archiver

RECO - Recover

Dnnn - Dispatcher, and

LCKn - Lock

Snnn - Server.

77.  What Does DBWR do ?

Database  writer  writes  modified blocks from the database buffer cache to the data files.

78.When Does DBWR write to the database ?

DBWR  writes  when  more  data  needs  to  be read into the SGA and too few database  buffers  are free. The least recently used data is written to the data files first. DBWR also writes when CheckPoint occurs.

79. What does LGWR do ?

Log  Writer (LGWR) writes redo log entries generated in the redo log buffer of the SGA to on-line Redo Log File.

80. When does LGWR write to the database ?

LGWR   writes  redo  log  entries  into  an  on-line  redo  log  file  when transactions commit and the log buffer files are full.

81. What is the function of checkpoint(CKPT)?

The  Checkpoint  (CKPT)  process  is  responsible  for  signaling  DBWR  at checkpoints  and  updating  all  the  data  files  and control files of the database.

82. What are the functions of SMON ?

System  Monitor (SMON)  performs instance recovery at instance start-up. In a multiple instance system (one that uses the Parallel Server), SMON of one instance  can  also  perform instance recovery for other instance that have failed SMON also cleans up temporary segments that are no longer in use and recovers  dead  transactions  skipped  during  crash  and instance recovery because of  file-read or off-line errors. These transactions are eventually recovered  by SMON when the tablespace or file is brought back on-line SMON also  coalesces  free  extents  within  the  database  to  make  free space contiguous and easier to allocate.

83.  What are functions of PMON ?

Process Monitor (PMON)  performs process recovery when a user process fails PMON  is  responsible  for cleaning up the cache and Freeing resources that the  process  was using PMON also checks on dispatcher and server processes and restarts them if they have failed.

Startup of RAC database fails with ORA-01105 & ORA-01677

Problem Description
Oracle Data Guard was setup between two RAC databases and after switch-over operation is performed one node of primary database can be opened but another node can't be mounted. Following is the output while starting the instance using srvctl command.

$ srvctl start database -d orcl1
PRCR-1079 : Failed to start resource ora.orcl1.db
ORA-01105: mount is incompatible with mounts by other instances
ORA-01677: standby file name convert parameters differ from other instance
CRS-2674: Start of 'ora.orcl1.db' on 'rac1' failed
CRS-2632: There are no more servers to try to place resource 'ora.orcl1.db' on that would satisfy its placement policy

If we try to start the instance using SQL*Plus it also fails with error message ORA-01105 and ORA-01677 while mounting the database.

Cause of the Problem
The 'ORA-01105: mount is incompatible with mounts by other instances' error indicates that the parameter file does not match with the parameter file of another instance. So, you must verify the list of initialization parameters of one node with the list of initialization parameters on another node. The 'ORA-01677: standby file name convert parameters differ from other instance' error message gives you a hint which specific initialization parameter mismatch with another instance. It means the log_file_name_convert initialization parameter differs between two nodes.

Solution of the Problem
1) The best way to solve the problem is to use shared storage for your database initialization parameter (spfile) and keep same spfile for both instances so that if you perform any modification from database using ALTER SYSTEM command both instance are affected. So, check the spfile location from one instance and use same spfile for another instance.

2) If you use different spfile/pfile to start your database instance then set log_file_name_convert parameter to the same as it is used in another instance so that both instance has same value.

3) Once you ensure same parameter value in both database try to mount and start the instance.

Clusterware Installation fails at the end of CRS on Red Hat Linux 5

Cause
While installing oracle clusterware on Red Hat Enterprise Linux 5.0 at then end of the installation of Cluster Ready Services OUI prompts for the $CRS_HOME/root.sh script to be run on all
of the nodes in the cluster. The fact is when the root.sh script is run on the last node in
the cluster, the script calls the VIPCA utility which fails in RHEL 5. The same failure occurs on Red Hat Enterprise Linux 5.0, and SUSE Linux Enterprise Linux 10.

Solution of The Problem
As a workaround to solve the problem before running the root.sh script on the last node in the cluster,
alter the $CRS_HOME/bin/vipca script commenting out lines 119 through 123:

arch=’uname -m’
# if [ "$arch" = "i686" -o "$arch" = "ia64" -o "$arch" = "x86_64" ]
# then
# LD_ASSUME_KERNEL=2.4.19
# export LD_ASSUME_KERNEL
# fi

After commenting out run root.sh and it should be able to call VIPCA successfully.
But don't comment out the line 118 that is arch=’uname -m’ as it is needed by the root.sh script to set the arch variable.