11g Data Guard New Features

11g Data Guard New Features

Real-Time Query: In Oracle Database 8i it was possible to bring a standby database into READ ONLY mode so that it could be used for reporting purposes, but it was necessary to switch it back to standby mode for reapplication of pending change vectors from the archived redo logs transported from the primary database. Oracle Database 11g now lets me run queries in real time against any physical standby database without any disturbance to receipt and application of redo.

Snapshot Standby Databases: Oracle Database 11g offers another intriguing prospect: the ability to open a physicalstandby database for testing or QA purposes while simultaneously collecting production changes for immediate reapplication in case disaster recovery is required. This snapshot standbydatabase still accepts redo information from its primary, but unlike the first two standby types, it does not apply the redo to the database immediately; instead, the redo is only applied when the snapshot standby database is reconverted back into a physical standby. This offers significant leverage because in theory, a QA environment that requires specifically dedicated, identical hardware is no longer required.

Improved Handling of Role Transitions: The addition of standby snapshot databases brings the total of different Data Guard standby database types to three (physical, logical, and snapshot), so Oracle Database 11g also makes it much easier to transition between these different roles via either Data Guard Broker (DGB) command line execution or Enterprise Manager Grid Control. Role transitions are simpler to execute and complete more quickly than in earlier releases.

Improvements to Rolling Database Upgrades: Oracle Database 11g supports rolling database upgrades to be performed against a physical standby database by first transforming it into a logical standby database with a few simple commands before the upgrade begins. Once the upgrade is done, the logical standby database is reverted to its original physical standby state. Oracle 11gleverages this capability as well as the improved speed and simplicity of role transitions to perform system and database patching in a fraction of the time it would’ve taken in earlier releases, and it’s especially powerful in a Real Application Clusters (RAC) database environment.

SQL Apply Enhancements: Logical standby databases are obviously central to these new role transition features, but they use SQL Apply technology to apply change vectors to data. It therefore makes sense that Oracle Database 11g provides significant improvements to this crucial part of Data Guard architecture. SQL Apply now supports parallel DDL execution, Fine-Grained Auditing (FGA), Virtual Private Database (VPD), and Transparent Data Encryption (TDE), as well as simpler real-time SQL Apply reconfiguration and tuning.

Enhanced Redo Logs Transport: Physical standby databases have always used archived redo logs for application of change vectors to data. Oracle Database 11g augments redo transport with some long-overdue features, including compressionand SSL authentication of redo logs while they’re being transmitted between the primary and standby sites.

Heterogeneous DataGuard: Oracle Database 11g allows the primary and standby databases to use different operating systems (for example, Windows 2003 Server and Oracle Enterprise Linux) as long as both operating systems support the same endianness.

Fast Start Failover Improvements: Oracle introduced this feature set in Release 10gR2, but it’s been enhanced significantly in Oracle 11g to permit much finer-grained control over the conditions under which a fast-start failover would be initiated.

“Live Cloning” of Standby Databases: Finally, Oracle 11g has made it extremely simple to set up a standby database environment because Recovery Manager(RMAN) now supports the ability to clone the existing primary database directly to the intended standby database site over the network via the DUPLICATE DATABASE command set while the target database is active. This means it’s no longer necessary to first generate, then transmit, and finally restore and recover RMAN backups of the primary database on the standby site via tedious (and possibly error-prone!) manual methods; instead, RMAN automatically generates a conversion script in memory on the primary site and uses that script to manage the cloning operation on the standby site with virtually no DBA intervention required. 

About Redo Block Address (RBA)

About Redo Block Address (RBA)

An  RBA (Redo Block Address) points  to  a  specific phyical  location  within a redo logfile . The "tail of the log" is the RBA of the most recent redo entry written to the redo log file . It is ten bytes long and has  three  components .

the log file sequence number  ( 4 bytes)
the log file block number       ( 4 bytes)
the byte offset into the block at which the redo record starts (2 bytes)

For Example :  RBA [0x775.2.10]  maps to Log squence , Block number with byte offset .

There are different types of RBA available in SGA , the following are :

Low RBA : Dirty buffer contains first redo change address called Low RBA. From x$bh we can check low RBA.

High RBA : Dirty buffer contains last and most recent redo changes address called High RBA. From x$bh we can check High RBA.

Checkpoint  RBA : DBWR  has written  buffers from  checkpoint queue  are pointing  to  checkpoint  RBA while  incremental checkpoint  is  enabled. This  RBA copies  in  to  control  file’s checkpoint  progress record. When instance recovery occurs that time it starts from checkpointing  RBA from control  file. We  can check this RBA from x$targetrba (sometimes from x$kccrt).

On-disk RBA : That RBA which was flushed in to online Redo Log File on disk. This RBA recorded in to control file record  section. We can check from x$kcccp for on-disk RBA (sometimes from x$targetrba).

How RBA comes in Pictures :
CKPT records checkpoint information to controlfile for maintaining book keeping information like checkpoint  progress . Each instance checkpoint  refers  to some  RBA (called checkpoint RBA) whose  redo prior to this RBA have been written to disk. Hence recovery time is difference between checkpoint RBA and end of the redo log  .

Given a  checkpoint RBA, DBWR writes  buffers  from  the  head  of  the queue  until  low RBA of the buffer at  the head of the checkpoint queue  is greater  than  the checkpoint  RBA . At  this  point ,CKPT can  record  this checkpoint  progress  record  in  control file  (phase 3).

PHASE(1)  process  initiating  the checkpoint (checkpoiting  RBA or current RBA is marked) (The RBA of the last change made to a buffer) at the time reuqest is initiated.

PHASE (2)  DBWR  writes all  required  buffers  i.e  all  buffers  that  have  been modified at RBAs less than or equal to the checkpoint RBA. After all required buffers have been written, in

PHASE (3)  CKPT process records the completion of the checkpoint in control file.

The checkpoint  RBA  is copied  into  the  checkpoint  progress  record  of  the  controlfile by the checkpoint  heartbeat  once  every  3  seconds. Instance recovery, when needed, begins from the checkpoint  RBA  recorded  in  the  controlfile. The  target  RBA is the point up to which DBWn should seek to advance the checkpoint RBA to satisfy instance recovery objectives.

The term sync RBA is sometimes used to refer to the point up to which LGWR is required to sync the thread. However, this is not a full RBA -- only a redo block number is used at this point.

Post Activities After Database Cloning

Post Activities After Database Cloning

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.

How To Change DBID and DB NAME

How To Change DBID and DB NAME

DBNEWID is a database utility that can change the internal database Identifier(DBID) and database name (DBNAME). The DBNEWID utility solves this problem by allowing us to change any of the following:                                                                                
1) Only the DBID of a database
2) Only the DBNAME of a database
3) Both the DBNAME and DBID of a database

1) Only the DBID of a database :   The DBID is an internal, unique identifier for a database. Because Recovery Manager (RMAN) distinguishes databases by DBID, we could not register a seed database and a manually copied database together in the same RMAN repository.                                                                
Changing the DBID of a database is a serious procedure. When the DBID of a database is changed, all previous backups and archived logs of the database become unusable. This is similar to creating a database except that the data is already in the datafiles. After we change the DBID, backups and archive logs that were created prior to the change can no longer be used because they still have the original DBID, which does not match the current DBID. we must open the database with the RESETLOGS option, which re-creates the online redo logs and resets their sequence to 1 .

Below are steps to change the dbid of the database.

C:\>set ORACLE_SID=test
C:\>sqlplus / as sysdba
SQL*Plus: Release 11.2.0.1.0 Production on Mon May 30 14:16:48 2011
Copyright (c) 1982, 2010, Oracle.  All rights reserved.
Connected to an idle instance.

SQL> startup
ORACLE instance started.

Total System Global Area            263639040 bytes
Fixed Size                                    1373964 bytes
Variable Size                                  205523188 bytes
Database Buffers                            50331648 bytes
Redo Buffers                                  6410240 bytes
Database mounted.
Database opened.
SQL> select name,dbid from v$database;
NAME               DBID
---------             ----------
TEST              2050645904

SQL> archive log list
Database log mode                   Archive Mode
Automatic archival                     Enabled
Archive destination                    USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence       10
Next log sequence to archive    12
Current log sequence                12
SQL> shut immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

SQL> startup mount
ORACLE instance started.
Total System Global Area                263639040 bytes
Fixed Size                                       1373964 bytes
Variable Size                                   205523188 bytes
Database Buffers                             50331648 bytes
Redo Buffers                                   6410240 bytes
Database mounted.

SQL> host nid target=sys/test@test

DBNEWID: Release 11.2.0.1.0 - Production on Mon May 30 14:25:13 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
Connected to database TEST (DBID=2050645904)
Connected to server version 11.2.0
Control Files in database:
D:\APP\MQM\ORADATA\TEST\CONTROL01.CTL
D:\APP\MQM\FLASH_RECOVERY_AREA\TEST\CONTROL02.CTL

Change database ID of database TEST? (Y/[N]) => Y
Proceeding with operation
Changing database ID from 2050645904 to 2050636234
Control File D:\APP\MQM\ORADATA\TEST\CONTROL01.CTL - modified
Control FileD:\APP\MQM\FLASH_RECOVERY_AREA\TEST\CONTROL02.CTL - modified
Datafile D:\APP\MQM\ORADATA\TEST\SYSTEM01.DB - dbid changed
Datafile D:\APP\MQM\ORADATA\TEST\SYSAUX01.DB - dbid changed
Datafile D:\APP\MQM\ORADATA\TEST\UNDOTBS01.DB - dbid changed
Datafile D:\APP\MQM\ORADATA\TEST\USERS01.DB - dbid changed
Datafile D:\APP\MQM\ORADATA\TEST\EXAMPLE01.DB - dbid changed
Datafile D:\APP\MQM\ORADATA\TEST\TEMP01.DB - dbid changed
Control File D:\APP\MQM\ORADATA\TEST\CONTROL01.CTL - dbid changed
Control File D:\APP\MQM\FLASH_RECOVERY_AREA\TEST\CONTROL02.CTL
dbid changed
Instance shut down

Database ID for database TEST changed to 2050636234. All previous backups and archived redo logs for this database are unusable.Database is not aware of previous backups and archived logs in Recovery Area.Database has been shutdown, open database with RESETLOGS option.
Succesfully changed database ID.
DBNEWID - Completed succesfully.

C:\>sqlplus sys/test@test as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Mon May 30 14:26:13 2011
Copyright (c) 1982, 2010, Oracle.  All rights reserved.
Connected to an idle instance.
SQL> startup mount
ORACLE instance started.
Total System Global Area       263639040 bytes
Fixed Size                                 1373964 bytes
Variable Size                             205523188 bytes
Database Buffers                      50331648 bytes
Redo Buffers                            6410240 bytes
Database mounted.
SQL> alter database open resetlogs;
Database altered.

SQL> select name,dbid from v$database;
NAME                  DBID
---------              ----------
TEST                   2050636234

SQL> archive log list
Database log mode                     Archive Mode
Automatic archival                      Enabled
Archive destination                     USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence         1
Next log sequence to archive      1
Current log sequence                  1

2) Only the DBNAME of a database  :  Changing the DBNAME without changing the DBID does not require us to open with the RESETLOGS option, so database backups and archived logs are not invalidated. However, changing the DBNAME does have consequences. We must change the DB_NAME initialization parameter after a database name change to reflect the new name. Also, we may have to re-create the Oracle password file. If we restore an old backup of the control file (before the name change), then we should use the initialization parameter file and password file from before the database name change.

Below are steps to change the database name  of the database :
SQL> shut immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area         263639040 bytes
Fixed Size                               1373964 bytes
Variable Size                           209717492 bytes
Database Buffers                     46137344 bytes
Redo Buffers                          6410240 bytes
Database mounted.
SQL> host nid TARGET=SYS/test@test DBNAME=newtest SETNAME=YES
DBNEWID: Release 11.2.0.1.0 - Production on Mon May 30 14:35:45 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
Connected to database TEST (DBID=2050636234)
Connected to server version 11.2.0
Control Files in database:
D:\APP\MQM\ORADATA\TEST\CONTROL01.CTL
D:\APP\MQM\FLASH_RECOVERY_AREA\TEST\CONTROL02.CTL

Change database name of database TEST to NEWTEST? (Y/[N]) => Y
Proceeding with operation
Changing database name from TEST to NEWTEST
Control File D:\APP\MQM\ORADATA\TEST\CONTROL01.CTL - modified
Control File D:\APP\MQM\FLASH_RECOVERY_AREA\TEST\CONTROL02.CTL - modified
Datafile D:\APP\MQM\ORADATA\TEST\SYSTEM01.DB - wrote new name
Datafile D:\APP\MQM\ORADATA\TEST\SYSAUX01.DB - wrote new name
Datafile D:\APP\MQM\ORADATA\TEST\UNDOTBS01.DB - wrote new name
Datafile D:\APP\MQM\ORADATA\TEST\USERS01.DB - wrote new name
Datafile D:\APP\MQM\ORADATA\TEST\EXAMPLE01.DB - wrote new name
Datafile D:\APP\MQM\ORADATA\TEST\TEMP01.DB - wrote new name
Control File D:\APP\MQM\ORADATA\TEST\CONTROL01.CTL - wrote new name
Control File D:\APP\MQM\FLASH_RECOVERY_AREA\TEST\CONTROL02.CTL - wrote   new name
Instance shut down

Database name changed to NEWTEST. Modify parameter file and generate a new password file before restarting.Succesfully changed database name.
DBNEWID - Completed succesfully.

SQL> exit
C:\>sqlplus / as sysdba
SQL*Plus: Release 11.2.0.1.0 Production on Mon May 30 14:36:39 2011
Copyright (c) 1982, 2010, Oracle.  All rights reserved.
Connected to an idle instance.

SQL> create pfile='c:\inittest.ora' from spfile;
File created.

Now open the pfile inittest.ora and replace db_name parameter value "test"  to "newtest"

SQL> create spfile from  pfile='c:\inittest.ora' ;
File created.
SQL> startup
ORACLE instance started.
Total System Global Area           263639040 bytes
Fixed Size                                  1373964 bytes
Variable Size                              209717492 bytes
Database Buffers                       46137344 bytes
Redo Buffers                             6410240 bytes
Database mounted.
Database opened.
SQL> select open_mode ,name from v$database;
OPEN_MODE            NAME
-------------------- ---------
READ WRITE           NEWTEST

3) Both the DBNAME and DBID of a database

C:\>sqlplus sys/test@newtest as sysdba
SQL*Plus: Release 11.2.0.1.0 Production on Mon May 30 15:54:45 2011
Copyright (c) 1982, 2010, Oracle.  All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> select dbid, name,open_mode from v$database;
      DBID                       NAME                       OPEN_MODE
----------                       ---------                     -----------------
2050636234                   NEWTEST                 READ WRITE

SQL> shut immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

C:\>sqlplus / as sysdba
SQL*Plus: Release 11.2.0.1.0 Production on Mon May 30 16:01:03 2011
Copyright (c) 1982, 2010, Oracle.  All rights reserved.
Connected to an idle instance.

SQL> startup mount
ORACLE instance started.
Total System Global Area             263639040 bytes
Fixed Size                                     1373964 bytes
Variable Size                                 213911796 bytes
Database Buffers                           41943040 bytes
Redo Buffers                                 6410240 bytes
Database mounted.

SQL> host nid target=sys/test@newtest dbname=prod

DBNEWID: Release 11.2.0.1.0 - Production on Mon May 30 16:11:17 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
Connected to database NEWTEST (DBID=2050636234)
Connected to server version 11.2.0
Control Files in database:
D:\APP\MQM\ORADATA\TEST\CONTROL01.CTL
D:\APP\MQM\FLASH_RECOVERY_AREA\TEST\CONTROL02.CTL

Change database ID and database name NEWTEST to PROD? (Y/[N]) => Y
Proceeding with operation
Changing database ID from 2050636234 to 164330150
Changing database name from NEWTEST to PROD
Control File D:\APP\MQM\ORADATA\TEST\CONTROL01.CTL - modified
Control FileD:\APP\MQM\FLASH_RECOVERY_AREA\TEST\CONTROL02.CTL modifd
Datafile D:\APP\MQM\ORADATA\TEST\SYSTEM01.DB - dbid changed, wrote new name
Datafile D:\APP\MQM\ORADATA\TEST\SYSAUX01.DB - dbid changed, wrote new name
Datafile D:\APP\MQM\ORADATA\TEST\UNDOTBS01.DB-dbid changed,wrote new name
Datafile D:\APP\MQM\ORADATA\TEST\USERS01.DB - dbid changed, wrote new name
Datafile D:\APP\MQM\ORADATA\TEST\EXAMPLE01.DB - dbid changed, wrote new name
Datafile D:\APP\MQM\ORADATA\TEST\TEMP01.DB - dbid changed, wrote new name
Control File D:\APP\MQM\ORADATA\TEST\CONTROL01.CTLdbid changd,wrote new name  Control File D:\APP\MQM\FLASH_RECOVERY_AREA\TEST\CONTROL02.CTL - dbid changed, wrote new name
Instance shut down

Database name changed to PROD.  Modify parameter file and generate a new password file before restarting. Database ID for database PROD changed to 164330150.  All previous backups and archived redo logs for this database are unusable.Database is not aware of previous backups and archived logs in  Recovery Area.  Database has been shutdown, open database with RESETLOGS option.  Succesfully changed database name and ID.
DBNEWID - Completed succesfully.

SQL> exit
C:\>sqlplus / as sysdba
SQL*Plus: Release 11.2.0.1.0 Production on Mon May 30 16:43:18 2011
Copyright (c) 1982, 2010, Oracle.  All rights reserved.
Connected to an idle instance.
SQL> startup mount
ORACLE instance started.
Total System Global Area  263639040 bytes
Fixed Size                  1373964 bytes
Variable Size             209717492 bytes
Database Buffers           46137344 bytes
Redo Buffers                6410240 bytes
Database mounted.
SQL> alter database open resetlogs;
Database altered.
SQL> select name,dbid,open_mode from v$database;
NAME              DBID                    OPEN_MODE
---------          ----------                ----------------
PROD            164330150                READ WRITE

About Data Masking

About Data Masking 

Data masking is the process of protecting sensitive information in non-production databases from inappropriate visibility. After sanitization, the database remains perfectly usable - the look-and-feel is preserved - but the information content is secure. The Data Masker software provides a simple, repeatable and "push-button" method of scrambling data in test systems.

It is important to be aware that data masking is appropriate to more than just personal details – sometimes business confidential information is appropriate for masking as well. For example, it may be desirable to prevent quarterly sales figures for some products being present in an outsourced test database.

Why Mask Data :                                                                                                                                    
1) Legal Requirements :  The regulatory environment surrounding the duties and obligations of a data holder to protect the information they maintain are becoming increasingly rigorous in just about every legal jurisdiction. It is a pretty safe assumption that the standards for the security and maintenance of data will become increasingly strict in the future .

2) Loss of Confidence And Public Relations Disasters :   It can reasonably be said in most locations, that if a data escape happens at our organization, then the formal legal sanctions applied by governmental bodies is not the only problem we will be facing. Possibly it may not even be the biggest of our immediate worries.

3) Malicious Exposure :    Most people think the major risk to the information they hold is external entities (and organized syndicates) out to break in and steal the data. The assumption then follows that protecting the network and firewalls is the appropriate and sufficient response. There is no denying that such protection is necessary – however it has been shown that in many cases the data is stolen by malicious insiders who have been granted access to the data

4) Accidental Exposure :   The risk of accidental exposure of information is often neglected when considering the security risks associated with real test data. Often it is thought that “there is no point in masking the test data because everybody has access to production anyways”. Not so, the risks associated with an accidental exposure of the data remain. Often just masking the most sensitive information (credit card numbers, customer email addresses etc) is enough to somewhat mitigate the damage associated with accidental exposure and the masked databases remain just as functional.

What Data To Mask :

I) Light Masking on a Bug-Fix or Fire-Fighting Database .

II) Medium Masking on Internal Development Databases .

III) Thorough Masking on an Outsourced Database .

Is My Data Too Complex to be Masked :

Not likely. Data Masker handles even the most intricate data structures. It can preserve data relationships between rows in tables, between rows in the same table or even internally between columns in the same row. Data synchronization issues of this type can be automatically handled by the addition of simple, easily configured masking rules. Don't worry about the size of the data either - Data Masker has successfully masked tables containing hundreds of millions of rows.

What Platforms and Databases does Data Masker Support :

Oracle, SQL Server and DB2 UDB versions are available. The Data Masker software is installed on a Windows PC and operates on both local and remote databases. There are no server side components for any Data Masker version. Oracle versions 9i, 10g, 11g, Sql Server versions 2000, 2005, 2008 and DB2 UDB (LUW) versions 8.2 or greater are supported.

Oracle Advanced Compression

Oracle Advanced Compression

Oracle Advanced Compression and Oracle Database 11g Release 2 helps manage more data in a cost-effective manner. With data volumes, on average, tripling every two years, Oracle Advanced Compression delivers compression rates of 2-4x across all types of data and applications.storage savings from compression will cascade throughout the data center, reducing network traffic and data backups as well. And by reading fewer blocks off disk, Oracle Advanced Compression also improves query performance.

Oracle Advanced Compression is an option of the Oracle 11g database (separately licensed) that allows data in the database to be compressed. Oracle Advanced Compression offers the following advantages:


1) OLTP Compression  : It allows structured and unstructured data to be compressed on insert,update and delete  operations.The following are features :
New compression algorithm uses deferred or batched approach
Data is inserted as is without compression until  PCTFREE  value is reached.
Compression of data starts once PCTFREE threshold is reached
Can be enabled at  table, partition or tablespace level
No need of decompressing the data during reads
Recommended for low update activity tables

2) Data Pump Compression   : In Data Pump, the compression of metadata was introduced in 10g and compression of "data" was introduced in 11g.This covers the following features :
Both are Inline operation
Save on storage allocation
No need to uncompress before Import
Implemented with COMPRESSION attribute, Values supported are ALL, DATA_ONLY, METADATA_ONLY .

3) Data guard Compression : It includes the following features :
Redo is compressed as it is transmitted over a network .
Helps efficiently utilize network bandwidth when data guard  is across data centers
Faster re-synchronization of Data guard  during gap resolution.
Recommended for low network bandwidth .
Implemented with attribute “COMPRESSION”  of initialization parameter log_archive_dest_n

4) RMAN Backup Compression  : It compresses the RMAN backups.The followinf features are
Supports compression of backups using "ZLIB"  algorithm .
Faster compression and low CPU utilization compared to default BZIP2 (10g) .
Low compression ratio  compared to BZIP2 .
Implement  with  CONFIGURE COMPRESSION ALGORITHM  ‘value’ command where value can be High , Medium(ZLIB) and Low(LZO) .


The Oracle Database 11g Advanced Compression option introduces a comprehensive set of compression capabilities to help customers maximize resource utilization and reduce costs. It allows IT administrators to significantly reduce their overall database storage footprint by enabling compression for all types of data – be it relational (table), unstructured (file), or backup data . Although storage cost savings are often seen as the most tangible benefit of compression, innovative technologies included in the Advanced Compression Option are designed to reduce resource requirements and technology costs for all components of our IT infrastructure, including memory and network bandwidth .

The benefits of compression are manyfold

1) Reduction of disk space used for storage .
2) Reduction in I/O bandwidth requirements .
3) Faster full table scans .
4) Lower server memory usage.