Как принудительно уронить MS SQL Server чтобы он ушёл на перезагрузку

ALARM! В данном кратком материале приведена краткая инструкция того, чего НЕ СЛЕДУЕТ делать при попытке прочитать существующие логи в базе.

При чтении логов из базы данных, а именно, из LDF данных, в большинстве случаев вы наткнётесь на такие функции в запросе как sys.fn_dblog(null, null), sys.fn_dblog_xtp(null, null)

Читать из LDF Вы захотите по различным причинам, но так или иначе основная проблема будет «у нас откуда-то списались деньги остатки, пропал товар, упал прод, разберитесь».

Допустим, Вы захотите воскресить удалённый, дропнутый объект из базы.

Типичный скрипт

--Recover Script of Dropped objects. SELECT        CONVERT(varchar(max), SUBSTRING(                 [RowLog Contents 0],     33,     LEN([RowLog Contents 0])             )        ) AS Script FROM fn_dblog(NULL, NULL) --LDF WHERE Operation = 'LOP_DELETE_ROWS' --удаление строк AND  Context = 'LCX_MARK_AS_GHOST' AND AllocUnitName = 'sys.sysobjvalues.clst' --Откуда строки удаляются. В данном случае изменения в реестре объектов.  AND [TRANSACTION ID] IN (     SELECT DISTINCT  [TRANSACTION ID]  --Нужна именнно транзакция в промежуток времени.     FROM sys.fn_dblog(NULL, NULL) --в рамках которой было удаление объекта из sysobjvalues     WHERE  Context IN ('LCX_NULL')     AND Operation IN ('LOP_BEGIN_XACT') --Начало транзакции     AND  [Transaction Name] =  'DROPOBJ' --Операция DROP     AND CONVERT(nvarchar(11), [Begin Time])  BETWEEN  '2024/07/10' AND '2024/07/11' ) AND  SUBSTRING([RowLog Contents 0], 33, LEN([RowLog Contents 0])) <> 0; --Есть контент

Если выполнить этот скрипт один раз ничего страшного не произойдёт. Но что если Вы делаете запросы слишком часто из-за того, что редиска снёс целую гору объектов?
Сервер по-прежнему будет работать, пока Вы не будете лезть глубже.

А именно, если вдруг Вам захотелось использовать sys.fn_dblog_xtp(null, null) то будьте готовы, что при очередном запросе Ваш сервер упадёт.

Так что не джуновское это дело — читать логи LDF скуля.

Если что, то в журнале Вы увидите следующие строки

07/10/2024 14:25:01,spid10s,Unknown,SQL Server is terminating in response to a 'stop' request from Service Control Manager. This is an informational message only. No user action is required. 07/10/2024 14:25:01,spid10s,Unknown,Always On: The availability replica manager is going offline because SQL Server is shutting down. This is an informational message only. No user action is required. 07/10/2024 14:25:01,spid56,Unknown,Configuration option 'Agent XPs' changed from 1 to 0. Run the RECONFIGURE statement to install.

Основная причина останова написана в строке «SQL Server is terminating in response to a ‘stop’ request from Service Control Manager.«.

Так что не лезьте кривыми руками в логи, иначе оперативку сожрёт медведь, внезапно появившийся из воздуха, временного континуума, портала Рика, «Sevice Manager-ов».