Oracle Database 11g Release 2: What's New, Release History & Support Lifecycle

What Is New in Oracle Database 11g Release 2

What is the Oracle Grid Infrastructure and why does it matter for 11g Release 2?

Oracle Grid Infrastructure is the single most architecturally significant change in 11g Release 2, consolidating Oracle Clusterware, Oracle ASM, and -- for single-instance databases -- Oracle Restart into one unified installation layer.

Before 11.2, DBAs managed Oracle Clusterware and ASM as largely separate concerns. In this release they share a common home, a common install path, and a common management framework. In practice this means:

• Oracle Restart monitors, relocates, and automatically restarts single-instance databases, listeners, and ASM instances after an OS reboot or unexpected failure -- without requiring a full RAC license.
• ASM Cluster File System (ACFS) extends ASM storage to non-database files (binaries, application data, logs) and exports them over NFS and CIFS. It uses extent-based allocation with a log-based metadata engine, so file system integrity and fast recovery are built in -- no third-party cluster file system required.
• Oracle Cluster Registry (OCR) can now live inside ASM itself and supports up to five copies for redundancy. Faster service relocation on node failure is a direct result of the improved OCR access model.

Watch out for the home layout change. Grid Infrastructure installs into a separate Oracle home from the database binaries. Runbooks and automation that assume a single ORACLE_HOME for everything will break. Plan your directory structure and oratab entries before the upgrade.

How does RAC One Node change high-availability options in Oracle 11g Release 2?

RAC One Node replaces Cold Cluster Failover and gives single-instance workloads a licensed path to online relocation and instance failover without the cost of a full RAC environment.

With Cold Cluster Failover gone as of 11.2, shops that relied on it must migrate to RAC One Node if they want clusterware-managed failover. The practical advantage is that a RAC One Node database runs on a single node at any given time but can be online-relocated to another cluster node via the srvctl relocate database command -- with no application downtime in most cases. If the active node fails, Clusterware restarts the database on a surviving node automatically.

Oracle Enterprise Manager DB Control gained full RAC One Node awareness in 11.2.0.2, so you can manage the configuration through the GUI rather than exclusively through command-line tools. Most teams running high-availability single-instance databases on shared storage should evaluate RAC One Node as a lower-cost alternative to full RAC before upgrading.

What new SQL and PL/SQL capabilities did Oracle 11g Release 2 introduce for developers?

Oracle 11g Release 2 delivers a meaningful set of SQL analytical enhancements that let you push complex reporting logic fully into the database without workarounds.

LISTAGG is the headline addition -- an ordered aggregate that concatenates column values into a delimited string in a single SQL pass, eliminating the need for home-grown string aggregation tricks using SYS_CONNECT_BY_PATH or custom PL/SQL:

SELECT department_id,
       LISTAGG(last_name, ', ') WITHIN GROUP (ORDER BY last_name) AS employees
FROM   employees
GROUP  BY department_id;

NTH_VALUE is a new analytic window function that retrieves the value of an expression at an arbitrary (nth) position within a window -- a generalization of FIRST_VALUE and LAST_VALUE. The LAG and LEAD window functions gain an IGNORE NULLS option, which had previously required a workaround with conditional expressions. The recursive WITH clause (recursive CTEs) arrives in this release as well, enabling hierarchical queries without CONNECT BY in cases where the recursive pattern is cleaner.

On the PL/SQL side, fine-grained dependency tracking for triggers is now complete. The new PRECEDES keyword (complementing the existing FOLLOWS keyword from 11.1) allows you to control the firing order of multiple triggers on the same table and DML event. This matters if you have complex trigger chains -- previously, firing order was undefined beyond what FOLLOWS allowed. Additionally, IGNORE_ROW_ON_DUPKEY_INDEX in INSERT...SELECT lets you silently skip duplicate-key collisions without an exception handler loop, which simplifies bulk-load patterns significantly.

How did Active Data Guard change disaster recovery and read offload strategies in 11g Release 2?

Active Data Guard in 11g Release 2 dramatically expands standby scale limits and formally establishes the standby as a read-only query destination, turning DR infrastructure into productive capacity.

Up to 30 standby databases are now supported per primary. Combined with the Active Data Guard option -- which allows a physical standby to serve live queries while continuously applying redo -- this makes reader farm architectures practical. Large reporting workloads can be directed to one or more read-only physical standbys with zero impact on the primary OLTP database.

In practice, teams using this feature need to think carefully about:

• Network bandwidth from primary to all standby destinations, especially with synchronous (SYNC) redo transport for maximum protection mode.
• Licensing -- Active Data Guard is a separately licensed option on top of Enterprise Edition. Confirm entitlements before enabling open-for-read on your standbys.
• The Data Guard Broker deprecations that arrived in 11.2.0.2: the HostName instance property and the ADD DATABASE...MAINTAINED AS clause are gone. Review your broker configurations and DGMGRL scripts before upgrading.

This release also allows a physical standby to be temporarily converted to a logical standby for rolling database upgrades via the KEEP IDENTITY clause on ALTER DATABASE RECOVER TO LOGICAL STANDBY, substantially reducing downtime for patch set applications.

What changed about Oracle patch set delivery starting with 11.2.0.2?

Starting with 11.2.0.2, Oracle patch sets became full software distributions rather than differential overlays -- a fundamental change in how environments are built and maintained.

Before this change, a patch set was a relatively small package applied on top of the base release in the same Oracle home. From 11.2.0.2 onward, the patch set is a complete installation. The consequences for operations teams are significant:

• Out-of-place upgrades become the recommended best practice. Install the new patch set into a fresh Oracle home, test, then switch over. In-place upgrades are still supported but are explicitly not recommended by Oracle.
• Direct upgrades from 10.x and 11.x releases directly to the latest patch set are supported -- you do not need to install the base release first.
• DBUA gained a silent (non-interactive) mode to support scripted and automated deployments alongside the GUI wizard, which is important for large fleets.

This change matters significantly for capacity planning. You now need enough disk space for two full Oracle homes during the upgrade window. Automation that uses in-place patch delivery (OPatch overlays) must be redesigned for the new model. Document your deinstall procedures for the old home -- orphaned homes consume significant storage on production servers over time.