Академический Документы
Профессиональный Документы
Культура Документы
Here’s the scenario: File 3 has gone belly-up, because DISK2, on which it was housed, has
had a head crash and is out of commission. The vendors are rushing you a replacement
hard disk, but it won’t be here until tomorrow –but the database cannot be out of
commission. So how do you recover data file 3 onto another hard disk, albeit a temporary
one?
Well, you’re dealing with a complete recovery here, so the basics don’t change: it’s still a
question of restore (from backup) file 3 somewhere and apply all redo from available redo
logs to bring it up to date. The only catch is the “somewhere”. Fortunately, the
techniques for moving data files don’t suddenly change just because you can’t get the
database open: it’s still a question of using the “alter database rename file” command.
When the new hard disk is installed, and you wish to move the file back to its proper home,
perform the following steps:
Just make sure you always specify full path and filenames… don’t use environment
variables –the Control File seems to get upset from time to time if the path you specify is
not literally and exactly what it expects. I’d recommend querying the name column from
the V$DATAFILE view before attempting any renaming operations, because that shows you
exactly how the Control File stores the details.
Finally, I’ve shown you doing a complete recovery here, from the mount state. The
principles don’t change whatever type of recovery you’re performing. The key is to issue
the ‘alter database’ command before attempting the ‘recover xxx’ command.