Troubleshooting the Fallback Process
To detect integrity problems, sp_fallback_help can be executed on the fallback server (either directly or via an RPC) at any time. Integrity problems that are detected are:
Some integrity problems can be solved by setting these columns to NULL. Some integrity problems could be fixed by updating a NULL spt_fallback_db.xfallback_dbid to the corresponding sysdatabases.dbid.
-
During active fallback support, no commands should be issued that could affect the physical devices or space allocations on them. Commands like ALTER DATABASE or DISK RESIZE could permanently eliminate the option of the original primary server resuming control of its enrolled databases and devices. If ALTER DATABASE is mistakenly issued, use sp_fallback_permanent_svr and sp_dbremove (the latter on the primary server only).
-
The SA is responsible for passing the proper parameter values when executing sp_fallback_upd_dev_drive. If a bad value is used but realized before activation, then another execution can solve the problem. If activation with a bad value is attempted before the problem is recognized, then sp_fallback_deactivate_svr_db should be enough to allow another execution of sp_fallback_upd_dev_drive.
-
On the primary server, the DBO for a given database can be logged on to a login other than SA. But when fallback is activated, each database is installed with the DBO recorded as the SA. You can, however, execute the necessary procedures to change the DBO of a database that is being actively supported on the fallback server.
-
Like all spt_ tables, the spt_fallback_ tables should not be updated directly unless you are instructed to do so by technical support personnel.