Close Menu
Oracle RAC

ORA-01623 — Orphan Thread Redo Log After RAC to Single Instance Migration

HenriqueBy Updated:8 Mins Read

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

When trying to drop a redo log group after migrating a database from Oracle RAC to Single Instance, the following error appears:

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'

The database won’t allow dropping the redo log because it belongs to thread 2 — which was from the second RAC instance. Even though RAC has been decommissioned and the database now runs as Single Instance, thread 2 and its redo logs remain registered in the controlfile.

In this article, I’ll explain why this happens, how to resolve the ORA-01623, and provide a complete cleanup checklist for RAC to Single Instance migrations.

💡 In practice: One of the databases I manage had to be migrated from a RAC environment to a Single Instance VM — infrastructure consolidation. After the migration, I tried to remove the redo log groups from thread 2 and hit the ORA-01623. The fix is to disable the thread before dropping the logs.

Why the ORA-01623 Error Occurs

In an Oracle RAC environment, each cluster instance has its own redo log thread:

InstanceThreadRedo Log Groups
Instance 1 (node1)Thread 1Groups 1, 2, 3
Instance 2 (node2)Thread 2Groups 11, 12, 13

Each thread is independent — it has its own redo log groups, online logs, and log sequence numbers.

When you migrate the database from RAC to Single Instance, only thread 1 remains active. But thread 2 (and its redo logs) stay registered in the controlfile. The database keeps them because:

  • The controlfile still knows thread 2 exists
  • Thread 2 is still marked as enabled
  • The redo logs from thread 2 may have CURRENT or ACTIVE status from the perspective of the instance that no longer exists

The ORA-01623 appears because Oracle refuses to drop a redo log belonging to an enabled thread — even if no instance is using that thread.

Diagnosis

Before fixing, map the complete state of redo logs and threads.

1. Check all threads and their 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. Check which threads are enabled

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

Typical result after RAC → SI migration:

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

Thread 2 is CLOSED (no instance using it) but still ENABLED — that’s the problem.

3. Check active instances

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

If only one instance appears on thread 1, thread 2 is safe to disable.

Solution

Step 1 — Disable the orphan thread

ALTER DATABASE DISABLE THREAD 2;

Result:

Database altered.

Warning: Only disable a thread if no instance is using it. In an active RAC, disabling a thread in use will bring down the corresponding instance.

Step 2 — Drop the redo log groups from the disabled thread

-- Check which groups belong to thread 2
SELECT group#, thread#, status FROM v$log WHERE thread# = 2;

Drop each one:

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

If any group has CURRENT or ACTIVE status, force a checkpoint first:

ALTER SYSTEM CHECKPOINT;
ALTER SYSTEM SWITCH LOGFILE;

-- Try again
ALTER DATABASE DROP LOGFILE GROUP <group#>;

Step 3 — Remove physical files (if needed)

If the redo logs were on filesystem (not ASM), the physical files may not be automatically removed:

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

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

In ASM, Oracle automatically removes the files when the group is dropped.

Step 4 — Validate

-- Verify only thread 1 logs remain
SELECT group#, thread#, status FROM v$log;

-- Verify thread 2 is disabled
SELECT thread#, status, enabled FROM v$thread;

Complete Cleanup Checklist: RAC to Single Instance Migration

The ORA-01623 is just one of the leftovers from a RAC → SI migration. Here’s the complete cleanup checklist:

1. Redo Log Threads (this article)

ALTER DATABASE DISABLE THREAD 2;
ALTER DATABASE DROP LOGFILE GROUP <group#>;

2. Extra Undo Tablespaces

Each RAC instance had its own undo tablespace. Remove the ones no longer needed:

SELECT tablespace_name, status FROM dba_tablespaces WHERE contents = 'UNDO';
DROP TABLESPACE UNDOTBS2 INCLUDING CONTENTS AND DATAFILES;

3. Residual RAC Parameters

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;

ALTER SYSTEM SET cluster_database = FALSE SCOPE=SPFILE;
ALTER SYSTEM RESET cluster_database_instances SCOPE=SPFILE;
ALTER SYSTEM RESET remote_listener SCOPE=SPFILE;
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 (if used)

SELECT file#, ts#, name FROM v$tempfile;
ALTER TABLESPACE TEMP DROP TEMPFILE '/path/to/extra_temp.dbf';

5. RAC Services

SELECT name, network_name FROM dba_services;
EXEC DBMS_SERVICE.DELETE_SERVICE('service_rac_specific');

6. Archived Logs from Thread 2

rman target /
RMAN> LIST ARCHIVELOG ALL;
RMAN> DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7' THREAD 2;

Quick Checklist

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

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

-- 3. Disable orphan thread
ALTER DATABASE DISABLE THREAD 2;

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

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

-- 6. Check residual RAC parameters
SELECT name, value FROM v$spparameter
WHERE name IN ('cluster_database', 'cluster_database_instances', 'remote_listener')
AND value IS NOT NULL;

Conclusion

The ORA-01623 error appears when trying to drop redo logs from a thread that’s still enabled — a typical scenario after migrating from RAC to Single Instance. The second instance’s thread remains registered in the controlfile even though no instance is using it.

The fix is straightforward:

  1. Verify which threads are enabled and which redo logs belong to each
  2. Confirm no instance is using the orphan thread
  3. Disable the thread with ALTER DATABASE DISABLE THREAD
  4. Drop the redo log groups
  5. Clean up all other RAC leftovers (undo, parameters, services, archived logs)

The ORA-01623 is just the tip of the iceberg — a complete RAC to Single Instance migration requires cleaning up every item in the checklist to avoid future surprises.

References:

Share.

Related Posts

Add A Comment
Leave A Reply