По материалам статьи Microsoft Knowledge Base "Bypass (Emergency) Mode and DUMP TRANSACTION WITH NO_LOG"
Информация в этой статье относится к версиям Microsoft SQL Server 4.2x, 6.0, 6.5, 7.0

В критических ситуациях, база данных может быть представлена Вам, как SUSPECT, из-за завершения неудачей её восстановления во время старта сервера, причём обычно, это препятствует любому доступу клиентов к данным. Однако, существует возможность ручного вывода базы данных из состояния SUSPECT в "bypass mode" (также называемого "emergency mode") и последующего исполнения команды SELECT или запуска программы Bulk Copy (BCP), позволяющих осуществить копирование данных в другое место, в целях их сохранения. В то время, когда никто не сможет выполнять никаких легитимных модификаций данных, с помощью этой уловки, можно выполнить DUMP TRANSACTION WITH NO_LOG. Обратите внимание, что использование этой уловки не поддерживается Микрософт, и является потенциально опасной операцией. По этим же причинам, если восстановление базы при запуске будет осуществляться слишком долгое время, Вы не должны прерывать этот процесс, переводить базу данных в bypass mode, и затем выполнять DUMP TRANSACTION WITH NO_LOG.
Все операции сервера, исполняемые в рамках DUMP TRANSACTION, обычно регистрируются в журнале, так, что эти операции можно восстановить или отменить. Однако, эти операции, порождённые непосредственно командой DUMP, также занимают место в transaction log. Если transaction log переполнен, и места недостаточно для нормальной работы сервера, а также для регистрации операций DUMP TRANSACTION, использование опции WITH NO_LOG может предоставить Вам возможность произвести усечение transaction log без регистрации каких - либо операций в журнале.
DUMP TRANSACTION WITH NO_LOG правильно сохраняет транзакции только при относительно нормальных условиях работы сервера. Сервер сам предпринимает определённые меры для гарантии успешности восстановления, даже если на сервере произойдёт сбой во время этой операции. В редких случаях автоматическое восстановление (также называемое, восстановление при запуске - startup recovery) может закончится неудачей, после чего база данных будет отмечена, как SUSPECT. Восстановление закончится неудачей по определенной причине. Очень важно обратить внимание на сообщение в errorlog, которое отражает причину завершения неудачей восстановления, потому что это может помочь локализовать проблему. Восстановление, это процесс поиска и исправления противоречий в базе данных, который восстанавливает или отменяет все транзакции, которые были или активны или завершены после времени исполнения последней контрольной точки. Этот процесс основывается на write-ahead (опережающей записи) природе transaction log (все измененные страниц записываются вначале в журнал регистрации транзакций, и только потом в базу данных). Восстановление состоит из чтения каждой записи журнала, сравнения её timestamp с timestamp соответствующей страницы базы данных, и последующего принятия или отмены этого изменения. Отмена происходит в случае не исполненной транзакции, а восстановление внесённого изменения в случае исполненной транзакции.
После обнаружения в errorlog нужного сообщения, которое относится к ошибке, повлекшей неудачу процесса восстановления, попробуйте перевести состояние базы данных в нормальное NORMAL, с помощью простого перезапуска SQL сервера. Это позволит Вам попробовать выполнить процедуру восстановления второй раз. Вы можете изменить состояние базы данных посредством хранимой процедуры sp_resetstatus. Эта дополнительная хранимая процедура, которую Вы можете установить, воспользовавшись сценарием Instsupl.sql в каталоге Mssql\Install. Для получения дополнительной информации, см. "Resetting the Suspect Status" в документации.
Если восстановление все равно терпит неудачу, обратите внимание на сообщение об ошибках, и войдите в контакт с вашей службой поддержки. Вы должны также убедится в наличии и работоспособности вашей последней резервной копии базы данных, потому что она может понадобится для восстановления работоспособности базы. Однако, многие данные в вашей базе могут быть все еще доступны, хотя их целостность нарушена. Вы можете обращаться к этим данным, установив предварительно состояние базы данных в bypass или emergency mode. Для этого установите для базы данных sysdatabases.status в значение: -32768, которое будет применено после выполнения команды "allow updates". Например, используйте следующую команду:

UPDATE SYSDATABASES SET STATUS=-32768 WHERE NAME='DBNAME'

После исполнения этой инструкции, база данных может быть доступна и станет возможно получить данные с помощью SELECT или BCP. Вы можете сталкиваться с ошибками при выполнении SELECT или BCP, но в большинстве случаев, часть данных удаётся спасти.