What does PMON do?

PMON (Process Monitor)

• Process Monitor is an Oracle background process created when you start a database instance. 
• The PMON process will free up resources if a user process fails (release database locks).
• Is in charge to perform process recovery when a user process fails (also when killed).
• Rolls back any open transactions for the process.
• PMON normally wakes up every 3 seconds to perform its housekeeping activities. 
• PMON must always be running for an instance. If not, the instance will terminate.

Check process

The following Unix/Linux command is used to check if the PMON process is running:

$ ps -ef | grep pmon

Speed-up PMON

To speed-up housekeeping, one may also wake-up PMON (process 2 below) manually:

SQL> oradebug setmypid

SQL> oradebug wakeup 2

Instance Recovery Performance

Instance Recovery

Instance and crash recovery are the automatic application of redo log records to Oracle data blocks after a crash or system failure. During normal operation, if an instance is shutdown cleanly as when using a SHUTDOWN IMMEDIATE statement, rather than terminated abnormally, then the in-memory changes that have not already been written to the datafiles on disk are written to disk as part of the checkpoint performed during shutdown.

• Cache Recovery (Rolling Forward)

During the cache recovery step, Oracle applies all committed and uncommitted changes in the redo log files to the affected data blocks. The work required for cache recovery processing is proportional to the rate of change to the database (update transactions each second) and the time between checkpoints.

• Transaction Recovery (Rolling Back)

To make the database consistent, the changes that were not committed at the time of the crash must be undone (in other words, rolled back). During the transaction recovery step, Oracle applies the rollback segments to undo the uncommitted changes. The work required to do transaction recovery is proportional to the number and size of uncommitted transactions when the system fault occurred.

Control the duration of startup after instance failure

Oracle recommends using the FAST_START_MTTR_TARGET initialization parameter to control the duration of startup after instance failure. Fast-start checkpointing is only available with Enterprise Edition. The FAST_START_IO_TARGET initialization parameter has been deprecated in favor of the FAST_START_MTTR_TARGET parameter. 

FAST_START_MTTR_TARGET

1. You should disable or remove the FAST_START_IO_TARGET.
1. LOG_CHECKPOINT_INTERVAL, and LOG_CHECKPOINT_TIMEOUT initialization parameters when using FAST_START_MTTR_TARGET. 
2. Setting these parameters to active values interferes with FAST_START_MTTR_TARGET, resulting in a different than expected value in the TARGET_MTTR column of the V$INSTANCE_RECOVERY view.
2. The maximum value for FAST_START_MTTR_TARGET is 3600, or one hour.
1. If you set the value to more than 3600, then Oracle rounds it to 3600. There is no minimum value for FAST_START_MTTR_TARGET. However, this does not mean that you can target the recovery time as low as you want. 
2. The time to do a crash recovery is limited by the low limit of the target number of dirty buffers, which is 1000, as well as factors such as how long initialization and file open take.
3. If you set the value of FAST_START_MTTR_TARGET too low.
1. Then the effective mean time to recover (MTTR) target will be the best MTTR target the system can achieve. 
2. If you set the value of FAST_START_MTTR_TARGET to such a high value that even in the worst-case recovery would not take that long, then the effective MTTR target will be the estimated MTTR in the worst-case scenario when the whole buffer cache is dirty. 
3. Use the TARGET_MTTR column in the V$INSTANCE_RECOVERY view to see the effective MTTR.

Oracle Alert Log Location

What is the alert log?

This log is there to alert you to major events in the database like:

• When the database was started and stopped.
• When the database was stopped. 
• When a log switch occurs. 
• You can see many other things. 

So the DBA should check the contents of the alert log on a regular basis. 

Alert log Location

The alert log is stored in the directory pointed to by the background dump destination and specified by the background_dump_dest initialization parameter, You can display the location of the alert log directory with SQLPlus or OS commands:

SQL Plus

1. SQL> show parameter background;
2. SQL> select value from v$parameter where name='background_dump_dest';

OS

• UNIX
• find / -name alert*.log 2>/dev/null
• Windows
• dir /s alert*.log