Redo log moved

Question

Hello everyone,
We have Oracle 10g running on Redhat r3, and a database on a partition. As this partition got full I foolly tried to make some space by moving the redolog files (we have 3 groups with 1 file each) to another partition. The system was restarted, but Oracle didn's start properly but we got "ORA-01033: Oracle initiralization or shutdown in progress". The files were moved back to their position but the sequence on the files differ from the one expected: The system expects [...29] and we have[...26],[...27] and [...28] in the respective files. It is a test database so the consistency is not a problem. I tried "recover ... until cancel" but then I got "ORA-01194: file (system01.dbf) needs more recovery to be consistent". I read other similat threds but none of them gave a solution. Is ther any way I can solve it whether by changing the value of the expected sequence number (how?) whether by ignoring this inconsintency. We would like to be able to use our current data without but we are not concerned about being able to roll it back, it would be ok to have something like a "reincarnation". By the way, we had achiving off when this happened.
Any suggestions will be very appreciated.
Best regards

Answer 1

Hi,
as a last resort, you can recreate the controlfiles. That could get you over the "datafile needs more recovery" after incomplete recovery, where there are no archivelogs and messed up redologs. Be warned, in case you are using RMAN backups with the controlfile (the /nocatalog), you will loose the RMAN metadata stored in the controlfile.
To get a list of controlfiles, use
SQL> select name from v$controlfile;
With database in mount state, issue
SQL> alter database backup controlfile to trace;
That will create a trace file in background dump dest (where the alert log is). In the trace file, you find the commands for recreating the controlfile. You go for the RESETLOGS case.
Shutdown the instance. Remove (or better rename) all control files (the create controlfile statement cannot overwrite existing controlfiles).
Startup the database in nomount state.
sqlplus / as sysdba
SQL> startup nomount;
Run the command from the trace file to re-create controlfile, it looks something like the following (BUT USE YOUR OWN FROM THE TRACE FILE!):
SQL>
CREATE CONTROLFILE REUSE DATABASE "ORCL" RESETLOGS NOARCHIVELOG
MAXLOGFILES 5
MAXLOGMEMBERS 3
MAXDATAFILES 14
MAXINSTANCES 1
MAXLOGHISTORY 226
LOGFILE
GROUP 1 'E:\ORACLE\ORADATA\ORCL\REDO01.LOG' SIZE 100M,
GROUP 2 'E:\ORACLE\ORADATA\ORCL\REDO02.LOG' SIZE 100M,
GROUP 3 'E:\ORACLE\ORADATA\ORCL\REDO03.LOG' SIZE 100M
DATAFILE
'E:\ORACLE\ORADATA\ORCL\SYSTEM01.DBF',
'E:\ORACLE\ORADATA\ORCL\UNDOTBS01.DBF',
'E:\ORACLE\ORADATA\ORCL\EXAMPLE01.DBF',
'E:\ORACLE\ORADATA\ORCL\INDX01.DBF',
'E:\ORACLE\ORADATA\ORCL\TOOLS01.DBF',
'E:\ORACLE\ORADATA\ORCL\USERS01.DBF',
'E:\ORACLE\ORADATA\ORCL\OEM_REPOSITORY.DBF',
'E:\ORACLE\ORADATA\ORCL\CWMLITE01.DBF',
'E:\ORACLE\ORADATA\ORCL\DRSYS01.DBF',
'E:\ORACLE\ORADATA\ORCL\ODM01.DBF',
'E:\ORACLE\ORADATA\ORCL\XDB01.DBF',
'E:\ORACLE\ORADATA\ORCL\USERS02.DBF',
'E:\ORACLE\ORADATA\ORCL\USERS03.DBF',
'E:\ORACLE\ORADATA\ORCL\USERS04.DBF'
CHARACTER SET WE8MSWIN1252
Then, skip the recover statements (as that was leading to nowhere) and issue the
SQL> ALTER DATABASE OPEN RESETLOGS;
If it opens, add the tempfiles to temporary tablespaces, the commands are at the end of the generated trace file:
SQL> ALTER TABLESPACE TEMP add tempfile '....' reuse;
Good luck with that,
Martin