Управление размером файла журнала транзакций

Ошибки внутри ОбработкаОтображенияОшибки() ^

Вот у нас в обработке произошла ошибка. 1С передала управление в метод ОбработкаОтображенияОшибки().

Но что будет, если в этом методе тоже произойдёт ошибка? Как себя поведёт платформа?

Вызовем ошибку внутри процедуры по обработке ошибки (интересно звучит). Для этого попытаемся присвоить «Неопределено» в зарезервированную переменную

Выполняем обработку и видим стандартный текст с инфомацией об ошибке:

Перейдём в формирование отчета:

И посмотрим подробный текст ошибки:

Как видим, это текст ошибки, которая возникла в обработке. Здесь не содержится информация об ошибке, которую мы совершили после.

А что в журнале регистрации?

Опять же только одна ошибка. Та, которая является первопричиной. И нет никаких данных о том, что у нас была ещё и другая.

Дело в том, что когда в процедуре ОбработкаОтображенияОшибки() происходит ошибка, то 1С дальше работает по стандартной логике. Независимо от того, успели ли вы отключить СтандартнуюОбработку.

И в журнале регистрации вторая ошибка (в самом обработчике) фиксироваться не будет.

А что если мы успели сами уже отобразить показать информацию пользователю? Для этого внесём изменения в код:

Вызываем ошибку:

В этом тексте есть в конце слово «ТЕСТ». А значит, это то окно, которое мы сами программно вызвали.

Но когда мы закроем это окно, 1с откроет новое:

Это окно уже без надписи «ТЕСТ».

Дело в том, что 1С сначала выполнила открытие окна с ошибкой, которое мы выполнили сами, а затем, после того как процедуру ОбработкаОтображенияОшибки() не удалось выполнить, открыла ещё и стандартное окно.

Этот нюанс важно помнить при разработке. И быть очень осторожным, чтобы не допустить в методе ошибку

Иначе вы как разработчик можете даже не заметить её (ведь в журнале не фиксируется), а пользователя может пытать ситуация, когда ему дважды предлагают отправить отчет.

2 thoughts on “ MS SQL очистка журнала транзакций ”

А что делать, если файл журнала уже переполнен и свободное место ушло аж в минус (0%)?

ОБЛАСТЬ ПРИМЕНЕНИЯ: SQL Server База данных SQL Azure Azure Synapse Analytics (хранилище данных SQL) Parallel Data Warehouse APPLIES TO: SQL Server Azure SQL Database Azure Synapse Analytics (SQL DW) Parallel Data Warehouse

В этой статье рассказывается о мониторинге размера журнала транзакций SQL Server SQL Server , сжатии журнала транзакций, добавлении или увеличении файла журнала транзакций, оптимизации скорости роста журнала транзакций tempdb, а также об управлении размером файла журнала транзакций. This topic covers how to monitor SQL Server SQL Server transaction log size, shrink the transaction log, add to or enlarge a transaction log file, optimize the tempdb transaction log growth rate, and control the growth of a transaction log file.

Работа последовательности резервных копий журнала

Последовательность резервных копий цепочки журналов транзакций не зависит от резервных копий данных. Например, предположим, что имеется следующая последовательность событий:

Time	Событие
8:00	Резервное копирование базы данных.
Полдень	Резервное копирование журнала транзакций.
16:00	Резервное копирование журнала транзакций.
18:00	Резервное копирование базы данных.
20:00	Резервное копирование журнала транзакций.

Резервная копия журналов транзакций, созданная в 20:00, содержит записи журнала транзакций с 16:00 до 20:00. В этом временном диапазоне, а именно в 18:00, была создана полная резервная копия базы данных. Последовательность резервных копий журнала транзакций продолжается непрерывно с момента создания начальной полной резервной копии базы данных в 8:00 и до создания последней резервной копии журналов транзакций в 20:00. Сведения о применении этих резервных копий журналов приводятся в примере в статье Применение резервных копий журналов транзакций (SQL Server).

Настройки резервного копирования для репликации транзакций

Репликация транзакций включает параметр sync with backup , который может быть установлен для базы данных распространителя и для базы данных публикации.

Рекомендуется устанавливать этот параметр в базе данных распространителя.

Установка этого параметра для базы данных распространителя гарантирует, что транзакции в журнале базы данных публикации не будут усечены до тех пор, пока не будет создана их резервная копия в базе данных распространителя. Базу данных распространителя можно восстановить до последней резервной копии, а все потерянные транзакции будут доставлены из базы данных публикации в базу данных распространителя. Репликация не затрагивается.

Установка этого параметра для базы данных распространителя не влияет на задержку репликации. Тем не менее этот параметр откладывает усечение журнала в базе данных публикации до того момента, пока не завершится резервное копирование соответствующих транзакций в базе данных распространителя. (Это может привести к увеличению размера журнала транзакций в базе данных публикации.)
Рекомендуется установить этот параметр для базы данных публикации, если приложение допускает дополнительную задержку.

Установка этого параметра для базы данных публикации гарантирует, что транзакции не будут доставлены в базу данных распространителя до тех пор, пока не будет создана их резервная копия в базе данных публикации. Последняя резервная копия базы данных публикации может быть затем восстановлена на издателе, при этом в базе данных распространителя не будет транзакций, которых нет в восстановленной базе данных публикации.

Задержка и пропускная способность изменяются, так как транзакции не могут быть доставлены в базу данных распространителя до тех пор, пока не будут созданы их резервные копии на издателе. Например, если резервная копия журнала транзакций создается каждые пять минут, потребуются дополнительные пять минут задержки между фиксацией транзакции на издателе и доставкой транзакции сначала в базу данных распространителя, а затем подписчику.

Примечание

Параметр sync with backup обеспечивает согласованность базы данных публикации и базы данных распространителя, но он не гарантирует отсутствия потерь данных. Например, если журнал транзакций потерян, транзакции, зафиксированные после последнего резервного копирования журнала транзакций, не будут доступны в базе данных публикации или базе данных распространителя. Точно так же ведет себя нереплицируемая база данных.

Установка параметра «sync with backup»

Программирование репликации на языке Transact-SQL: Enable Coordinated Backups for Transactional Replication (Включение скоординированной архивации для репликации транзакций)

Операции, поддерживаемые журналом транзакций

Журнал транзакций поддерживает следующие операции:

восстановление отдельных транзакций;
восстановление всех незавершенных транзакций при запуске SQL Server ;
накат восстановленной базы данных, файла, файловой группы или страницы до момента сбоя;
поддержка репликации транзакций;
Поддержка решений высокой уровня доступности и аварийного восстановления: Группы доступности AlwaysOn, зеркальное отображение базы данных и доставка журналов.

Восстановление отдельных транзакций

Если приложение выдает инструкцию или Компонент Database Engine обнаруживает ошибку, такую как потеря связи с клиентом, записи журнала используются для отката изменений, выполненных в результате незавершенной транзакции.

Восстановление всех незавершенных транзакций при запуске SQL Server

Если на сервере происходит сбой, базы данных могут остаться в состоянии, когда часть изменений не переписана из буферного кэша в файлы данных, но в них имеются изменения, совершенные незаконченными транзакциями. Когда экземпляр SQL Server будет запущен, он выполнит восстановление каждой базы данных. Каждое изменение, записанное в журнале, которое, возможно, не было записано в файлы данных, накатывается. Чтобы сохранить целостность базы данных, будет также произведен откат каждой незавершенной транзакции, найденной в журнале транзакций. Дополнительные сведения см. в статье .

Накат восстановленной базы данных, файла, файловой группы или страницы до момента сбоя

После потери оборудования или сбоя диска, затрагивающего файлы базы данных, можно восстановить базу данных на момент, предшествующий сбою. Сначала восстановите последнюю полную резервную копию и последнюю дифференциальную резервную копию базы данных, затем восстановите последующую серию резервных копий журнала транзакций до момента возникновения сбоя.

При восстановлении каждой резервной копии журнала, Компонент Database Engine повторно применяет все изменения, записанные в журнале, для наката всех транзакций. После восстановления последней резервной копии журнала Компонент Database Engine затем использует данные журнала для отката всех транзакций, которые не были завершены на момент сбоя. Дополнительные сведения см. в статье .

Поддержка репликации транзакций

Агент чтения журнала следит за журналами транзакций всех баз данных, которые настроены для репликации транзакций, и копирует отмеченные для репликации транзакции из журнала транзакций в базу данных распространителя. Дополнительные сведения о репликации транзакций см. в разделе Как работает репликация транзакций.

Поддержка решений высокого уровня доступности и аварийного восстановления

Решения резервного сервера, Группы доступности AlwaysOn, зеркальное отображение базы данных и доставка журналов в значительной степени опираются на журнал транзакций.

В сценарии «Группы доступности AlwaysOn» каждое изменение в базе данных (первичной реплике) немедленно воспроизводится в ее полных автономных копиях (вторичных репликах). Первичная реплика немедленно отсылает каждую запись журнала во вторичные реплики, которые применяют входящие записи к базам данных групп доступности, производя непрерывный накат. Дополнительные сведения см. в разделе Экземпляры отказоустойчивого кластера AlwaysOn.

В сценарии доставки журналов основной сервер отправляет активный журнал транзакций основной базы данных в определенное назначение или множество назначений. Каждый сервер-получатель восстанавливает журнал в свою локальную базу данных-получатель. Дополнительные сведения см. в разделе Сведения о доставке журналов.

В сценарии зеркального отражения базы данных каждое изменение в базе данных (основной базе данных) немедленно воспроизводится в ее полной автономной копии (зеркальной базе данных). Экземпляр основного сервера немедленно отсылает каждую запись журнала в экземпляр зеркального сервера, который применяет входящие записи к зеркальной базе данных, путем ее непрерывного наката. Дополнительные сведения см. в разделе Зеркальное отображение базы данных.

Управление устойчивостью транзакций

Управление на уровне базы данных

Администратор базы данных управляет тем, могут ли пользователи использовать отложенные устойчивые транзакции в базе данных, с помощью следующей инструкции. Необходимо использовать для настройки параметра отложенной устойчивости инструкцию ALTER DATABASE.

ВЫКЛЮЧЕНО
При использовании этой настройки все фиксируемые в базе данных транзакции являются полностью устойчивыми независимо от настроек уровня фиксации (DELAYED_DURABILITY= ). Изменение и повторная компиляция хранимых процедур не требуются. Это позволяет гарантировать, что данные не будут подвергаться рискам из-за отложенной устойчивости.

РАЗРЕШЕНО
При использовании этой настройки устойчивость каждой транзакции определяется на уровне транзакций — DELAYED_DURABILITY = { OFF | ON }. Дополнительные сведения см. в разделах и .

ПРИНУДИТЕЛЬНО
Если выбран этот параметр, все транзакции, которые фиксируются в базе данных, являются отложенными устойчивыми. Независимо от того, указана ли транзакция как полностью устойчивая (DELAYED_DURABILITY = OFF) или данные не указаны, транзакция является отложенной устойчивой. Этот параметр полезен, если отложенная устойчивая транзакция используется для баз данных и не следует изменять код приложения.

Управление на уровне блока Atomic — скомпилированные в собственном коде хранимые процедуры

Ниже представлен код блока ATOMIC.

OFF
Транзакция является полностью устойчивой, пока действует параметр базы данных DELAYED_DURABLITY = FORCED, в этом случае фиксация является асинхронной и таким образом, устойчивой. Подробнее см. в разделе .

ON
Транзакция является устойчиво отложенной, пока действует параметр базы данных DELAYED_DURABLITY = DISABLED, в этом случае фиксация является синхронной и таким образом, полностью устойчивой. Подробнее см. в разделе .

Пример кода

Таблица 1: Устойчивость в блоках ATOMIC

Параметр устойчивости блоков ATOMIC	Отсутствие существующих транзакций	Транзакция обрабатывается (полностью или отложенная устойчивая)
DELAYED_DURABILITY = OFF	Блок ATOMIC инициирует новую полностью устойчивую транзакцию.	Блок ATOMIC создает точку сохранения в существующей транзакции, а затем начинает новую транзакцию.
DELAYED_DURABILITY = ON	Блок ATOMIC инициирует новую отложенную устойчивую транзакцию.	Блок ATOMIC создает точку сохранения в существующей транзакции, а затем начинает новую транзакцию.

Управление на уровне ФИКСАЦИИ — Transact-SQL

Синтаксис фиксации расширен, что обеспечивает возможность принудительной реализации отложенной устойчивости транзакций. Если для DELAYED_DURABILITY задано DISABLED или FORCED на уровне базы данных (см. выше), то этот параметр фиксации не учитывается.

OFF
Фиксация транзакции является полностью устойчивой за исключением случаев, когда применяется параметр базы данных DELAYED_DURABLITY = FORCED, в этом случае фиксация является асинхронной и, следовательно, отложенной устойчивой. Подробнее см. в разделе .

ON
Фиксация транзакции является отложенной устойчивой за исключением случаев, когда применяется параметр базы данных DELAYED_DURABLITY = DISABLED, в этом случае фиксация является синхронной и, следовательно, полностью устойчивой. Подробнее см. в разделе .

Краткое описание параметров и их взаимодействий

В следующей таблице перечислены взаимодействия параметров отложенной устойчивости на уровне базы данных и параметров на уровне фиксации. Параметры уровня базы данных всегда имеют более высокий приоритет, чем параметры уровня фиксации.

Параметр фиксации/параметр базы данных	DELAYED_DURABILITY = DISABLED	DELAYED_DURABILITY = ALLOWED	DELAYED_DURABILITY = FORCED
DELAYED_DURABILITY = OFF Транзакции на уровне базы данных.	Транзакция является полностью устойчивой.	Транзакция является полностью устойчивой.	Транзакция является отложенной устойчивой.
DELAYED_DURABILITY = ON Транзакции на уровне базы данных.	Транзакция является полностью устойчивой.	Транзакция является отложенной устойчивой.	Транзакция является отложенной устойчивой.
DELAYED_DURABILITY = OFF Межбазовая или распределенная транзакция.	Транзакция является полностью устойчивой.	Транзакция является полностью устойчивой.	Транзакция является полностью устойчивой.
DELAYED_DURABILITY = ON Межбазовая или распределенная транзакция.	Транзакция является полностью устойчивой.	Транзакция является полностью устойчивой.	Транзакция является полностью устойчивой.

Use ApexSQL Log

ApexSQL Log – это инструмент, который позволяет работать с журналом транзакций SQL Server в наглядном виде. Он позволяет просматривать текущий журнал транзакций в режиме реального времени, обращаться к резервным копиям журнала транзакций, как обычным, так и созданных в режиме компрессии. При этом приложение самостоятельно считывает данные из резервных копий БД, чтобы получить всю необходимую информацию для успешного восстановления. С помощью ApexSQL Log вы можете просматривать цепочки транзакций, которые произошли в вашей БД, даже те, которые были совершены до установки утилиты. В отличии от недокументированных и неподдерживаемых функций, рассмотренных выше, вы получите наглядную информацию о том, какие операции происходили над объектами, сможете увидеть старое и новое значение.

Запустите ApexSQL Log
Подключитесь к базе данных, чей журнал транзакций вы хотите проанализировать
На шаге Select SQL logs to analyze, выберите записи, которые нужно прочитать. Убедитесь, что они образуют полную цепочку
Чтобы добавить резервные копии журнала транзакций и отдельные файлы LDF, используйте кнопку Add
Используйте фильтр на шаге Filter setup, чтобы уменьшить количество считываемых транзакций с помощью указания временного диапазона, типа операций, таблицы и другие фильтры
Нажмите Open

Полный результат можно будет увидеть в табличном виде

Вы сможете отследить, когда операция началась и когда закончилась, тип операции, схему и объект, над которым произошла операция, имя пользователя, совершившего эту операцию, а также имя компьютера и приложения из которого эта операция была совершена. Для операций обновления (UPDATE) вы сможете увидеть, как новое, так и старое значение.

Чтобы избежать нечитаемых шестнадцатеричных значений, недокументированных функций, непонятного содержимого колонок, запросов со сложной конструкцией, сложных сценариев получения данных, неполных данных операций UPDATE, а также проблем с получением BLOB значений из журнала транзакций SQL Server, используйте программу ApexSQL Log. Она за вас выполнит все сложные операции и предоставит результат в читабельном виде. Кроме того, она позволит вам с помощью одного нажатия отменить или повторно выполнить нужную транзакцию.

Git + 1С. Часть 1. Как подключиться к команде разработки и начать использовать Git

Первая статья из цикла инструкций по работе с Git в 1С-разработке. Рассмотрим, как настроить рабочее место, как получить свою «копию» проекта для разработки и приступить к полезным действиям. Все примеры будут изложены в рамках трёх практических кейсов: 1. Моя команда дорабатывает типовую конфигурацию, использует приватный репозиторий на BitBucket, в котором версионируются внешние отчеты/обработки, расширения конфигураций и правила обмена; 2. Я участвую в стартап-команде, которая разрабатывает свою конфигурацию с использованием Git и GitLab; 3. Я принимаю участие в развитии OpenSource-продукта на GitHub как заинтересованный разработчик (контрибьютор).

Журнал транзакций с упреждающей записью

В этом разделе описана роль, которую журнал транзакций с упреждающей записью играет в записи изменений данных на диск. SQL Server использует алгоритм с упреждающей записью журнала (WAL), который гарантирует, что сначала на диск будет записана соответствующая запись журнала, и только после этого изменения данных будут записаны на диск. Таким образом обеспечиваются свойства ACID для транзакции.

Для понимания принципов работы упреждающего ведения журнала важно знать, как измененные данные записываются на диск. SQL Server Имеет буферный кэш, в который считываются страницы данных, когда требуется получить данные

Если какая-либо из страниц в буферном кэше изменилась, она не записывается сразу на диск, а помечается грязной. До момента ее физической записи на диск к странице могла быть применена одна или несколько операций логической записи. При каждой логической операции записи в кэш журнала, который записывает изменения, добавляется запись журнала транзакций. Записи журнала должны быть перенесены на диск до того, как соответствующая «грязная» страница будет удалена из буферного кэша и записана на диск. Заключается в том, что процесс контрольных точек производит периодический просмотр буферного кэша на наличие буферов со страницами определенной базы данных и запись всех «грязных» страниц на диск. Контрольные точки экономят время во время последующего восстановления при помощи создания точки, в которой все «грязные» страницы гарантированно записываются на диск.

Запись измененной страницы данных из буферного кэша на диск называется сбросом страницы на диск. SQL Server Имеет логику, которая предотвращает запись на диск «грязной» страницы до записи на него связанной записи журнала. Содержимое журнала записывается на диск при сбросе буферов журнала. Это происходит при фиксации транзакции или заполнении буферов журнала.

Имена недействительных файлов

Папки или файлы, содержащие недействительные или зарезервированные имена файлов, также могут быть исключены из статистики файлов и папок. В NTFS допустимы папки или файлы, содержащие ведущие или точки заднего пользования, но они не допустимы с точки зрения подсистемы Win32. Поэтому ни Windows, ни командная подсказка не могут надежно работать с ними.

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

ИЛИ

Если у вас есть папки или файлы, которые нельзя удалить или переименовать, обратитесь в службы поддержки продуктов Майкрософт.

Функция fn_dump_dblog

fn_dump_dblog – это ещё одна недокументированная функция, которая позволяет просматривать журнал транзакций из резервной копии журнала транзакций, как сжатого, так и обычного.

Ниже пример запуска функции fn_dump_dblog, обратите внимание, что необходимо указать все её 63 параметра

SELECT *
FROM fn_dump_dblog
(NULL,NULL,N'DISK',1,N'E:\ApexSQL\backups\AdventureWorks2012_05222013.trn', 
DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, 
DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,
DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,
DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,
DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,
DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,
DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, 
DEFAULT);

Т.к. функция fn_dump_dblog возвращает так же, как и fn_dblog 129 столбцов, то желательно сократить этот набор полей

SELECT , 
       Operation, 
       Context, 
       , 
     ,
       Description
FROM fn_dump_dblog
(NULL,NULL,N'DISK',1,N'E:\ApexSQL\backups\AdventureWorks2012_05222013.trn', 
DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, 
DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,
DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,
DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,
DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,
DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,
DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT,DEFAULT, 
DEFAULT);

Но вам потребуется опять расшифровать шестнадцатеричные значения, чтобы найти искомые записи

И вы опять получаете те же самые ограничения, что и при работе с функцией fn_dblog.

Для восстановления БД из копии журнала транзакций до определённого момента времени или до конкретной транзакции, вам необходимо:

Определить LSN (Log Sequence Number) для этой транзакции
Преобразовать LSN в формат, который используется в конструкции WITH STOPBEFOREMARK = ‘<mark_name>’, например значение 00000070:00000011:0001 должно быть переведено в формат 112000000001700001
Восстановите полную резервную копию БД и всю цепочку резервных копий журнала транзакций до нужной транзакции с помощью конструкции WITH STOPBEFOREMARK = ‘<mark_name>’ , где укажите идентификатор нужной транзакции.

RESTORE LOG AdventureWorks2012
FROM
    DISK = N'E:\ApexSQL\backups\AW2012_05232013.trn'
WITH
    STOPBEFOREMARK = 'lsn:112000000001700001',
    NORECOVERY;

Требования к восстановлению резервных копий журналов транзакций

Для применения резервной копии журнала транзакций необходимо выполнить следующие требования.

Достаточное количество резервных копий журналов для последовательности восстановления: Чтобы провести полную последовательность восстановления, в резервных копиях журнала должно быть достаточно записей. Необходимые резервные копии журнала, включая при необходимости резервные копии конца журнала , должны быть доступны перед запуском последовательности восстановления.
Правильный порядок восстановления: Сначала необходимо восстановить предыдущую полную или разностную резервную копию базы данных. После этого в хронологическом порядке необходимо восстановить все журналы транзакций, созданные после указанной полной или разностной резервной копии. Если резервная копия журнала транзакций в этой цепочке журналов утрачена или повреждена, то восстановить можно только журналы транзакций до отсутствующего журнала.
База данных еще не восстановлена: Базу данных нельзя восстановить до тех пор, пока не будет применен последний журнал транзакций. Если база данных восстанавливается после восстановления одной из промежуточных резервных копий журнала транзакций, расположенной перед концом цепочки журналов, базу данных после этой точки можно восстановить без перезапуска всей последовательности восстановления, начинающейся с полной резервной копии базы данных.

Совет

Рекомендуется восстановить все резервные копии журналов (). Затем, после восстановления последней резервной копии журнала, восстановите базу данных в отдельной операции ().

Функция fn_dbblog

fn_dblog – это недокументированная функция SQL Server, которая позволяет просматривать активную часть журнала транзакций в режиме реального времени.

Давайте посмотрим, как с ней работать:

Выполните функцию fn_dblog

Select * FROM sys.fn_dblog(NULL,NULL)

Функция возвращает 129 столбцов, поэтому желательно сузить результирующий набор по необходимым наборам полей и по возможности ограничить выборку только нужным типом транзакций

Из всего набора данных, который возвращает функция fn_dblog выведем только нужные транзакции.

Например, выберем только транзакции на вставку строк в таблицу:

SELECT , 
       Operation, 
       Context, 
       , 
       
       FROM sys.fn_dblog
   (NULL, NULL)
  WHERE operation IN
   ('LOP_INSERT_ROWS');

Чтобы увидеть транзакции на удаление строк, выполните следующий скрипт:

SELECT , 
       , 
       , 
       Operation
  FROM sys.fn_dblog
   (NULL, NULL)
  WHERE operation IN
   ('LOP_DELETE_ROWS');

Информация по вставленным или удалённым строкам храниться в столбцах – RowLog Contents 0, RowLog Contents 1, RowLog Contents 2, RowLog Contents 3, RowLog Contents 4, Description и Log Record

Для каждого типа транзакций используются разные столбцы, для того, чтобы получить нужную вам информацию вы должны точно знать какие столбцы используются для каких транзакций, а сделать это не просто, так, как официальной документации с описанием нет.

Вставленные и удаленные строки хранятся в шестнадцатеричных значениях. Для того, чтобы вытащить данные из этих значений вы должны знать формат хранения, понимать биты состояний, знать общее количество столбцов и так далее.

Далее необходимо преобразовать двоичные данные в табличный вид с учётом типа данных столбцов таблицы. Следует отметить, что механизм преобразования различный для разных типов данных.

fn_dbLog замечательный бесплатный инструмент для чтения журнала транзакций, но эта функция имеет ряд ограничений – разобраться в данных достаточно сложно, т.к. среди прочей информации содержатся записи, связанные с системными таблицами, функция отображает только активную часть журнала и не отображает информацию по обновлению BLOB-значений.

Операция UPDATE при минимальном протоколировании журнала транзакций не содержит полное значение, которое было до и после изменений, а хранит только то, что изменилось (SQL Server может записать, что изменилось значение “G” на “D”, хотя в действительности изменилось слово “GLOAT” на “FLOAT”). В этом случаи вам потребуется вручную восстанавливать все промежуточные состояния записи на странице от первой её вставки до момента, который вас интересует.

При удалении BLOB-объектов сами объекты не записываются в журнал, а лишь фиксируется факт удаления. Для восстановления, удалённого BLOB-объекта вам необходимо найти в журнале пару для этого удаления, которой является ранее осуществлённая вставка, а она скорее всего уже не содержится в активной части журнала.

Ректальное администрирование: Основы для практикующих системных АДминистраторов

Одной из самых популярных и зарекомендовавших себя методологий системного администрирования является так называемое ректальное. Редкий случай сопровождения и обслуживания информационных систем, инфраструктуры организации обходится без его использования. Зачастую без знания данной методологии сисадминам даже бывает сложно найти работу в сфере ИТ, потому что работодатели, особенно всякие аутсорсинговые ИТ фирмы, в основном отдают предпочтение классическим, зарекомендовавшим себя методикам, а не новомодным заграничным веяниям: практикам ITIL, нормальным ITSM и прочей ерунде.