ASM Enhancements and Data Guard Enhancements

ASM Enhancements

Oracle Database 10g introduced Automatic Storage Management (ASM) that at its essence is a file system specifically developed for Oracle database files. Oracle Database 11g expands the reach of ASM with several new features, including-

# SYSASM Role. A new role, SYSASM, has been created so that ASM instances can be managed separately from the roles typically granted for traditional Oracle database instance management.

# ASM Rolling Upgrades. One of the most popular and sensible uses of ASM is in a Real Applications

Cluster (RAC) environment. Oracle Database 10g made it possible to initiate a rolling patch set upgrade to the software in the Oracle database home on each node in the cluster. This ensures that

the clustered database remains accessible at all times because at least one Oracle database instance is active while the patch set is applied to the other node(s). The good news is that Oracle Database 11g now extends this concept to ASM instances in a RAC clustered environment.

# Fast Mirror Resynchronization. An ASM disk group that's mirrored using ASM two-way or three-way mirroring could lose an ASM disk due to a transient failure (e.g., failure of a Host Bus Adapter, SCSI cable, or disk I/O controller). Should this occur, ASM will now utilize the Fast Mirror Resynchronization feature to quickly resynchronize only the extents that were affected by the temporary outage when the disk is repaired, thus reducing the time it takes to restore the redundancy of the mirrored ASM disk group.

# Preferred Mirror Read. An ASM disk group that's mirrored using ASM two-way or three-way mirroring requires the configuration of failure groups. (A failure group defines the set of disks across which ASM will mirror allocation units; this ensures that the loss of any disk(s) in the failure group doesn't cause data loss.) In Oracle Database 11g, it's now possible to inform ASM that it's acceptable to read from the nearest secondary extent (i.e., the extent that's really supporting the mirroring of the ASM allocation unit) if that extent is actually closer to the node that's accessing the extent. This feature is most useful in a Real Application Clusters (RAC) database environment, especially when the primary mirrored extent is not local to the node that's attempting to access the extent.

# Resizable Allocation Unit. Oracle Database 11g now permits an ASM allocation unit to be sized at

either 2, 4, 8, 16, 32, or 64 MB when an ASM disk group is first created. This means that larger sequential I/O is now possible for very large tablespaces, and/or tablespaces with larger block sizes. The extent size is now automatically increased as necessary and this allows an ASM file to grow up to the maximum of 128 TB as supported by Bigfile Tablespaces (BFTs).

# Improved ASMCMD Command Set. ASMCMD now includes several new commands that increase visibility of ASM disk group information, support faster restoration of damaged blocks, and retain and

restore complex metadata about disk groups:

# A system / storage administrator can execute the lsdsk command to view a list of all ASM disks even if an ASM instance is not currently running.

# The remap command utilizes the existing backup of a damaged block on an ASM-mirrored disk group to recover the damaged block to an alternate location elsewhere in the ASM disk group.

# Commands md_backup and md_restore allow a DBA to back up and restore, respectively, the meta-data reflecting the exact structure of an ASM disk group. These new commands are an immense boon

because the recreation of extremely large disk groups consisting of several dozen mount points can be

tedious, time-consuming, and prone to error.

Data Guard Enhancements

Last but most certainly not least, Oracle Database 11g adds plenty of enhancements to its flagship high-avail-ability solution for site survivability, Data Guard:

# Snapshot Standby Database. Prior versions of Oracle Database supported two types of standby

databases: the physical standby, which is an exact duplicate of the primary database and is updated via direct application of archived redo logs; and the logical standby, which contains the same logical information as the primary database, but whose data is organized and/or structured differently than on the primary database and which is updated via SQL Apply. Oracle Database 11g adds a third standby database type, the snapshot standby database, that's created by converting an existing physical standby database to this format. A snapshot standby data-base 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 means that the DBA could convert an existing physical standby database to a snapshot standby for testing purposes, allow developers or QA personnel to make changes to the snapshot standby, and then roll back those data created during testing and immediately reapply the valid production redo data, thus reverting the snapshot standby to a physical standby again.

# Rolling Database Upgrades Support Physical Standby Databases. Oracle Database 10g introduced

the ability to utilize SQL Apply to perform rolling upgrades against a primary database and its logical

standby database. During a rolling upgrade, the DBA first upgrades the logical standby database to the latest database version, and then performs a switchover to make the standby database the primary and vice versa. The original primary database is then upgraded to the new database version, and a switchover reverses the roles once again. This ensures that the only interruption to database access is the time it takes to perform the switchovers. The good news is that Oracle Database 11g now allows a rolling data-base upgrade to be performed on a physical standby database by allowing the physical standby to be converted into a logical standby database before the upgrade begins. After the rolling upgrade is completed, the upgraded logical standby is simply reconverted back into a physical standby.

# Real-Time Query Capability. Active Data Guard will now allow the execution of real-time queries against a physical standby database, even while the physical standby continues to receive and apply redo transactions via Redo Apply. (In prior releases, the physical standby could only be accessed for reporting if it was opened in read-only mode while the application of redo was suspended.) This means that a physical standby database can be utilized more flexibly for read-only reporting purposes; also, the considerable resources needed to create and maintain the standby environment may now be put to much more effective use.

# Expanded Data Type and Security Support. Oracle Database 11g now supports XML Type data stored in CLOB data types on logical standby databases. In addition, Transparent Data Encryption (TDE) can now support encrypted table data as well as encrypted tablespaces, and Virtual Private Database (VPD) is supported for logical standby databases.

# Heterogeneous Data Guard. Finally, it's now possible to set up the primary database site using one

operating system (e.g., Oracle Enterprise Linux 4.4) while using another operating system (e.g., Windows 2003 Server) for the standby database site.