Monday, June 6, 2011

Myth of Commit Causing Buffer to be Flushed to the Disk

Today I have gone through a post of one of the famous Oracle Expert Anup Nanda. The post is very useful and invaluable.This Post is regarding the commit statements. There are very few person who have the knowledge of the oracle internals and Arup is one of them . There is a general confusion that commit means that the data are written to the disk but it is not always. Below is the link regarding the commits statements and hope this will help u  .  



Enjoy    :-) 


Saturday, June 4, 2011

What is Checkpoint ?


A checkpoint is an operation that Oracle performs to ensure data file consistency. When a checkpoint occurs, Oracle ensures all modified buffers are written from the data buffer to disk files. Frequent checkpoints decrease the time necessary for recovery should the database crash, but may decrease overall database performance.                                                                                                                                                 
A checkpoint performs the following three operations:

1.) Every dirty block in the buffer cache is written to the data files. That is, it synchronizes the datablocks in the buffer cache with the datafiles on disk.  It's the DBWR that writes all modified databaseblocks back to the datafiles.                                                           

2.) The latest SCN is written (updated) into the datafile header.

3.) The latest SCN is also written to the controlfiles.

The checkpoint process (CKPT) is responsible for writing checkpoints to the data file headers and control file. Checkpoints occur in a variety of situations. For example, Oracle Database uses the following types of checkpoints:

1.) Thread checkpoints  :     The database writes to disk all buffers modified by redo in a specific thread before a certain target. The set of thread checkpoints on all instances in a database is a database checkpoint. Thread checkpoints occur in the following situations:
  • Consistent database shutdown .
  • ALTER SYSTEM CHECKPOINT statement . 
  • Online redo log switch .
  • ALTER DATABASE BEGIN BACKUP statement                                                                             
2.) Tablespace and data file checkpoints  :    The database writes to disk all buffers modified by redo before a specific target. A tablespace checkpoint is a set of data file checkpoints, one for each data file in the tablespace. These checkpoints occur in a variety of situations, including making a tablespace read-only or taking it offline normal, shrinking a data file, or executing ALTER TABLESPACE BEGIN BACKUP.


3.) Incremental checkpoints  :     An incremental checkpoint is a type of thread checkpoint partly intended to avoid writing large numbers of blocks at online redo log switches. DBWn checks at least every three seconds to determine whether it has work to do. When DBWn writes dirty buffers, it advances the checkpoint position, causing CKPT to write the checkpoint position to the control file, but not to the data file headers.

Other types of checkpoints include instance and media recovery checkpoints and checkpoints when schema objects are dropped or truncated.

Importance of Checkpoints for Instance Recovery  :                                                                               
Instance recovery uses checkpoints to determine which changes must be applied to the data files. The checkpoint position guarantees that every committed change with an SCN lower than the checkpoint SCN is saved to the data files.


Checkpoint Position in Online Redo Log File

During instance recovery, the database must apply the changes that occur between the checkpoint position and the end of the redo thread. As shown in Figure, some changes may already have been written to the data files. However, only changes with SCNs lower than the checkpoint position are guaranteed to be on disk.

Time and SCN of last checkpoint   :
The date and time of the last checkpoint can be retrieved through checkpoint_time in  v$datafile_header view
The SCN of the last checkpoint can be found in v$database.


Enjoy      J J J


Tuesday, May 31, 2011

Post Checking After Database Clonning

As I have already covered the clonning through different method .Here are some Post checklist to check the cloned database  environment.

1.) Check Database Name and DBID :
After successful creation of clonning on same or different server we should try to change the database name and id.(in case of same server, clone has different name) .It is suggested to changed the DBID of clone database because Recovery Manager (RMAN) distinguishes databases by DBID. For more details click here  

2.) Edit the Listener.ora and tnsname.ora files :
Edit the listener file to include the new entry of the clonned database.Invoke  the lsnrctl utility and reload the listener. Similarly check the service name in the tnsnames.ora file. Make sure the connection should be connected to cloned database.

3.) Check all the schedule jobs :
If we have scheduled any scripts ,then make sure that all the jobs are enabled for the clonned database.

4.) Verify the parameter file :
Make sure the location mention in the pfile of the clonned database should be correct. The location and values of the parameter should be valid.

5.) Check tempfile  :
After the successful creation of the clone database ,check the tempfile. If there is no tempfile then add the new tempfile in clone database.

6.) Check the archivelog :
Generally archivelog mode is disabled for UAT/Cloned databases. In case our production database is in archivelog mode, make sure that the clonned database archiving is disable. 

7.) Check for database link :
Check for database link present in the cloned environment. Ensure that these are select only dblinks and will not perform any DML in production databases. If  find any ,then you can either drop these or recreate them to point to any UAT or simply remove/hash out tnsnames entry corresponding to these hosts. Also check for any hard coded IP address in host column in DBA_DB_LINKS.


Enjoy    :-)