For some systems we use cloning (RMAN DUPLICATE) as a method of refreshing Dev and Test environments from Live. The process of doing a backup-based or active duplicate is not that complicated and typically you do it once, script it and you don’t have to worry too much about it again.
Yesterday we had to refresh a test environment from live, so we used our trusty clone script, but it failed with the following message.
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence ???? and starting SCN of ????
Strange! The message is pretty clear. It is expecting an archived redo log that doesn’t exist. If this were a backup-based clone I would suspect one of the archived redo logs had not been copied across, but this was an active duplicate, so it automatically transports everything from the target to the auxiliary instance. How could it lose something?
I knew I had seen this before, but no matter how much I searched my website, private work notes, MOS or using Uncle Google I couldn’t find the solution. Everything pointed to a missing archived redo log, but that couldn’t be happening on an active duplicate right? Wrong!
After much denial, wailing and gnashing of teeth I remembered the archived redo log backups! During the clone operation an archived redo log backup had kicked in on the target database and deleted all the logs that had been backed up. By the time the active duplicate tried to grab them they were gone and hence the error…
Notes to self:
When you see something like this happen, write a note about it! Don’t think you will remember it next time. You won’t, or you will waste loads of time before you do remember it! How many times do you have to tell yourself, “If it’s not written down it doesn’t exist!”
The error message is trying to tell you the answer. Don’t try and intellectualise your way round it. It’s probably not a bug that is causing some spurious misreporting of the “real problem”. You probably don’t know better than the error trapping. Think less about why the error message might be wrong and think more about what could have caused the situation that resulted in the error, as it is reported.
Don’t write a blog post confessing how rubbish you are at your job or people will find out and… Doh!
Not only have Oracle fixed the bug in 184.108.40.206 that prevented the remote cloning, but they’ve also added the ability to clone directly from non-CDB style instances, giving you another option for migrating from non-CDBs to PDBs. Pretty darn cool if you ask me! 🙂
Some more stuff will be amended over the coming days. If the changes result in some major rewrites I’ll probably blog about them. If not, I’ll just slip them into the articles and make a reference to the fact the specific feature was introduced in 220.127.116.11…