Oracle 19.29 DBRU — One-off Patch 38854064 and the RAC Corruption Regression

Background

The Oracle Database 19.29 Release Update introduced a fix for bug 34352668 that, under specific conditions, caused a regression affecting RAC environments. In certain Global Cache hang scenarios during a rolling update, this fix could disable lock state error handling on some instances, leading to lock state inconsistencies and, in rare cases, block corruption or lost writes on a standby database.

Oracle released one-off patch 38854064 to address this regression. The patch is RAC Rolling Installable and must be applied with opatch apply -local (one node at a time). It is also Data Guard Standby-First Installable.

The official document is MOS KB867473 — Fix 34352668 in 19.29 and 19.30 Database RU May Cause Corruption in RAC Databases and Redo Corruption Impacting Recovery.

Who Is Affected

MOS KB867473 is explicit about scope. The issue affects multi-instance RAC databases where a RAC rolling database home software update is performed — this explicitly includes standby databases in that scenario, not just primary (the patch's own bug description confirms a real case of "lost write detected in the standby").

The following are not affected per the official note:

• Multi-instance RAC — rolling update (primary or standby): YES, affected
• Single instance RAC (per the MOS note's own wording): not affected
• Non-RAC databases: not affected
• Grid Infrastructure / ASM: not affected
• Autonomous Database: not affected

A note on RAC One Node specifically: the MOS note itself never uses the words "RAC One Node" — it excludes "single instance RAC databases," and RAC One Node reasonably falls under that description since only one instance is active at a time. The explicit statement that RAC One Node is unaffected comes from Mike Dietrich's blog (cited below), not verbatim from KB867473 — worth knowing the difference if you're citing this to someone who wants the primary source.

What Oracle Platinum Support Actually Requires

In our experience, Oracle Platinum Support required patch 38854064 to be applied on all 19.29 Database homes before proceeding with an upgrade to 19.32 — regardless of the RAC type in use.

This means that even on RAC One Node clusters, which the official MOS note explicitly lists as unaffected, Oracle Support made application of this patch a mandatory prerequisite before they would perform or approve the 19.29 to 19.32 upgrade. The patch is included in their standard pre-upgrade checklist for any system running 19.29.

The practical implication: if you are on 19.29 and plan to upgrade to 19.32 (or any later RU) with Oracle Platinum Support involvement, expect this patch to be required regardless of your RAC configuration.

Immediate Mitigation Before Patching

MOS KB867473 recommends executing the following on any one RAC instance as soon as the exposure is identified, independently of the patch schedule:

alter system set "_gcs_recoverable_asserts"=3 scope=both sid='*';
alter system reset "_gcs_recoverable_asserts" scope=both sid='*';

This is a dynamic online operation — no instance restart required. The SET and RESET are executed immediately one after the other as a pair. This is important to understand correctly, because the sources differ on this point (see Differences Between Sources below).

Differences Between Sources

Patch README

The official Oracle patch README (Prerequisites, step 10) only documents the SET statement, with no further context:

alter system set "_gcs_recoverable_asserts"=3 scope=both sid='*';

No RESET is mentioned anywhere in the README. Reading only the README would leave the impression that the parameter should be left set persistently.

MOS KB867473

The MOS note includes both SET and RESET as an immediate pair in all relevant cases (Case 1, 3.1, 3.2.2, 4). The FAQ section (Q3) explains the reasoning: the default value of _gcs_recoverable_asserts is already 3, but due to the regression the internal cached value can be out of sync. The SET forces a resync across all instances; the RESET immediately removes the explicit override since the parameter is no longer needed.

Mike Dietrich's Blog

Mike Dietrich's article (February 2026) provides useful clarification on scope — in particular confirming that RAC One Node is not affected by the corruption issue, since only one instance is active at a time and the bug is triggered specifically during multi-instance rolling update transitions.

How to Apply the Patch

Prerequisites

• Oracle Database 19.29.0.0.251021DBRU (PSU 38291812) must be applied
• OPatch version 12.2.0.1.47 or higher required
• Patch zip: p38854064_1929000DBRU_Linux-x86-64.zip

Update OPatch first (per Oracle Home, on each node):

cd $ORACLE_HOME
mv OPatch OPatch_old
unzip /path/to/p6880880_190000_Linux-x86-64.zip
opatch version

Conflict check

cd /path/to/38854064
opatch prereq CheckConflictAgainstOHWithDetail -ph ./
opatch prereq CheckApplicable -phBaseDir ./

Option A — RAC One Node (with full downtime)

RAC One Node has only one active instance at any given time. The simplest approach is to stop the database, patch both nodes sequentially, then start it again. This is what we used in practice.

1. Save PDB open state (for all open PDBs):

alter pluggable database <PDB_NAME> save state;

2. Immediate mitigation and shutdown:

show parameter _gcs_recoverable_asserts
alter system set "_gcs_recoverable_asserts"=3 scope=both sid='*';
alter system reset "_gcs_recoverable_asserts" scope=both sid='*';
show parameter _gcs_recoverable_asserts

srvctl stop database -d <db_unique_name>
srvctl status database -d <db_unique_name>

3. Apply patch on each node (SSH to each node and run):

cd /path/to/38854064
opatch apply -local
opatch lspatches

4. Start database and verify:

srvctl start database -d <db_unique_name> -n <node_hostname>
srvctl status database -d <db_unique_name>
opatch lspatches | grep 38854064

Option B — RAC One Node (with online relocation, reduced downtime)

If downtime is a concern, RAC One Node supports online database relocation. The instance is relocated to node 2 while node 1 is patched, then relocated back so node 2 can be patched — the database remains available throughout except for the brief relocation windows.

1. Apply immediate mitigation (same as above — SET+RESET pair).

2. Relocate instance to node 2:

srvctl relocate database -d <db_unique_name> -n <node2_hostname>
srvctl status database -d <db_unique_name>

3. Apply patch on node 1 (while database runs on node 2):

cd /path/to/38854064
opatch apply -local
opatch lspatches

4. Relocate instance back to node 1:

srvctl relocate database -d <db_unique_name> -n <node1_hostname>
srvctl status database -d <db_unique_name>

5. Apply patch on node 2 (while database runs on node 1):

cd /path/to/38854064
opatch apply -local
opatch lspatches | grep 38854064

Option C — Full RAC (rolling, per instance)

For a standard multi-instance RAC cluster, the patch is applied in rolling fashion — one instance at a time, while the remaining instances continue serving workload.

1. Apply immediate mitigation on any one instance (same SET+RESET pair, sid='*' propagates to all instances).

2. Save PDB state on all open PDBs.

3. For each node sequentially — stop the instance on that node only (leaving other instances running):

srvctl stop instance -d <db_unique_name> -i <instance_name>
srvctl status database -d <db_unique_name>

Apply patch on that node:

cd /path/to/38854064
opatch apply -local
opatch lspatches

Start the instance back up:

srvctl start instance -d <db_unique_name> -i <instance_name>
srvctl status database -d <db_unique_name>

Repeat for each remaining node.

4. Verify once all nodes are patched:

opatch lspatches | grep 38854064

Rollback

Per the patch README. For RAC, shut down services on the node first, rollback, then start — repeat per node.

opatch rollback -id 38854064
opatch lsinventory

Alternative: Re-released 19.30

If you are planning to move to 19.30 rather than staying on 19.29, Oracle re-released 19.30 on February 2, 2026 with fix 38884142 that backouts the regression. The re-released patch (38632161) carries unique_patch_id 28482211 in its inventory.xml. With this version, patch 38854064 is not required.

If you downloaded 19.30 between January 20–22, 2026, you have the recalled version (unique_patch_id 28443995) — uninstall it and apply the re-released version before proceeding.

The takeaway