Close Menu
Oracle

ORA-01400 – How to Fix “Cannot Insert NULL into DVSYS.REALM_OBJECT$” in Datapatch

HenriqueBy Updated:8 Mins Read

This post is also available in: Português (Portuguese (Brazil))

When applying a Release Update (RU) with datapatch, the process may fail with the following error:

Patch 35643107 apply: WITH ERRORS
  logfile: /u01/app/oracle/cfgtoollogs/sqlpatch/35643107/25405995/35643107_apply_SVHMBR01.log (errors)
  -> Error at line 239485: script rdbms/admin/catmacd.sql
      - ORA-01400: cannot insert NULL into ("DVSYS"."REALM_OBJECT$"."OWNER_UID#")
      - ORA-06512: at line 7
      - ORA-06512: at line 2

The ORA-01400 error is generic – it means that an INSERT tried to put NULL in a NOT NULL column. But in this specific context, it appears exclusively in banks with Oracle Database Vault (DV) enabled, during the execution of the catmacd.sql script that updates the DVSYS objects.

In this article, I’ll explain why this error occurs, how to confirm that you’re in the same scenario and how to resolve it in a safe and Oracle-supported way.

💡 In practice: I encountered this error when applying RU 19.21 to a database that was on version 19.12 – a jump of 9 Release Updates. Database Vault was enabled and the DVSYS update script failed when trying to populate the OWNER_UID# column. Oracle’s official solution is to run the datapatch with the flag -ignorable_errors ORA-01400.

Why Errors Occur

Oracle Database Vault (DV) has internal tables in the DVSYS schema that control realms, access rules and protected objects. One of these tables is DVSYS.REALM_OBJECT$, which has a OWNER_UID# column with NOT NULL constraint.

When datapatch applies a Release Update, it runs the script catmacd.sql – responsible for updating the Database Vault metadata. In certain version combinations, this script tries to insert records where the OWNER_UID# column depends on data that has not yet been migrated at that point in the patching run.

The result: INSERT fails with ORA-01400 because the value of OWNER_UID# is NULL at the time of execution.

When this happens

  • Banks with Database Vault enabled – without DV, the DVSYS schema doesn’t even exist
  • Big version jumps – e.g. 19.3 → 19.21, 19.12 → 19.21 (the bigger the jump, the greater the chance)
  • Bug in the execution sequence of catmacd.sql – documented by Oracle in MOS
  • Can occur in both Single Instance and RAC

What does NOT cause this error

  • Permission or disk space problems
  • SSH or network failure
  • OPatch out of date

Diagnosis

Before applying the correction, confirm that you are in the correct scenario.

1. Check that the Database Vault is enabled

sqlplus / as sysdba

-- Método 1: Verificar parâmetro
SELECT * FROM dba_dv_status;

-- Método 2: Verificar se o schema DVSYS existe
SELECT username, account_status
FROM dba_users
WHERE username = 'DVSYS';

-- Método 3: Verificar componentes registrados
SELECT comp_name, version, status
FROM dba_registry
WHERE comp_name LIKE '%Vault%';

If Database Vault is not enabled or the DVSYS schema does not exist, your ORA-01400 error has another cause – this article does not apply.

2. Check the current status of patches

SELECT patch_id, action, status, description
FROM dba_registry_sqlpatch
ORDER BY action_time DESC
FETCH FIRST 10 ROWS ONLY;

Look for patches with status = 'WITH ERRORS'. This is the RU that failed.

3. Check the datapatch log

The log path is shown in the datapatch output. Check the error exactly:

# Procurar o erro no log
grep -n "ORA-01400\|DVSYS\|REALM_OBJECT\|catmacd" \
  /u01/app/oracle/cfgtoollogs/sqlpatch/<PATCH_ID>/*_apply_*.log

If the error is in catmacd.sql referencing DVSYS.REALM_OBJECT$.OWNER_UID#you are in the correct scenario.

Solution: Run Datapatch with -ignorable_errors

Oracle documents this solution in MOS Note 2949214.1. The flag -ignorable_errors instructs the datapatch to continue execution even if it encounters the specified error, and to reapply the failed scripts.

Step 1 – Run the datapatch with the flag

$ORACLE_HOME/OPatch/datapatch -verbose -ignorable_errors ORA-01400

The datapatch goes:

  1. Detect that the previous RU failed with errors
  2. Reapply pending scripts
  3. Ignore ORA-01400 when found in the catmacd.sql
  4. Continue with the rest of the application
  5. The missing data is populated in later stages of the script

Step 2 – Check the result

At the exit, look for:

Patch 35643107 apply: SUCCESS
Patch 35648110 apply: SUCCESS

Both should show SUCCESS, no longer WITH ERRORS.

Step 3 – Validate at the bank

-- Verificar que os patches estão aplicados com sucesso
SELECT patch_id, action, status, description
FROM dba_registry_sqlpatch
ORDER BY action_time DESC
FETCH FIRST 10 ROWS ONLY;

-- Verificar componentes do Database Vault
SELECT comp_name, version, status
FROM dba_registry
WHERE comp_name LIKE '%Vault%';

The STATUS of the Database Vault must be VALID and the version must correspond to the RU applied.

Step 4 – Checking for invalid objects

-- Verificar objetos inválidos no DVSYS
SELECT object_name, object_type, status
FROM dba_objects
WHERE owner = 'DVSYS' AND status = 'INVALID';

-- Se houver objetos inválidos, recompilar
@?/rdbms/admin/utlrp.sql

What the -ignorable_errors Flag Really Does

It’s important to understand that -ignorable_errors doesn’t silently ignore the error. What she does:

  1. Logs the error normally
  2. It does not stop the execution of the datapatch because of this specific error
  3. Continue applying the remaining RU scripts
  4. Scripts that depend on the data that caused ORA-01400 are executed again at a later stage, when the data is already available
  5. In the end, the result is SUCCESS because all the objects have been updated correctly

This flag is supported and documented by Oracle – it’s not a risky hack or workaround.

Considerations for RAC Environments

In RAC environments with Database Vault, run the datapatch from a single node – it propagates to the shared database:

# De qualquer nó do RAC
$ORACLE_HOME/OPatch/datapatch -verbose -ignorable_errors ORA-01400

After execution, check the status of all instances:

-- Conectar em cada instância e verificar
SELECT instance_name FROM v$instance;

SELECT patch_id, action, status
FROM dba_registry_sqlpatch
ORDER BY action_time DESC
FETCH FIRST 5 ROWS ONLY;

Quick Diagnostic Checklist

-- 1. Database Vault está habilitado?
SELECT * FROM dba_dv_status;

-- 2. Quais patches falharam?
SELECT patch_id, action, status, description
FROM dba_registry_sqlpatch
WHERE status = 'WITH ERRORS'
ORDER BY action_time DESC;

-- 3. Verificar o erro no log (executar no shell)
-- grep -n "ORA-01400\|DVSYS\|REALM_OBJECT" /u01/app/oracle/cfgtoollogs/sqlpatch/<PATCH_ID>/*_apply_*.log

-- 4. Após a correção: tudo com SUCCESS?
SELECT patch_id, action, status
FROM dba_registry_sqlpatch
ORDER BY action_time DESC
FETCH FIRST 10 ROWS ONLY;

-- 5. Database Vault VALID?
SELECT comp_name, version, status
FROM dba_registry
WHERE comp_name LIKE '%Vault%';

Conclusion

The error ORA-01400: cannot insert NULL into DVSYS.REALM_OBJECT$.OWNER_UID# during datapatch is a known bug that affects banks with Oracle Database Vault enabled, especially in large Release Update version jumps.

The correct diagnosis follows this order:

  1. Confirm that the Database Vault is enabled (dba_dv_status)
  2. Check that the error is in the catmacd.sql referencing DVSYS.REALM_OBJECT$
  3. Execute datapatch -verbose -ignorable_errors ORA-01400
  4. Validate that all patches are with SUCCESS
  5. Check that the Database Vault is VALID and has no invalid objects

The flag -ignorable_errors is Oracle’s official solution, documented in MOS Note 2949214.1, and poses no risk to the bank.

References:

Share.

Related Posts

Add A Comment
Leave A Reply