Monday, May 4, 2026

Resuming RMAN Duplicate Command

 If you are in a process of cloning a database using RMAN duplicate command, there is a possibility that duplicate command fails in the middle due to some unforeseen problem. If database is relatively small, you may try to re-execute duplicate command from scratch. However, if the database is quite huge in size and most of the work during duplicate has already completed, it is better to continue the duplication process from the point where it failed/aborted. In this article I will discuss a scenario that I faced when duplicate command failed and I continued the process manually from the point where it failed.

Saturday, March 7, 2026

ORA-01507: database not mounted

This error message comes if you are trying to perform aoperation that needs database to be in mount state, however, the current state of the database in NOMOUNT. To explain further, if you are executing a statement that can only be run if database is in MOUNT state, or could either be in MOUNT or OPEN state, but database is only in nomount state, ORA-01507 will be returned. Following are a few examples where you can see ORA-01507 is being returned. And after mounting the database, error no longer appears. 

Saturday, January 17, 2026

ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below

During duplicate command or during normal recovery process of database, if ORA-01547 comes, it would mean that datafile(s) are not consistent after the recovery and need more redo data to be applied to make datafiles consistent. The full error stack could be like the following. 

ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below 

ORA-01194: file 1 needs more recovery to be consistent 

ORA-01110: data file 1: '+DATAC1/operat/system01.dbf' 

Popular Posts - All Times