The SQL Server fallback feature is invoked by executing system stored procedures. In most cases, these procedures begin with the common prefix sp_fallback_. To shift the control of databases and devices from a broken primary server to a fallback server, one or two procedures are executed on the primary server, but most others are executed on the fallback server. The procedures that are executed on the fallback server can contain remote procedure calls (RPCs) to the primary server.
The sp_fallback_ procedures interact with the sysdatabases, sysdevices, and sysusages system tables of the primary and fallback servers. The system tables on the primary server are only read from; on the fallback server, SELECT, INSERT, UPDATE, and DELETE statements are executed against the system tables. The sp_fallback_ procedures also interact with some corresponding user tables on the fallback server, which are all named with the prefix spt_fallback_.
In general, the sp_fallback_ procedures copy information from the system tables of the primary server into the spt_fallback_ tables on the fallback server to enroll specific databases for future fallback support. If the primary server fails, a procedure is run to recalculate and copy information from those spt_fallback_ tables into the system tables of the fallback server to activate the databases that are enrolled for fallback support. Recalculated information includes the columns sysdatabases.dbid, sysdevices.low, and sysusages.vstart.
After the primary server is repaired, you have the option of running procedures to deactivate the fallback support and return control of the switchable hard drive array to the primary server.