Close Menu
Oracle Oracle RAC RAC

ORA-01623 — Redo Log de Thread Órfã Após Migração de RAC para Single Instance

HenriqueBy Updated:8 Mins Read

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

Ao tentar remover um grupo de redo log após migrar um banco de dados de Oracle RAC para Single Instance, o seguinte erro aparece:

SQL> ALTER DATABASE DROP LOGFILE GROUP 12;

ERROR at line 1:
ORA-01623: log 12 is current log for instance UNNAMED_INSTANCE_2 (thread 2) - cannot drop
ORA-00312: online log 12 thread 2: '+DATA/DBNAME/ONLINELOG/group_12.595.1080201495'

O banco não permite dropar o redo log porque ele pertence à thread 2 — que era da segunda instância do RAC. Mesmo que o RAC já tenha sido descomissionado e o banco agora rode como Single Instance, a thread 2 e seus redo logs continuam registrados no controlfile.

Neste artigo, vou explicar por que isso acontece, como resolver o ORA-01623 e apresentar um checklist completo de limpeza para quem migrou de RAC para Single Instance.

💡 Na prática: Um dos bancos que administro precisou ser migrado de um ambiente RAC para uma VM Single Instance — consolidação de infraestrutura. Após a migração, fui remover os redo log groups da thread 2 e encontrei o ORA-01623. A solução é desabilitar a thread antes de dropar os logs.

Por Que o Erro ORA-01623 Ocorre

Em um ambiente Oracle RAC, cada instância do cluster tem sua própria thread de redo log:

InstânciaThreadRedo Log Groups
Instância 1 (node1)Thread 1Groups 1, 2, 3
Instância 2 (node2)Thread 2Groups 11, 12, 13

Cada thread é independente — possui seus próprios redo log groups, online logs e log sequence numbers.

Quando você migra o banco de RAC para Single Instance, apenas a thread 1 continua ativa. Mas a thread 2 (e seus redo logs) permanecem registrados no controlfile. O banco os mantém porque:

  • O controlfile ainda sabe que a thread 2 existe
  • A thread 2 ainda está marcada como enabled
  • Os redo logs da thread 2 podem ter status CURRENT ou ACTIVE do ponto de vista da instância que não existe mais

O ORA-01623 aparece porque o Oracle se recusa a dropar um redo log que pertence a uma thread habilitada — mesmo que nenhuma instância esteja usando essa thread.

Diagnóstico

Antes de corrigir, mapeie o estado completo dos redo logs e threads.

1. Verificar todas as threads e seus redo log groups

SELECT
  l.group#,
  l.thread#,
  l.bytes / 1024 / 1024 AS size_mb,
  l.status,
  l.archived,
  lf.member
FROM v$log l
JOIN v$logfile lf ON l.group# = lf.group#
ORDER BY l.thread#, l.group#;

2. Verificar quais threads estão habilitadas

SELECT
  thread#,
  status,
  enabled
FROM v$thread;

Resultado típico pós-migração RAC → SI:

   THREAD# STATUS  ENABLED
---------- ------- --------
         1 OPEN    PUBLIC
         2 CLOSED  PUBLIC

A thread 2 está CLOSED (nenhuma instância usando) mas ainda ENABLED (habilitada) — esse é o problema.

3. Verificar instâncias ativas

SELECT instance_name, thread#, status FROM gv$instance;

Se só aparece uma instância na thread 1, a thread 2 é segura para desabilitar.

Solução

Passo 1 — Desabilitar a thread órfã

ALTER DATABASE DISABLE THREAD 2;

Resultado:

Database altered.

Atenção: Só desabilite uma thread se nenhuma instância está usando. Em RAC ativo, desabilitar uma thread em uso derruba a instância correspondente.

Passo 2 — Dropar os redo log groups da thread desabilitada

-- Verificar quais groups pertencem à thread 2
SELECT group#, thread#, status FROM v$log WHERE thread# = 2;

Dropar cada um:

ALTER DATABASE DROP LOGFILE GROUP 11;
ALTER DATABASE DROP LOGFILE GROUP 12;
ALTER DATABASE DROP LOGFILE GROUP 13;

Se algum group tiver status CURRENT ou ACTIVE, force um checkpoint antes:

ALTER SYSTEM CHECKPOINT;
ALTER SYSTEM SWITCH LOGFILE;

-- Tentar novamente
ALTER DATABASE DROP LOGFILE GROUP <group#>;

Passo 3 — Remover os arquivos físicos (se necessário)

Se os redo logs estavam em filesystem (não ASM), os arquivos físicos podem não ser removidos automaticamente:

ls -la /u02/app/oracle/oradata/DBNAME/onlinelog/group_12*

rm /u02/app/oracle/oradata/DBNAME/onlinelog/group_12*

Em ASM, o Oracle remove os arquivos automaticamente ao dropar o group.

Passo 4 — Validar

-- Verificar que só restam logs da thread 1
SELECT group#, thread#, status FROM v$log;

-- Verificar que a thread 2 está desabilitada
SELECT thread#, status, enabled FROM v$thread;

Checklist Completo de Limpeza Pós-Migração RAC → Single Instance

O ORA-01623 é apenas um dos resíduos de uma migração RAC → SI. Aqui está o checklist completo de limpeza:

1. Redo Log Threads (este artigo)

-- Desabilitar threads órfãs
ALTER DATABASE DISABLE THREAD 2;

-- Dropar redo log groups
ALTER DATABASE DROP LOGFILE GROUP <group#>;

2. Undo Tablespaces extras

Cada instância RAC tinha seu próprio undo tablespace. Remova os que não são mais necessários:

-- Verificar undo tablespaces
SELECT tablespace_name, status FROM dba_tablespaces WHERE contents = 'UNDO';

-- Dropar o undo da instância 2
DROP TABLESPACE UNDOTBS2 INCLUDING CONTENTS AND DATAFILES;

3. Parâmetros RAC residuais

-- Verificar parâmetros com referência a instâncias
SELECT name, value FROM v$spparameter
WHERE name IN ('instance_number', 'thread', 'undo_tablespace',
               'cluster_database', 'cluster_database_instances',
               'remote_listener')
AND value IS NOT NULL;

-- Ajustar parâmetros para Single Instance
ALTER SYSTEM SET cluster_database = FALSE SCOPE=SPFILE;
ALTER SYSTEM RESET cluster_database_instances SCOPE=SPFILE;
ALTER SYSTEM RESET remote_listener SCOPE=SPFILE;

-- Remover parâmetros específicos da instância 2
ALTER SYSTEM RESET undo_tablespace SCOPE=SPFILE SID='DBNAME2';
ALTER SYSTEM RESET thread SCOPE=SPFILE SID='DBNAME2';
ALTER SYSTEM RESET instance_number SCOPE=SPFILE SID='DBNAME2';

4. Temp Tablespace Groups (se usados)

-- Verificar se há temp files extras
SELECT file#, ts#, name FROM v$tempfile;

-- Remover temp files extras se necessário
ALTER TABLESPACE TEMP DROP TEMPFILE '/path/to/extra_temp.dbf';

5. Services RAC

-- Verificar services
SELECT name, network_name FROM dba_services;

-- Remover services específicos do RAC (se não forem mais necessários)
EXEC DBMS_SERVICE.DELETE_SERVICE('service_rac_specific');

6. Archived Logs da Thread 2

rman target /
RMAN> LIST ARCHIVELOG ALL;

RMAN> DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7' THREAD 2;

Checklist Rápido

-- 1. Verificar threads
SELECT thread#, status, enabled FROM v$thread;

-- 2. Verificar redo logs por thread
SELECT group#, thread#, status FROM v$log ORDER BY thread#, group#;

-- 3. Desabilitar thread órfã
ALTER DATABASE DISABLE THREAD 2;

-- 4. Dropar redo logs
ALTER DATABASE DROP LOGFILE GROUP <group#>;

-- 5. Verificar undo tablespaces extras
SELECT tablespace_name, status FROM dba_tablespaces WHERE contents = 'UNDO';

-- 6. Verificar parâmetros RAC residuais
SELECT name, value FROM v$spparameter
WHERE name IN ('cluster_database', 'cluster_database_instances', 'remote_listener')
AND value IS NOT NULL;

Conclusão

O erro ORA-01623 aparece ao tentar dropar redo logs de uma thread que ainda está habilitada — cenário típico após migração de RAC para Single Instance. A thread da segunda instância continua registrada no controlfile mesmo que nenhuma instância a utilize.

A correção é direta:

  1. Verificar quais threads estão habilitadas e quais redo logs pertencem a cada uma
  2. Confirmar que nenhuma instância usa a thread órfã
  3. Desabilitar a thread com ALTER DATABASE DISABLE THREAD
  4. Dropar os redo log groups
  5. Limpar os demais resíduos do RAC (undo, parâmetros, services, archived logs)

O ORA-01623 é apenas a ponta do iceberg — uma migração RAC → Single Instance completa requer a limpeza de todos os itens do checklist para evitar surpresas futuras.

Referências:

Share.

Related Posts

Add A Comment
Leave A Reply