When Oracle Object IDs Hit Their Limit: Causes, Impact, and Recovery Strategies

Introduction

At the start of the year a wave of incidents—including massive MongoDB data deletions and a ransomware demand—was followed by a rare Oracle database failure where new objects could no longer be created because the 42‑billion‑range object ID space had been exhausted.

Symptoms

All attempts to create global temporary tables, sequences, or indexes failed with ORA-600 [kkdlron-max-objid], indicating that the next object ID (Object ID) exceeded the database limit of 4254950911. The error appears in MOS article ID 76746.1.

Analysis

Queries on the affected database showed the next object number:

SQL> SELECT dataobj# FROM sys.obj$ where name='_NEXT_OBJECT';
DATAOBJ#
----------
4254950908
SQL> select max(object_id),max(DATA_OBJECT_ID) from dba_objects ;
MAX(OBJECT_ID) MAX(DATA_OBJECT_ID)
-------------- -------------------
4254909633 4254950794

The next ID (4254950908) was only three less than the failing value, confirming the limit was reached. Daily growth statistics revealed that over the last ten days the object ID increased by 2‑4.6 million per day, an implausibly high rate that points to extremely frequent drop/create operations, especially on partitioned tables or indexes.

Root Cause

Oracle uses a 32‑bit object ID (data_object_id) with a theoretical maximum of 4294950911. Frequent DDL that drops and recreates objects rapidly consumes this space. A patch can raise the limit slightly, but the underlying issue remains the high churn of objects.

Mitigation

Short‑term: Apply any available patch for the specific Oracle version (if supported) and perform a logical export/import (impdp) to reset object IDs.

Long‑term: Reduce the frequency of drop/create operations, especially for partitioned tables and indexes; monitor object ID growth and set alerts when daily increase exceeds 100 000; adjust sequence cache sizes; enforce change‑management procedures for DDL.

Recommended Operational Settings

Disable DRM in Oracle RAC environments.

Set default sequence cache to 500 (or higher as needed).

Set AUDSESS$ sequence cache to 1000.

Prohibit DB Links in new application deployments.

Deploy OSW (RAC PRVNET) on all new installations.

Limit tablespaces to a maximum of 1 000 data files.

Ensure daily new object creation does not exceed 10 000.

Reproduction Steps

On a 12cR1 test instance, manually set the next object number near the limit:

update obj$ set dataobj#=4254950905 where name='_NEXT_OBJECT';

Creating a new table immediately reproduced the ORA-600 error.

Post‑Recovery Analysis

After rebuilding the database on a new instance and importing logical structures, the daily object ID growth dropped to around 40 000, confirming that heavy DDL activity drives the exhaustion.

Understanding the Magic Number 4254950911

According to MOS script analysis, the highest sensible object ID is 2147483648 and the absolute maximum ever assigned is 4294950911. The observed error value of 4254950911 is only about 4 million below this ceiling, meaning the patch can only buy a few more days of operation.

LIMIT number:=2147483648; /* Highest sensible object id */
MAXOBJ number:=4294950911;/* Max ever object id */