Block corruptioin after rman restore/recovery

Question

Thanks for taking my question!
Oracle Enterprise Edition 11.1.0.7 on Windows 2008. Using Rman on-line backups COMPRESSED.
Can anyone give me any ideas on why SYSAUX data block corruption should occur after a rman recovery?
Below is my script. Am I missing something? Should I be physically removing the redo? Any ideas welcome?
Thanks!
Kathie
rman> restore until seq = 123
recover until seq = 123
alter database open resetlogs;
Background:
I had to do a rman recovery the other day to restore our database back to the previous day. After the recovery the sysaux table became logically corrupted. I tried to fix data corruption with rman but it said it couldn't after reading thru 6 days of backups. I ended up deleting the database, recreating the database and restoring from an export takien a few hours prior.
I now have a database to test rman recovery. Database has been up and rman backups (compressed) running for several days. I tried to recover back to previouse day and again SYSAUX has logical corruption. I tried to use Rman to recover data corruption but it failed.
I deleted database and recreated it. Took several rman on-line backups (this time not compressed). Did 3rd recovery this time only a few hours back. This time everything worked - no sysaux block corruption but why? The only difference is the recovery used non compressed backups and recovery was a shorter time frame. why ???

Answer 1

I agree the errors are not identical but I am going to stop performing compressed backups until I am sure that is not the issue.
My first two recoveries had logical block corruption and this last one without compression set had no block corruption. I performed the same recovery process for all recoveries and the big difference was the successfull recovery did not have compressed backups. I checked v$database_block_corruption and it shows no errors. I also, performed a backup and verify to double check.
The only issue I can see is below. I am hoping someone can confirm this is normal after "alter database open resetlogs". Can anyone verify that?
Thanks!
Kathie
Thu Aug 27 10:17:49 2009
alter database open resetlogs
RESETLOGS after incomplete recovery UNTIL CHANGE 3587892
Resetting resetlogs activation ID 3129052671 (0xba818dff)
Thu Aug 27 10:17:50 2009
Errors in file e:\oracle\diag\rdbms\cs90dev\cs90dev\trace\cs90dev_m000_2244.trc:
ORA-00316: log 1 of thread 1, type 0 in header is not log file
ORA-00312: online log 1 thread 1: 'E:\ORACLE\11.1.0\ORADATA\CS90DEV\REDO01.LOG'
Errors in file e:\oracle\diag\rdbms\cs90dev\cs90dev\trace\cs90dev_m000_2244.trc:
ORA-00316: log 2 of thread 1, type 0 in header is not log file
ORA-00312: online log 2 thread 1: 'E:\ORACLE\11.1.0\ORADATA\CS90DEV\REDO02.LOG'
Errors in file e:\oracle\diag\rdbms\cs90dev\cs90dev\trace\cs90dev_m000_2244.trc:
ORA-00316: log 3 of thread 1, type 0 in header is not log file
ORA-00312: online log 3 thread 1: 'E:\ORACLE\11.1.0\ORADATA\CS90DEV\REDO03.LOG'
Thu Aug 27 10:17:53 2009
Setting recovery target incarnation to 3