11g New Features : Top 5 Features In 11g

11g New Features : Top 5 Features In 11g
1.ASM Fast Mirror Resync :
ASM offlines a disk whenever it is not able to write to an extent allocated to the disk.In Oracle Database 10g,ASM no longer reads from offlined disks.Shortly after a disk is put offline,ASM drops it from disk group by re-creating the extents allocated to the disk on the remaining disks in the disk groups using redundant extent copies.This process is relatively costly operation and can take hours to complete. 11g introduces ASM Fast Mirror Resync feature which allows quick resynchronization of failed ASM disk.This feature significantly reduces the time it takes to repair a failed diskgroup, potentially from hours to minutes.When a disk goes offline following a transient failure,ASM tracks the extents that are modified during the outage.When the transient failure is repaired,ASM can quickly resynchronize only the ASM disk extents that have been affected during the outage. This tracking mechanism is very efficient as it uses one bit for each modified extent. DISK_REPAIR_TIME,an attribute for the corresponding disk group,determines the duration of disk outage that ASM will tolerate while still being able to resynchonize after you complete the repair.
The default DISK_REPAIR_TIME attribute value is 3.6h .
The REPAIR_TIMER column of V$ASM_DISK shows the amount of time left (in seconds) before an offline disk is dropped.
You can override this attribute with an ALTER DISKGROUP DISK OFFLINE statement and the DROP AFTER clause.
Note:
To use this feature, the disk group compatibility attributes must be set to 11.1 or higher.To enable Advancing compatible.asm / compatible.rdbms attributes from 10.1 to 11.1will enable the following key features:
- Fast mirror resync - Preferred mirror read- Variable size extentsPlease see Note 429098.1 Title: 11g ASM New Feature, The Disk Group Compatibility feature,for additional information.
2.Snapshot Standby :
DatabaseA snapshot standby database is a fully updatable standby database that is created by converting a physical standby database into a snapshot standby database. A snapshot standby database receives and archives, but does not apply, redo data from a primary database. A physical standby database is converted into a snapshot standby database with the following command:
SQL> ALTER DATABASE CONVERT TO SNAPSHOT STANDBY ;
The database is dismounted during conversion and must be restarted before it is mounted.Once a physical standby database has been converted into a snapshot standby database, it can be opened in read-write mode and it is fully updatable. A snapshot standby database continues to receive and archive redo data from the primary database, and this redo data will be automatically applied when the snapshot standby database is converted back into a physical standby database.A snapshot standby database is converted back into a physical standby database with the following SQL command:
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
Once a snapshot standby database has been converted back into a physical standby database and restarted, Redo Apply can be started and all redo received by the snapshot standby database will be applied.

3.Database Replay:
Large business-critical applications are complex and subjected to varying workload.Testing impact of changes to such system (software or hardware changes) becomes very difficult considering the high availability requirement with certain expected performance.Customer will need to have certain level of confidence before implementing the changes to production.The only way to achieve this is to simulate the environment same as production on test machine which is very difficult and also expensive. Database Replay allows you to test the impact of system change by replaying real-world workload on the test system before it is exposed to a production.The production workload (including transaction and dependency) of database server is recorded over an illustrative period of time which could be a peak time.This recorded data is used to replay the workload on a system that has been appropriately configured.This should give high degree of confidence before shipping changes to production.
4.Data Recovery Advisor:
Data Recover Advisor automatically diagnoses data failures, determines and presents appropriate repair options, and executes repairs at user request.The purpose of Data Recovery Advisor is to reduce the mean time to recover (MTTR) and improve manageability and reliability of Oracle Database by providing a centralized tool for automated data repair. In the context of Data Recovery Advisor, a data integrity check is a diagnostic procedure run by the Health Monitor to assess the state of the database or its components. Data integrity checks are invoked reactively when an error occurs. You can also invoke checks manually. The recovery process begins when you either suspect or discover a failure. You can discover failures in many ways, including error messages, alerts, trace files, and data integrity checks. You can then use Data Recovery Advisor to gain information and advice about failures and repair them automatically. A Failure is a persistent data corruption detected by a data integrity check. A Repair is an action that fixes one or more failures.
5.Improved Block Corruption Detection:
In earlier releases, RMAN-detected block corruptions were recorded in V$DATABASE_BLOCK_CORRUPTION. In Oracle Database 11g, live block corruptions are also recorded in that view. This view is automatically updated when corruptions are repaired; for example, using block media recovery or data file recovery. The VALIDATE command is enhanced with many new options such as VALIDATE ... BLOCK and VALIDATE DATABASE.This feature shortens the time to discover block corruptions.