It’s worth noting that if you’re not restoring data files and applying transaction logs, your recovery process will be very different. If it won’t start, go back to step one and figure out what went wrong. If you’ve followed all the steps correctly, you should be able to start the database at this point. But in other cases, you may want to stop media recovery before you get to some event like a dropped table.
In most cases, you will roll the database forward to the last successful transaction. These will capture an in-progress copy of the database and need media recovery to bring it to a consistent state. It’s also necessary if you use hot backup or the snap-and-sweep method in which you take a snapshot and back that up. This step replays the transactions that have occurred since the backup, bringing the database back to the state it was in before the outage occurred. Once that’s accomplished, apply media recovery if your database product supports it, and you have transaction-log backups. That entails restoring the files from your backup systems to a staging area, and then restoring from the staging area to the database. If you used the dump-and-sweep method, where you dump to disk and sweep that backup into your backup system, you might have to do a two-phase restore. Depending on the method used to back up the database, you may be able to restore the files directly from backup. To do so, first you must restore the data files from the backup system. In most cases database issues can be fixed by restoring the data files and applying media recovery. This way, you can save time and effort during the recovery phase. If you’re not sure what the issue is, try starting it up in phases to zero in on the problem. It could be a double disk failure on your RAID array or accidental deletion of the database.
This may seem obvious, but each database product has a sequence of steps to follow to determine why your database is not running.
0 kommentar(er)
