11g New Features

This is my first blog. As Oracle has just launched 11g so thought to post some new features which I liked most.





11g Dataguard New Feature. 2
Real-Time Query: 2
Snapshot Standby: 2
Transient Logical Standby: 2
Enhanced Data Protection: 2
Enhanced Security: 2
Enterprise Manager Grid Control 11g Enhancements: 2
ROLLING DATABASE UPGRADES. 2
CASCADED DESTINATIONS. 3
11g RMAN Features. 4
Simplified active database duplication. 4
Increased speed of compression when preserving backup space: 4
Optimized undo backup: 4
Ease-of-use by Automatic Network File System (NFS) 4
Enhanced configuration of deletion policies. 4
11g ASM Enhancement 5
ASM Fast Disk Resync Overview.. 5
ASM Preferred Read Failure Groups Overview.. 5
Restricted Mount Disk Group For Fast Rebalance. 6

11g Dataguard New Feature

Real-Time Query:
A physical standby database can be open read-only while apply is active. This allows users attached to a physical standby database to query and report against data that is up to date with the primary database.
Snapshot Standby:
This is a new type of standby database that is created from a physical standby database. Once created, a snapshot standby can be opened read-write to process transactions that are independent of the primary database for test or other purposes. A snapshot standby database will continue to receive and archive updates from the primary database, however, redo data received from the primary will not be applied until the snapshot standby is converted back into a physical standby database and all updates that were made while it was a snapshot standby are discarded. This enables production data to remain in a protected state at all times.
Transient Logical Standby:
Users can convert a physical standby to a transient logical standby database to effect a rolling database upgrade, and then revert to a physical standby once the upgrade is complete (using the KEEP IDENTITY clause). This benefits physical standby users who wish to execute a rolling database upgrade without investing in redundant storage otherwise needed to create a logical standby database.
Enhanced Data Protection:
A Physical Standby can now detect lost datafile writes caused by faulty storage hardware and firmware that lead to data corruption. Data Guard will compare versions of blocks on the standby with that of the incoming redo stream. If there is a version discrepancy it implies a lost write. The user can then failover to the standby database and restore data consistency.
Enhanced Security:
SSL authentication can be used in lieu of password file to authenticate redo transmission. Note: SSL authentication requires use of PKI Certificates, ASO and OID.
Enterprise Manager Grid Control 11g Enhancements:
Enterprise Manager further simplifies management in the areas of:

• Creation of standby databases from existing RMAN backups
• Creation of an Oracle RAC standby database from an Oracle RAC primary.
• Automated standby clones for reporting, development, and test
• Automatic propagation of Enterprise Manager jobs and metric thresholds to the new primary database upon switchover or failover
• Fault-tolerant observer for Fast-Start Failover
• Enterprise Manager Data Recovery Advisor will utilize available standby databases when making recommendations for Intelligent Data Repair (IDR).
ROLLING DATABASE UPGRADES
Oracle Database software upgrades for major release and patchset upgrades (10.1.0.3 onwards) can be performed in a rolling fashion – with near zero database downtime, by using Data Guard SQL Apply (see Figure 2).

Figure 2 –Rolling Database Upgrades with SQL Apply
The steps in a rolling upgrade process involve upgrading the logical standby database to the next release, running in a mixed mode to test and validate the upgrade, doing a role reversal by switching over to the upgraded database, and then finally upgrading the old primary database. While running in a mixed mode for testing purposes, the upgrade can be aborted and the software downgraded, without data loss. For additional data protection during these steps, a second standby database may be used.
Beginning with Oracle Database 11g, a physical standby database can also take advantage of the rolling upgrade feature provided by a logical standby. Through the use of the new KEEP IDENTITY clause option to the SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY statement, a physical standby database can be temporarily converted into a logical standby database for the rolling upgrade, and then reverted back to the original configuration of a primary database and a physical standby database when the upgrade is done.
CASCADED DESTINATIONS
Data Guard provides many flexible configuration options. Using Cascaded Destinations, a physical standby database can forward the redo it receives from the primary database to another standby database. Since the primary database sends redo data to the first standby databases, this feature reduces the load on the primary system, and can also reduce network traffic and use of valuable network resources at the primary site when multiple standby databases are required. Note that Oracle RAC and the Data Guard Broker are not supported in a Data Guard configuration that includes cascaded destinations.

11g RMAN Features

Simplified active database duplication
You can use the "network-aware" DUPLICATE command to create a duplicate or a standby database over the network without a need for pre-existing database backups. The ease-of-use is especially apparent through the Enterprise Manager GUI.
Increased speed of compression when preserving backup space:
You can use the CONFIGURE command to choose between the BZIP2 and ZLIB compression algorithms for RMAN backups. The new ZLIB backup compression algorithm can be 40% faster than previous BZIP2 algorithm. The real world data-warehousing database from one large pharmaceutical company had a compression ratio 2.0:1 with the BZIP2 algorithm, and 1.68:1 with the ZLIB algorithm.
Configure the backup compression algorithm with the following command (replace alg_name with either BZIP2 or ZLIB):
CONFIGURE COMPRESSION ALGORITHM TO 'alg_name';
Note: For more details, see the Oracle Database Backup and Recovery Reference.

Optimized undo backup:
Undo data that is not needed for transaction recovery (for example, for committed transactions), is not backed up. The benefit is reduced overall backup time and storage by not backing up undo that applies to committed transactions. This optimization is automatically enabled.

Ease-of-use by Automatic Network File System (NFS)
The NFS client is implemented as part of Oracle kernel in ODM library. This improves the ease of-use and stability of accessing NAS storage systems, as well as increasing the availability across different platforms while maintaining a consistent interface.

Enhanced configuration of deletion policies
Archived redo logs are eligible for deletion only when not needed by any required consumers such as Data Guard, Streams, Flashback Database, and so on.

In a Data Guard environment, all standby destinations are considered (instead of just mandatory destinations), before marking archive logs to be deleted. This configuration is specified using the CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY command.

When you CONFIGURE an archived log deletion policy, the configuration applies to all archiving destinations, including the flash recovery area. Both BACKUP ... DELETE INPUT and DELETE... ARCHIVELOG use this configuration, as does the flash recovery area.

When you back up the recovery area, RMAN can fail over to other archived redo log destinations if the archived redo log in the flash recovery area is inaccessible or corrupted.
11g ASM Enhancement

ASM Fast Disk Resync Overview
ASM fast disk resync significantly reduces the time required to resynchronize a transient failure of a disk. 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 feature assumes that the content of the affected ASM disks has not been damaged or modified.
When an ASM disk path fails, the ASM disk is taken offline but not dropped if you have set the DISK_REPAIR_TIME attribute for the corresponding disk group. The setting for this attribute determines the duration of a disk outage that ASM tolerates while still being able to resynchronize after you complete the repair.
Note: The tracking mechanism uses one bit for each modified allocation unit. This ensures that the tracking mechanism very efficient.


•Benefits:
•Fraction of time to establish redundancy
•Only changed blocks are resync’ed
•Fast recovery from transient failures
•Enables pro-active maintenance




ASM Preferred Read Failure Groups Overview
When you configure ASM failure groups, ASM in Oracle Database 10g always reads the primary copy of a mirrored extent. It may be more efficient for a node to read from a failure group extent that is closest to the node, even if it is a secondary extent. This is especially true in extended cluster configurations where reading from a local copy of an extent provides improved performance.
With Oracle Database 11g, you can do this by configuring preferred read failure groups using the new initialization parameter, ASM_PREFERRED_READ_FAILURE_GROUPS, to specify a list of preferred read failure group names. The disks in those failure groups become the preferred read disks. Thus, every node can read from its local disks. This results in higher efficiency and performance and reduced network traffic. The setting for this parameter is instance-specific.



•Benefits:

•Allow local mirror read operations
•Eliminate network latencies in extended clusters
•Better performance



Restricted Mount Disk Group For Fast Rebalance
A new mount mode to mount a disk group in Oracle Database 11g is called RESTRICTED. When a disk group is mounted in RESTRICTED mode, clients cannot access the files in a disk group. When ASM instance knows that there are no clients, it can improve the performance of the rebalance operation by not attempting to message clients for locking/unlocking extent maps.
A disk group mounted in RESTRICTED mode is mounted exclusively on only one node and clients of ASM on that node cannot use that disk group.
The RESTRICTED mode allows you to perform all maintenance tasks on a disk group in the ASM instance without any external interaction.
At the end of the maintenance cycle you have to explicitly dismount the disk group and remount it in normal mode.
The ALTER DISKROUP diskgroupname MOUNT command is extended to allow for ASM to mount the diskgroup in restricted mode. An example is shown on the slide.
When you use RESTRICTED option to startup a ASM instance, all the disk groups defined in ASM_DISKGROUPS parameter are mounted in RESTRICTED mode.