Databases 16 min read

Why Upgrading to Oracle 12cR2 Is Critical: Features, Bugs, and Best Practices

This article explains why enterprises should upgrade to Oracle 12cR2, outlines its key new features such as Multitenant, In‑Memory and Sharding, compares patch counts with earlier releases, details common bugs and work‑arounds, and provides recommended parameters and upgrade references for a smooth migration.

dbaplus Community
dbaplus Community
dbaplus Community
Why Upgrading to Oracle 12cR2 Is Critical: Features, Bugs, and Best Practices

1. Necessity of Upgrading to Oracle 12cR2

Oracle 12cR2 (12.2.0.3) is the final major release of the 12c line and now has long‑term support, making it the right time for databases still on 10g/11g to upgrade, especially those using DB links before 11.2.0.4.

Support for Oracle 11.2 ended on 2018‑12‑31, so critical bug patches are no longer freely available, and changes in SCN ceiling rate algorithms further motivate the upgrade.

Patch counts illustrate the maturity of 12cR2: 2,078 fix patches versus 27,782 for 11.2 and 26,281 for 10.2, indicating fewer known bugs or fewer large‑scale upgrades so far.

2. New Features in Oracle 12c

Multitenant – up to 4,098 PDBs (controlled by max_pdbs)

In‑Memory Option

Sharding

Real‑world usage shows limited adoption of Sharding (due to single Table Family per SDB in 12.2) and In‑Memory (because of use‑case and maintenance costs), while Multitenant remains the most valuable feature, enabling consolidation of many small applications into a single CDB and simplifying PDB migration.

3. Cautious Use of Certain Features

When migrating production OLTP databases to Oracle 12c (including 12cR2, 18c, 19c), consider disabling the following:

Instance Parallel Execution : set PARALLEL_FORCE_LOCAL=TRUE to avoid high inter‑node communication overhead.

Automatic Memory Management : prefer manual SGA/TARGET settings for critical databases.

Result Cache : set result_cache_max_size=0 for most OLTP workloads.

Bloom Filter : disable with _bloom_filter_enabled=FALSE and _bloom_pruning_enabled=FALSE due to false‑positive risks.

Deferred Segment Creation : set deferred_segment_creation=FALSE because of numerous bugs.

4. Notable Bugs and Work‑arounds

Bug 25576813 : PDBs may disappear from a standby after some time; fixed only in Oracle 18c/19c.

Bug 26405036 : Shared pool auto‑grows to >200 GB under manual SGA management (fixed in 19.2). Temporary fix:

oradebug setmypid
oradebug lkdebug -m reconfig lkdebug

Trace file explosion caused by events like AUTO SGA: kmgs_parameter_update_timeout (Bug 25415713) – resolved by installing the one‑off patch.

Additional trace‑related bugs (28174827, 28390273) can be mitigated with:

alter system set events 'trace[krb.*] disk disable, memory disable';
alter system set event='55901 trace name context off';
alter system set event='TRACE[RecordCompose] off';
alter system set event='TRACE[FileWrite] off';
alter system set event='TRACE[QueueWrite] off';

Large‑table TRUNCATE in RAC may hang a node; fixed in the latest PSU.

Client‑side authentication errors after upgrading (ORA‑28040, ORA‑01017) require adding to sqlnet.ora:

SQLNET.ALLOWED_LOGON_VERSION_CLIENT=8
SQLNET.ALLOWED_LOGON_VERSION_SERVER=8

5. Important Parameters

_serial_direct_read=AUTO

– avoid high‑direct‑path reads _lm_tickets=5000 – increase GES messaging tickets _px_use_large_pool=TRUE – use large pool for parallel sessions

_b_tree_bitmap_plans=FALSE
SEC_CASE_SENSITIVE_LOGON=FALSE

– disable case‑sensitive passwords _gc_defer_time=0 – reduce hot‑block contention _datafile_write_errors_crash_instance=FALSE – offline faulty datafiles without shutting down the instance _undo_autotune=FALSE – disable undo auto‑tuning

_use_adaptive_log_file_sync=FALSE
_fix_control='14142884:ON','8560951:ON',…

These settings aim to avoid known bugs and disable optional features that may cause instability.

6. Upgrade References

Upgrading a core database is a complex engineering effort requiring a rigorous plan, test migrations, performance testing, and cut‑over procedures. Experience from large migrations (e.g., 200 TB in under a day) demonstrates the need for thorough validation of performance, stability, availability, and data consistency before production cut‑over.

performanceOracleDatabase UpgradeBug FixesMultitenant12cR2
dbaplus Community
Written by

dbaplus Community

Enterprise-level professional community for Database, BigData, and AIOps. Daily original articles, weekly online tech talks, monthly offline salons, and quarterly XCOPS&DAMS conferences—delivered by industry experts.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.