Automated Storage Manager

[sukishan]

For 10g, Oracle added Automated Storage Manager (ASM), a no-charge option that provides a grid volume manager for single-instance and RAC-clustered databases. (RAC uses ASM underneath its architecture for its cluster volume management.) Logical unit numbers (LUNs), a logical storage allocation, are assigned by a storage administrator to ASM, which then forms a shared storage pool for database storage. ASM provides striping, mirroring (two- and three-way) and enables DBAs to add storage from the pool to a database without downtime.

ASM reduces DBA labor time in managing storage because storage space allocation and performance tuning (where to place the data for optimum performance) are done automatically by the software and not the DBA. Moreover, customers that implement ASM reduce their need for third-party file systems and volume managers, thus reducing their overall software and maintenance costs. ASM is supported with storage area network (SAN) or network-attached storage. Similar to how it has used reduced server hardware investment to justify RAC, Oracle is now advocating using less-expensive shared storage as a justification for RAC and ASM.

Manageability

Oracle enhanced 10g's manageability to reduce DBA labor time. The 10g product achieves a 25% to 50% reduction in DBA time over 9i RAC, but did not get to the point that a cluster is the same as managing a single system. To that end, Oracle added the capability for 10g to manage multiple databases from a single view. Commands can be run against an entire cluster, a database or a specific instance from one console.

Oracle implemented task automation in 10g, enabling a workflow engine for task execution and rollback. Oracle calls this feature "grid control," and it is enabled through Oracle Enterprise Manager. It also reduced installation time, implemented more self-tuning capabilities, such as for storage performance and automated shared memory tuning, and added more proactive diagnostics to aid root-cause analysis. With Oracle Database 11g (11g), Oracle's Automatic Database Diagnostic Monitoring now runs on a RAC cluster, further reducing the complexity and resources required to manage RAC.

Planned Downtime

The 10g RAC supports rolling patches, OS upgrades and hardware upgrades for the grid without application downtime, but does not support rolling-version upgrades. In 11g, Oracle added support for rolling ASM upgrades and patches. Although Oracle supports rolling DBMS patching, there is always the possibility of a patch requiring downtime due to the nature of the patch.

RAC does not provide transparent failover of update transactions when a cluster node fails. Applications that are not written to survive a database crash may require a restart or re-login. To make applications aware of a database server failure, the developer must write the logic to reconnect with a surviving node and resubmit lost transactions. Because of this, not all independent software vendor (ISV) applications support RAC.