It had been a long time since I last restored this particular database. I had an old init.ora file laying around, so I figured I might as well use it. I started the instance in NOMOUNT mode and fired off my duplication.
About half way through, I received the following error:
ORA-19870: error reading backup piece /nfs/backup/PROD/20100112.3fl38k2l_1_1 ORA-19599: block number 144709 is corrupt in backup piece /nfs/backup/PROD/20100112.3fl38k2l_1_1
Hmm, that's different.
I just figured my backup pieces were corrupt somehow, so I took another backup on the source db. I started restoring it on the QA server, and BAM! Same thing.
This was a job for Oracle Support. I created an SR and while they didn't have an immediate solution for me, they did bring up that there were a couple unverified bugs with compressed backups that might cause this error. Since I was using compressed backup pieces, I figured this was worth a shot to try.
I then took a backup on my production db without compressing the backup pieces. When I went to duplicate on my QA server, the restore part succeeded! The only thing that failed was creating the controlfile which gave me an error about a 9.2 controlfile was not compatible with a 10.2 database. Seems as though the old init.ora file had a compatible=9.2.0 parameter in it which was preventing my controlfile from being created. I change the compatible setting to 10.2.0.3 and recreated my controlfile and recovered my db with no problem.
My Oracle Support Analyst suggested I retry the duplicate using a compressed backup set. Lo and Behold, I was able to duplicate with the compressed pieces. A theory was tested that the compatible parameter set to 9.2 caused Oracle to think my backup pieces were corrupt. I changed the parameter back to 9.2 and sure enough, same error during the duplicate.
Just something to be aware of (And no, the lesson is not be stupid and forget to check your init.ora file).