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‑ов».

В итоге

Если у Вас есть соблазн дёргать недокументированную или плохо документированную фичу, будьте готовы к последствиям. Будете копать глубоко, обязательно что-нибудь сломаете. Однако, если не копать глубоко, то и мало чему научишься. Поэтому путём боли и ошибок записывайте и сохраняйте кейсы. И делайте это с умом и организованно.

Пост скриптум

P. S. Вообще, общая схема чтения лога такова, что всегда нужен подзапрос, в котором извлекается запись «начало транзакции» (LOP_BEGIN_XACT), а далее внешний подзапрос работает по [Transaction ID] с конкретной операцией.

P. P. S. Чаще пишут, что «Agent XPs» отвалился или ещё что‑нибудь, поэтому сервер упал на очередном select из log‑а. Стоит пояснить, что хотя это строка лежит раньше, чем строка о том, что сервер останавливается, само сообщение об «Agent XPs» — это уже сам факт того, что сервер выключается. т. е. сервер уже упал пост‑фактум, и само сообщение является информационным. Чтобы найти точку падения, самое очевидное — это найти первое нормальное сообщение, среди таких информационных.