Ora-367 on redo headers

Question

Following a refresh of database from a prod copy, after creating new controlfile successfully, got ora-367 on redo headers on alter open resetlogs.
ORA-00367: checksum error in log file header
ORA-00318: log 8 of thread 1, expected file size 512 doesn't match 512
ORA-00312: online log 8 thread 1: '/oracle/PEF/origlogB/log_g18m1.dbf'
logfile 8 header verification failed:367
No logfiles qualified for archival
ALTER SYSTEM ARCHIVE LOG ALL USING BACKUP CONTROLFILE complete
*** 2011-08-16 18:26:50.044
Thread 1: Sequence reset to 1.
Any suggestions appreciated.

Answer 1

Thanks for the reply, Srini :)
However, I discovered what happened.
In case I didn't say before (can't see it while typing this)...
This was a refresh of 1 database (non-prod) from another (prod) and cross-node netbackup/Rman/brbackup used.
What happened was this.
I'd scripted the rman restore separately from recovery, whereas in the past, I'd (as have all our other dbas) scripted both together on separate lines in 1 rman script.
While I was resting, awaiting restore completion (which occurred while I was out), another dba was asked to complete post-processing, that person assuming recovery had been done.
That other dba shutdown the target db, changed the init.ora to reference the correct controlfile locations and db_name, then did startup nomount, created a new control file, changing the db name, tried to bring it up and do post processing only to have problems.
That apparently garbaged my redo headers.
I was able to shutdown, re-edit the init.ora back to point to the temporary source control file and using the source db_name, then restart mount using the controlfile from the source again. Luckily.
That allowed me to complete recovery successfully.
One additional unrelated problem occurred that others who read this might want to know about.
I did not have the same redo log space sizes on disk as the source db did, though OS team was supposed to address this in advance :)...
Thus, my alter open resetlogs, when time to do so as the new target db, failed with no space left on device errors.
I was able to edit my create control file script (taken from a backup controlfile to trace on the source and edited appropriate to the target), forcing it to create smaller redo on the target. (work-around :) ).
I then shutdown again, removed the old redos (1st time I just renamed one to insure it would be recreated by the startup, ... it was)..., then did my create control file and alter open resetlogs with no further problems.
At the filesystem level, I was able to see it creating the redo files on the fly as it opened...
way cool.
Thanks again.