disk refit is used to restore sysdatabases and sysusages when you must perform disaster recovery on a failed database, but the last database dump does not contain the most current information about devices and/or databases. disk refit examines the disk allocations in sysdevices and rebuilds sysdatabases and sysusages.
However, disk refit can abort or encounter an error if it finds incorrect device allocation. For example, suppose you drop a database and recreate it (or create a new database) on a different set of devices. If you never reuse some or all of the space previously occupied by the old database, this leaves two sets of allocation pages written to disk for the same dbid: one for the old database version and one for the new. The same issue can occur in tempdb if you simply update sysusages by hand to show that tempdb is on a different device, then reboot the server. If allocation page 0 of the old database remains on the disk, this also leaves an old copy of that database’s dbinfo structure.
These types of activities cause a variety of problems that manifest in different ways when you must later run disk refit as part of disaster recovery. This writeup examines the various problems, their symptoms and how to correct them.
