Close Menu
Oracle Troubleshooting

ORA-01400 — Como Corrigir “Cannot Insert NULL into DVSYS.REALM_OBJECT$” no Datapatch

HenriqueBy 8 Mins Read

This post is also available in: English (Inglês)

Durante a aplicação de um Release Update (RU) com o datapatch, o processo pode falhar com o seguinte erro:

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

O erro ORA-01400 é genérico — significa que um INSERT tentou colocar NULL em uma coluna NOT NULL. Mas neste contexto específico, ele aparece exclusivamente em bancos com Oracle Database Vault (DV) habilitado, durante a execução do script catmacd.sql que atualiza os objetos do DVSYS.

Neste artigo, vou explicar por que esse erro ocorre, como confirmar que você está no mesmo cenário e como resolver de forma segura e suportada pela Oracle.

💡 Na prática: Encontrei esse erro ao aplicar o RU 19.21 em um banco que estava na versão 19.12 — um salto de 9 Release Updates. O Database Vault estava habilitado e o script de atualização do DVSYS falhava ao tentar popular a coluna OWNER_UID#. A solução oficial da Oracle é executar o datapatch com a flag -ignorable_errors ORA-01400.

Por Que o Erro Ocorre

O Oracle Database Vault (DV) possui tabelas internas no schema DVSYS que controlam realms, regras de acesso e objetos protegidos. Uma dessas tabelas é a DVSYS.REALM_OBJECT$, que possui uma coluna OWNER_UID# com constraint NOT NULL.

Quando o datapatch aplica um Release Update, ele executa o script catmacd.sql — responsável por atualizar os metadados do Database Vault. Em certas combinações de versão, esse script tenta inserir registros onde a coluna OWNER_UID# depende de dados que ainda não foram migrados naquele ponto da execução do patching.

O resultado: o INSERT falha com ORA-01400 porque o valor de OWNER_UID# é NULL no momento da execução.

Quando isso acontece

  • Bancos com Database Vault habilitado — sem DV, o schema DVSYS nem existe
  • Saltos grandes de versão — ex: 19.3 → 19.21, 19.12 → 19.21 (quanto maior o salto, maior a chance)
  • Bug na sequência de execução do catmacd.sql — documentado pela Oracle no MOS
  • Pode ocorrer tanto em Single Instance quanto em RAC

O que NÃO causa esse erro

  • Problemas de permissão ou espaço em disco
  • Falha de SSH ou rede
  • OPatch desatualizado

Diagnóstico

Antes de aplicar a correção, confirme que você está no cenário correto.

1. Verificar se o Database Vault está habilitado

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%';

Se o Database Vault não estiver habilitado ou o schema DVSYS não existir, o seu erro ORA-01400 tem outra causa — este artigo não se aplica.

2. Verificar o estado atual dos patches

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

Procure por patches com status = 'WITH ERRORS'. Esse é o RU que falhou.

3. Verificar o log do datapatch

O caminho do log é mostrado na saída do datapatch. Verifique o erro exatamente:

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

Se o erro estiver em catmacd.sql referenciando DVSYS.REALM_OBJECT$.OWNER_UID#, você está no cenário correto.

Solução: Executar o Datapatch com -ignorable_errors

A Oracle documenta essa solução na MOS Note 2949214.1. A flag -ignorable_errors instrui o datapatch a continuar a execução mesmo encontrando o erro especificado, e reaplicar os scripts que falharam.

Passo 1 — Executar o datapatch com a flag

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

O datapatch vai:

  1. Detectar que o RU anterior falhou com erros
  2. Reaplicar os scripts pendentes
  3. Ignorar o ORA-01400 quando encontrado no catmacd.sql
  4. Continuar com o restante da aplicação
  5. Os dados que estavam faltando são populados em etapas posteriores do script

Passo 2 — Verificar o resultado

Na saída, procure por:

Patch 35643107 apply: SUCCESS
Patch 35648110 apply: SUCCESS

Ambos devem mostrar SUCCESS, não mais WITH ERRORS.

Passo 3 — Validar no banco

-- 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%';

O STATUS do Database Vault deve ser VALID e a versão deve corresponder ao RU aplicado.

Passo 4 — Verificar objetos inválidos

-- 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

O Que a Flag -ignorable_errors Realmente Faz

É importante entender que -ignorable_errors não ignora o erro silenciosamente. O que ela faz:

  1. Registra o erro no log normalmente
  2. Não interrompe a execução do datapatch por causa desse erro específico
  3. Continua aplicando os scripts restantes do RU
  4. Os scripts que dependem dos dados que causaram o ORA-01400 são executados novamente em uma etapa posterior, quando os dados já estão disponíveis
  5. No final, o resultado é SUCCESS porque todos os objetos foram atualizados corretamente

Essa flag é suportada e documentada pela Oracle — não é um hack ou workaround arriscado.

Considerações para Ambientes RAC

Em ambientes RAC com Database Vault, execute o datapatch a partir de um único nó — ele se propaga para o banco compartilhado:

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

Após a execução, verifique o estado em todas as instâncias:

-- 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;

Checklist Rápido de Diagnóstico

-- 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%';

Conclusão

O erro ORA-01400: cannot insert NULL into DVSYS.REALM_OBJECT$.OWNER_UID# durante o datapatch é um bug conhecido que afeta bancos com Oracle Database Vault habilitado, especialmente em saltos grandes de versão de Release Update.

O diagnóstico correto segue esta ordem:

  1. Confirmar que o Database Vault está habilitado (dba_dv_status)
  2. Verificar que o erro é no catmacd.sql referenciando DVSYS.REALM_OBJECT$
  3. Executar datapatch -verbose -ignorable_errors ORA-01400
  4. Validar que todos os patches estão com SUCCESS
  5. Verificar que o Database Vault está VALID e sem objetos inválidos

A flag -ignorable_errors é a solução oficial da Oracle, documentada na MOS Note 2949214.1, e não apresenta riscos ao banco.

Referências:

Share.

Related Posts

Add A Comment
Leave A Reply