Журнал операций: Приказ Минфина России от 30.03.2015 N 52н (ред. от 15.06.2020) «Об утверждении форм первичных учетных документов и регистров бухгалтерского учета, применяемых органами государственной власти (государственными органами), органами местного самоуправления, органами управления государственными внебюджетными фондами, государственными (муниципальными) учреждениями, и Методических указаний по их применению» (Зарегистрировано в Минюсте России 02.06.2015 N 37519)

Содержание

Электронный учебник 1С:Бухгалтерия 7.7 — Урок 6, вопр.2: Журнал операций.

Урок 6 — продолжение

Понятие и виды операций.

Журнал операций.

Журнал проводок.

Ввод начального сальдо.

2. Журнал операций

Открыть журнал операций: Журналы ® Журнал операций или кнопкой (Журнал операций).

Журнал операций предназначен для просмотра списка операций. Каждая операция в нем представлена в виде отдельной строки. См. рис.8.

Рис. 8. Журнал операций.
В табличной части журнала операций имеются графы:

Дата	Дата операции
Время	Время операции (документа)
Документ	Вид документа (или указано )
Номер	Номер операции или номер документа, которому принадлежит операция
Содержание	Содержание операции
Сумма	Сумма операции

Интервал журнала операций устанавливается так же как и в журнале документов: Действия ® Интервал (или с помощью кнопки Интервал в панели инструментов).

Существует возможность разделения журнала операций на 2 подокна: для списка операций и для списка проводок текущей операции: Действия ® Показывать проводки.

Работа с операциями и документами:

Ввести новую операцию:
нажмите кнопку (Новая строка (Ins)). откроется окно диалога операции, заполните заголовок операции: дата, номер, сумма, содержание; далее введите проводки кнопкой (Новая проводка (Ins)) или корреспонденции кнопкой (Новая корреспонденция).
Примечание: номера операций и проводок внутри операции уникальны.

Ввести используя типовую операцию:
нажмите кнопку , выбирите типовую операцию, заполните реквизиты заголовка операции, а затем все недостающие реквизиты проводок или корреспонденций. При вводе типовой операции суммы проводок рассчитываются автоматически.
Для примера предлагается ввести типовую операцию Капитальные вложения в основные средства и нематериальные активы ® 1. Поступление оборудования от поставщика.

Ввести документ:
нажмите кнопку , выберите документ, заполните все его реквизиты, как и в журнале документов. Хотя такая возможность существует, все-таки удобнее вводить документы непосредственно в журналы документов.

Редактировать операцию или реквизиты документа:
выполните двойной щелчок по строке в журнале или нажмите Enter, откроется окно диалога операции. Можно также использовать кнопки (Открыть операцию), (Открыть документ).

Копировать операцию:
осуществляется аналогично копированию документов кнопкой (Копировать строку).

Сайт создан в системе uCoz

Журнал операций | LiveAgent

Что такое Журнал операций?

Журнал операций – это отчет обо всех действиях, предпринятых за определенный период времени. Журнал операций, также известный как протокол работы, показывает, как сотрудник проводит свое рабочее время. В LiveAgent журнал активности показывает все созданные или отредактированные заявки.

Это дает администратору/супервайзеру возможность проверить работу каждого агента. Это также позволяет им предложить улучшения для повышения эффективности работы в LiveAgent.

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

Почему журналы операций важны?

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

Журналы операций также показывают, что у Вас есть превентивные меры на случай возникновения злоупотреблений. Это важно, если в Ваш бизнес инвестируют деловые партнеры или заинтересованные стороны.

Журналы аудита также важны, потому что они предоставляют исчерпывающую информацию.

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

Зачем Вам нужно проверять Журнал операций?

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

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

Таким образом, просматривая журналы аудита, Вы можете найти возможности для улучшения качества обслуживания клиентов.

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

Преимущества Журнала операций/Журнала аудита:

немедленное выявление проблем, что позволяет избежать месяцев возможных ошибок
определение навыков агентов службы поддержки – хорошие/плохие исполнители
помощь в измерении ключевых показателей эффективности (KPI) сотрудников
возможность вознаграждать наиболее эффективных агентов службы поддержки
возможность увидеть необходимость дополнительного обучения агентов

Где находится Журнал операций в LiveAgent?

Шаги для перехода к Журналу операций:

Войдите в свою учетную запись LiveAgent
Найдите Конфигурации
Нажмите на Инструменты
Наконец, откройте Журнал аудита

Как уже упоминалось ранее, Журнал операций по-другому называется Журналом аудита.

Что показывает ваш Журнал операций в LiveAgent?

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

Он показывает:

имя агента
количество времени, которое агент тратит на работу с заявкой
количество заявок, над которыми работал агент
краткое описание каждого действия
точные действия агента/изменения в каждой заявке

Назад к глоссарию Зарегистрироваться БЕСПЛАТНО

Журнал операций со сточными водами

Артикул: 00004147

в желания В наличии

Место издания: Москва

Год: 2022

Формат: А4 (210×290 мм)

Переплет: Мягкая обложка

Страниц: 100

Вес: 150 г

С этим товаром покупают

Читать онлайн / Скачать/полистать/читать on-line
Читать on-line книгу «Журнал операций со сточными водами» на полный экран
Форма судового журнала операций со сточными водами соответствует Приложению 5 к Приказу Минтранса РФ от 10. 05.2011 N 133 «Об утверждении правил ведения журналов судовых (Зарегистрировано в Минюсте РФ 28.06.2011 N 21199), а также Приложению Д к РД 31.04.17-97 Правила регистрации операций с нефтью, нефтепродуктами и другими веществами.
Инструкция по заполнению:
1. Записи в журнал производятся лицами командного состава, ответственными за проведение операций
2. Капитан судна контролирует записи в журнале и удостоверяет их подписью в конце каждой страницы
3. Записи заносятся в журнал сразу после окончания операции.
4. Записи в журнале производятся темными чернилами (пастой)
5. Каждая запись в журнале подписывается лицом, ответственным за проведение операции, с указанием фамилии, инициалов и должности
6. В случае внесения в журнал ошибочной записи исправления выполняются следующим образом
Текст, подлежащий изменению, зачеркивается тонкой чертой, чтобы его можно было прочесть, и заключается в скобки. Если ошибка замечена во время совершения записи, правильный текст пишется сразу же после скобки. В остальных случаях за скобкой или, в случае пропуска, за словом, после которого нужно добавить текст, ставится цифровой знак сноски со сквозной нумерацией для каждой страницы. При исправлении и/или дополнении используются фразы «записано ошибочно», если зачеркнутый текст не нужно заменять другим, «читать» и далее верный текст, «дополнение» и далее верный текст.
Исправление и/или дополнение текста записывается непосредственно после последней имеющейся в журнале в период текущих суток записи, предваряется цифровым знаком сноски и скрепляется подписью лица, внесшего исправление или дополнение.
Если исправления или дополнения относятся к предшествующим страницам, то перед ними после номера сноски указывается номер страницы журнала.
Журнал контроля и учета операций, связанных с обращением лекарственных средств (Приложение №1, 60 страниц)
{{#each tradingPlatforms}} {{/each}} {{/if}}
Запросите оферту через форму обратной связи
{{#if tradingPlatforms. length}} {{/if}}
Наличие в магазинах «Комус» товара с артикулом N {{productId}}
{{region}}, состояние на {{currentTime}}
{{> pageNumberTemplate pages}} {{#if availableStocks.length}} {{#if subwayNeed }} {{/if}} {{#each availableStocks}} {{/each}} {{/if}} {{> pageNumberTemplate pages}}
В розничных магазинах «Комус» цена на данный товар может отличаться от цены Интернет-магазина.
Подробную информацию о цене и количестве товара вы можете получить,
позвонив по телефону ближайшего к Вам магазина «Комус».
Адреса всех магазинов Комус
Закрыть
Закрыть
{{/if}} {{#each products}} {{#each this}} {{/each}} {{/each}} {{#each products}} {{/each}} {{#each products}} {{/each}}
Сравнение товаров
{{> breadcrumbTemplate breadcrumbs=breadcrumbs }} {{#if (gt products.length 0)}}
Закрыть
{{else}}
Нечего сравнивать
{{/if}} {{#if (gt products.length 1)}} {{/if}} {{#each products}} {{#each fields}} {{#each this}} {{/each}} {{/each}} {{#each products}} {{/each}} {{#each products}} {{/each}}
Согласно приказа МИНИСТЕРСТВА ЗДРАВООХРАНЕНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ от 17 июня 2013 года N 378н об утверждении правил регистрации операций, связанных с обращением лекарственных средств для медицинского применения, включенных в перечень лекарственных средств для медицинского применения, подлежащих предметно-количественному учету, в специальных журналах учета операций, связанных с обращением лекарственных средств для медицинского применения, и правил ведения и хранения специальных журналов учета операций, связанных с обращением лекарственных средств для медицинского применения.
{{#if (eqw this. forbidden true)}} {{> productAddToCartForbiddenTemplate}} {{else}} {{#if (and (neqw this.stock null) (neqw (uppercase this.stock.stockLevelStatus.code) «OUTOFSTOCK») (neqw this.price null))}} {{else}} Товар недоступен {{/if}} {{/if}}
Арт. {{this.code}} {{#if this.stock}} {{#if (neqw this.stock.stockStatusText null)}} {{{ this.stock.stockStatusText }}} {{else}} {{#if (eqw (uppercase this.stock.stockLevelStatus.code) «ONREQUEST»)}} Под заказ {{else}} {{#if (neqw (uppercase this.stock.stockLevelStatus.code) «OUTOFSTOCK»)}} В наличии {{else}} Нет в наличии {{/if}} {{/if}} {{/if}} {{/if}}
{{/each}} {{#each fields}}
{{@key}} {{this}}
Торговая марка {{#if (neqw this. trademark null)}} {{this.trademark.name}} {{/if}}
Рейтинг {{#if (eqw this.ratingWidth null)}}
{{this.averageRating}}{{#if (eqw this.averageRating null)}}0{{/if}}
{{#unless eaistPopup}} Отсутствующий товар: {{/unless}} Выберите товары для замены:
{{#if (gt @index 0)}} {{/if}} {{#if (eqw this. forbidden true)}} {{> productAddToCartForbiddenTemplate}} {{else}} {{#if (and (neqw this.stock null) (neqw (uppercase this.stock.stockLevelStatus.code) «OUTOFSTOCK») (neqw this.price null))}} {{else}} Товар недоступен {{/if}} {{/if}}
Арт. {{this.code}} {{#if this.stock}} {{#if (neqw this.stock.stockStatusText null)}} {{{ this.stock.stockStatusText }}} {{else}} {{#if (eqw (uppercase this.stock.stockLevelStatus.code) «ONREQUEST»)}} Под заказ {{else}} {{#if (neqw (uppercase this.stock.stockLevelStatus.code) «OUTOFSTOCK»)}} В наличии {{else}} Нет в наличии {{/if}} {{/if}} {{/if}} {{/if}}
{{/each}}
{{@key}} {{this}}
Торговая марка {{#if (neqw this. trademark null)}} {{this.trademark.name}} {{/if}}
Рейтинг {{#if (eqw this.ratingWidth null)}}
{{this.averageRating}}{{#if (eqw this.averageRating null)}}0{{/if}}
Подробные характеристики
Сфера применения: в медицинских учреждениях
Отзывы могут оставлять только авторизованные пользователи.
{{#if (neqw this.shopAnswer null)}}
Магазин «Комус»,
{{this.shopAnswer}}
{{/if}}
Журнал операций
Журнал операций – это отчет, который содержит список всех проводок. Отчет вызывается из пункта «Бухгалтерские операции» главного меню задачи «Бухгалтерия».
Рис. 16-23 — Экранная форма отчета «Журнал операций»
Параметры отчета задаются в диалоговом окне параметров выборки.
Рис. 16-24 — Параметры отчета «Журнал операций»
• «С… по …» – период формирования отчета.
• «Выбирать» – возможные значения:
1. Операции – будут отобраны все проводки, сформированные за указанный период.
2. Остатки – будут отобраны только остатки, сформированные документами «Фиксация остатков на счетах» за указанный период.
• «Счет дебета«, «Счет кредита» – используется для отбора проводок по указанным счетам. При этом порядок отбора зависит от состояния переключателя «и/или«, расположенного в центре диалога (он выделен на рисунке).
1. и – будут отобраны все проводки, у которых в дебете – счет, указанный в поле «Счет дебета«, а в кредите – счет, указанный в поле «Счет кредита«. Если хотя бы одно из этих условий не выполнено, проводка в выборку не попадет. Например, если в поле «Счет дебета» – 50 счет, в поле «Счет кредита» – 51 счет, то будут выбраны все проводки Д 50 К 51.
2. или – будут отобраны все проводки, у которых или в дебете – счет, указанный в поле «Счет дебета«, или в кредите – счет, указанный в поле «Счет кредита«. Чтобы проводка попала в выборку достаточно выполнения одного из условий. Например, если в поле «Счет дебета» – 50 счет, в поле «Счет кредита» – 51 счет, то будут выбраны все проводки вида Д 50 К *, Д * К 51, где * – это любой счет.
• «Аналитики дебет«, «Аналитики кредит» – иногда требуется просмотреть отобрать проводки по определенным аналитикам, например, все проводки по заданному контрагенту и договору. Если указать аналитики дебета (кредита), то в отчет попадут только те проводки, у которых в аналитиках дебета (кредита) стоят указанные значения. Если в качестве счета выбран счет, имеющий субсчета, то важно правильно установить значение флага «Включать субсчета«. При установленном флаге будет построен отчет по всему счету, включая его субсчета. При снятом флаге отчет будет построен только по проводкам выбранного счета.
• Флаги «По группе(1)«, «По группе(2)«, «По группе(3)«, «По группе(4)» – определяют, как должны быть отобраны проводки, если в качестве первой, второй, третьей или четвертой аналитики соответственно указана папка. Если флаг установлен, то в выборку попадут все проводки, где в соответствующей аналитике стоит один из элементов указанной папки. Если флаг снят, то в выборку попадут только проводки, где в соответствующей аналитике указана сама папка.
Как правило, папка в качестве значения аналитики в проводках не указывается. Поэтому по умолчанию эти флаги установлены.
Флаг «Искать во всех аналитиках» – при установке этого флага становятся недоступными для редактирования поля со второй, третьей и четвертой аналитиками, а значение аналитики задается в поле первой аналитики. Данный флаг позволяет отобрать все проводки с данной аналитикой независимо от того, является ли она в этих проводках первой аналитикой, второй, третьей или четвертой.
Журнал транзакций (SQL Server) — SQL Server
08.10.2020
11 минут на чтение
Эта страница полезна?
Оцените свой опыт
да Нет
Любой дополнительный отзыв?
Отзыв будет отправлен в Microsoft: при нажатии кнопки «Отправить» ваш отзыв будет использован для улучшения продуктов и услуг Microsoft.Политика конфиденциальности.
Представлять на рассмотрение
В этой статье
Применимо к: SQL Server (все поддерживаемые версии)
Каждая база данных SQL Server имеет журнал транзакций, в котором записываются все транзакции и модификации базы данных, сделанные каждой транзакцией.
Журнал транзакций — важный компонент базы данных.В случае сбоя системы вам понадобится этот журнал, чтобы вернуть базу данных в согласованное состояние.
Для получения информации об архитектуре и внутреннем устройстве журнала транзакций см. Руководство по архитектуре и управлению журналом транзакций SQL Server.
Предупреждение
Никогда не удаляйте и не перемещайте этот журнал, если вы полностью не понимаете последствий этого.
Подсказка
Известные хорошие точки, с которых можно начать применение журналов транзакций во время восстановления базы данных, создаются контрольными точками.Дополнительные сведения см. В разделе Контрольные точки базы данных (SQL Server).
Операции, поддерживаемые журналом транзакций
Журнал транзакций поддерживает следующие операции:
Восстановление отдельной транзакции.
Восстановление всех незавершенных транзакций при запуске SQL Server.
Прокат восстановленной базы данных, файла, файловой группы или страницы до точки отказа.
Поддержка репликации транзакций.
Поддержка решений высокой доступности и аварийного восстановления: группы доступности AlwaysOn, зеркальное отображение базы данных и доставка журналов.
Восстановление отдельной транзакции
Если приложение выдает инструкцию ROLLBACK или компонент Database Engine обнаруживает ошибку, например потерю связи с клиентом, записи журнала используются для отката изменений, внесенных незавершенной транзакцией.
Восстановление всех незавершенных транзакций при запуске SQL Server
Если сервер выходит из строя, базы данных могут оставаться в состоянии, при котором некоторые модификации никогда не записывались из буферного кеша в файлы данных, и могут быть некоторые модификации из-за незавершенных транзакций в файлах данных.При запуске экземпляра SQL Server выполняется восстановление каждой базы данных. Для каждой модификации, записанной в журнале, которая, возможно, не была записана в файлы данных, выполняется повтор транзакций. Каждая незавершенная транзакция, обнаруженная в журнале транзакций, затем откатывается, чтобы убедиться, что целостность базы данных сохраняется. Дополнительные сведения см. В разделе Восстановление и восстановление: Обзор (SQL Server).
Прокрутка восстановленной базы данных, файла, файловой группы или страницы до точки отказа
После потери оборудования или отказа диска, повлиявшего на файлы базы данных, вы можете восстановить базу данных до точки отказа.Сначала вы восстанавливаете последнюю полную резервную копию базы данных и последнюю дифференциальную резервную копию базы данных, а затем восстанавливаете последующую последовательность резервных копий журнала транзакций до точки сбоя.
При восстановлении каждой резервной копии журнала компонент Database Engine повторно применяет все изменения, записанные в журнале, для наката всех транзакций. После восстановления последней резервной копии журнала компонент Database Engine затем использует информацию журнала для отката всех транзакций, которые не были завершены на тот момент. Дополнительные сведения см. В разделе Восстановление и восстановление: Обзор (SQL Server).
Поддержка репликации транзакций
Агент чтения журнала отслеживает журнал транзакций каждой базы данных, настроенной для репликации транзакций, и копирует транзакции, помеченные для репликации, из журнала транзакций в базу данных распространителя. Дополнительные сведения см. В разделе «Как работает репликация транзакций».
Поддержка решений высокой доступности и аварийного восстановления
Решения для резервного сервера, группы доступности AlwaysOn, зеркальное отображение базы данных и доставка журналов в значительной степени зависят от журнала транзакций.
В сценарии группы доступности AlwaysOn каждое обновление базы данных, первичной реплики, немедленно воспроизводится в отдельных полных копиях базы данных, вторичных репликах. Первичная реплика немедленно отправляет каждую запись журнала вторичным репликам, которые применяют входящие записи журнала к базам данных группы доступности, непрерывно повторяя транзакции. Дополнительные сведения см. В разделе Экземпляры отказоустойчивого кластера AlwaysOn
.
В сценарии доставки журналов первичный сервер отправляет активный журнал транзакций первичной базы данных одному или нескольким адресатам.Каждый вторичный сервер восстанавливает журнал в своей локальной вторичной базе данных. Для получения дополнительной информации см. О доставке журналов.
В сценарии зеркального отображения базы данных каждое обновление базы данных, основной базы данных, немедленно воспроизводится в отдельной полной копии базы данных, зеркальной базы данных. Экземпляр основного сервера немедленно отправляет каждую запись журнала экземпляру зеркального сервера, который применяет входящие записи журнала к зеркальной базе данных, непрерывно повторяя ее.Дополнительные сведения см. В разделе «Зеркальное отображение базы данных».
Характеристики журнала транзакций
Характеристики журнала транзакций ядра СУБД SQL Server:
Журнал транзакций реализован в виде отдельного файла или набора файлов в базе данных. Кэш журнала управляется отдельно от кеша буфера для страниц данных, что приводит к созданию простого, быстрого и надежного кода в ядре СУБД SQL Server. Для получения дополнительной информации см. Физическая архитектура журнала транзакций.
Формат записей и страниц журнала не ограничивается форматом страниц данных.
Журнал транзакций может быть реализован в нескольких файлах. Файлы можно настроить на автоматическое расширение, установив для журнала значение FILEGROWTH . Это снижает вероятность нехватки места в журнале транзакций и в то же время снижает административные издержки. Дополнительные сведения см. В разделе Параметры файла и файловой группы ALTER DATABASE (Transact-SQL).
Механизм повторного использования пространства в файлах журнала работает быстро и оказывает минимальное влияние на пропускную способность транзакций.
Для получения информации об архитектуре и внутреннем устройстве журнала транзакций см. Руководство по архитектуре и управлению журналом транзакций SQL Server.
Усечение журнала транзакций
Усечение журнала освобождает место в файле журнала для повторного использования журналом транзакций. Вы должны регулярно обрезать журнал транзакций, чтобы он не заполнял отведенное пространство.Несколько факторов могут задержать усечение журнала, поэтому мониторинг размера журнала имеет значение. Некоторые операции можно минимально протоколировать, чтобы уменьшить их влияние на размер журнала транзакций.
Усечение журнала удаляет неактивные файлы виртуального журнала (VLF) из журнала логических транзакций базы данных SQL Server, освобождая место в логическом журнале для повторного использования физическим журналом транзакций. Если журнал транзакций никогда не усекается, он в конечном итоге заполнит все дисковое пространство, выделенное для физических файлов журнала.
Чтобы избежать нехватки места, если усечение журнала не задерживается по какой-либо причине, усечение происходит автоматически после следующих событий:
По простой модели восстановления, после КПП.
В модели полного восстановления или модели восстановления с неполным протоколированием, если контрольная точка возникла с момента предыдущего резервного копирования, усечение происходит после резервного копирования журнала (если это не резервная копия журнала только для копирования).
Дополнительные сведения см. В разделе «Факторы, которые могут задерживать усечение журнала» далее в этом разделе.
Примечание
Усечение журнала не уменьшает размер физического файла журнала. Чтобы уменьшить физический размер физического файла журнала, необходимо сжать файл журнала. Для получения информации об уменьшении размера физического файла журнала см. Управление размером файла журнала транзакций.
Однако следует помнить о факторах, которые могут задерживать усечение журнала. Если после сжатия журнала снова потребуется пространство для хранения, журнал транзакций снова вырастет, что приведет к снижению производительности во время операций увеличения журнала.
Факторы, которые могут задержать усечение журнала
Когда записи журнала остаются активными в течение длительного времени, усечение журнала транзакций задерживается, и журнал транзакций может заполниться, как мы упоминали ранее в этом длинном разделе.
Действительно, усечение журнала может быть отложено по разным причинам.Узнайте, что мешает усечению журнала, запросив столбцы log_reuse_wait и log_reuse_wait_desc представления каталога sys.databases. В следующей таблице описаны значения этих столбцов.
значение log_reuse_wait значение log_reuse_wait_desc Описание
0 НИЧЕГО В настоящее время существует один или несколько повторно используемых файлов виртуального журнала (VLF).
1 КОНТРОЛЬНАЯ ТОЧКА С момента последнего усечения журнала контрольная точка не возникла, или заголовок журнала еще не переместился за пределы виртуального файла журнала (VLF). (Все модели восстановления)
Это обычная причина задержки усечения журнала. Дополнительные сведения см. В разделе Контрольные точки базы данных (SQL Server).
2 LOG_BACKUP Перед усечением журнала транзакций требуется резервная копия журнала. (Только для моделей восстановления с полным или неполным протоколированием)
По завершении следующего резервного копирования журнала часть пространства журнала может стать повторно используемым.
3 ACTIVE_BACKUP_OR_RESTORE Выполняется резервное копирование или восстановление данных (все модели восстановления).
Если резервное копирование данных предотвращает усечение журнала, отмена операции резервного копирования может помочь решить немедленную проблему.
4 АКТИВНОЕ ПЕРЕДАЧА Транзакция активна (все модели восстановления):
Длительная транзакция могла существовать в начале резервного копирования журнала. В этом случае для освобождения места может потребоваться еще одна резервная копия журнала.Обратите внимание, что длительные транзакции предотвращают усечение журнала во всех моделях восстановления, включая простую модель восстановления, при которой журнал транзакций обычно усекается на каждой автоматической контрольной точке.
Транзакция отложена. Отложенная транзакция фактически является активной транзакцией, откат которой заблокирован из-за недоступности ресурса. Для получения информации о причинах отложенных транзакций и о том, как вывести их из отложенного состояния, см. Отложенные транзакции (SQL Server).
Длительные транзакции также могут заполнить журнал транзакций tempdb. Tempdb неявно используется пользовательскими транзакциями для внутренних объектов, таких как рабочие таблицы для сортировки, рабочие файлы для хеширования, рабочие таблицы курсора и управление версиями строк. Даже если пользовательская транзакция включает в себя только чтение данных ( SELECT запросов), внутренние объекты могут быть созданы и использованы в пользовательских транзакциях. После этого можно заполнить журнал транзакций tempdb.
5 БАЗА ДАННЫХ_ЗЕРКАЛЬНОЕ ЗЕРКАЛО Зеркальное отображение базы данных приостановлено или в режиме высокой производительности зеркальная база данных значительно отстает от основной базы данных.(Только для модели полного восстановления)
Дополнительные сведения см. В разделе «Зеркальное отображение базы данных (SQL Server)».
6 РЕПЛИКАЦИЯ Во время репликации транзакций транзакции, относящиеся к публикациям, все еще не доставляются в базу данных распространителя. (Только для модели полного восстановления)
Для получения информации о репликации транзакций см. Репликация SQL Server.
7 DATABASE_SNAPSHOT_CREATION Создается моментальный снимок базы данных.(Все модели восстановления)
Это стандартная и обычно кратковременная причина отложенного усечения журнала.
8 LOG_SCAN Происходит сканирование журнала. (Все модели восстановления)
Это стандартная и обычно кратковременная причина отложенного усечения журнала.
9 AVAILABILITY_REPLICA Вторичная реплика группы доступности применяет записи журнала транзакций этой базы данных к соответствующей вторичной базе данных.(Модель полного восстановления)
Дополнительные сведения см. В разделе Обзор групп доступности AlwaysOn (SQL Server).
10 – Только для внутреннего использования
11 – Только для внутреннего использования
12 – Только для внутреннего использования
13 СТАРАЯ СТРАНИЦА Если база данных настроена на использование косвенных контрольных точек, самая старая страница в базе данных может быть старше, чем порядковый номер журнала контрольной точки (LSN).В этом случае самая старая страница может задерживать усечение журнала. (Все модели восстановления)
Для получения информации о косвенных контрольных точках см. Контрольные точки базы данных (SQL Server).
14 ДРУГОЙ_ПЕРЕВОД Это значение в настоящее время не используется.
16 XTP_CHECKPOINT Необходимо выполнить контрольную точку OLTP в памяти. Для таблиц, оптимизированных для памяти, автоматическая контрольная точка берется, когда файл журнала транзакций становится больше 1.5 ГБ с момента последней контрольной точки (включает как дисковые, так и оптимизированные для памяти таблицы)
Дополнительные сведения см. В разделах «Операция контрольной точки для таблиц, оптимизированных для памяти» и [Процесс ведения журнала и контрольной точки для таблиц, оптимизированных для памяти] (https: // blogs. msdn.microsoft.com/sqlcat/2016/05/20/logging-and-checkpoint-process-for-memory-optimized-tables-2/)
Операции, которые можно минимально протоколировать
Минимальное ведение журнала включает в себя регистрацию только той информации, которая требуется для восстановления транзакции без поддержки восстановления на определенный момент времени. В этом разделе описываются операции, которые минимально регистрируются в рамках модели восстановления с неполным протоколированием (а также в рамках простой модели восстановления, кроме случаев, когда выполняется резервное копирование).
Примечание
Минимальное ведение журнала не поддерживается для таблиц, оптимизированных для памяти.
Примечание
В модели полного восстановления все массовые операции полностью регистрируются. Однако вы можете свести к минимуму ведение журнала для набора массовых операций, временно переключив базу данных на модель восстановления с неполным протоколированием для массовых операций.Минимальное ведение журнала более эффективно, чем полное ведение журнала, и оно снижает вероятность крупномасштабной массовой операции, заполняющей доступное пространство журнала транзакций во время массовой транзакции. Однако, если база данных повреждена или потеряна при минимальном ведении журнала, вы не сможете восстановить базу данных до точки отказа.
Следующие операции, которые полностью регистрируются в рамках модели полного восстановления, минимально регистрируются в простой модели восстановления с неполным протоколированием:
Когда включена репликация транзакций, операции BULK INSERT полностью регистрируются даже в модели восстановления с массовым протоколированием.
Когда включена репликация транзакций, операции SELECT INTO полностью регистрируются даже в модели восстановления с неполным протоколированием.
Частичное обновление типов данных большого размера с использованием предложения .WRITE в операторе UPDATE при вставке или добавлении новых данных. Обратите внимание, что минимальное ведение журнала не используется при обновлении существующих значений. Дополнительные сведения о типах данных большого размера см. В разделе Типы данных (Transact-SQL).
Операторы WRITETEXT и UPDATETEXT при вставке или добавлении новых данных в столбцы типа данных text , ntext и image . Обратите внимание, что минимальное ведение журнала не используется при обновлении существующих значений.
Предупреждение
Операторы WRITETEXT и UPDATETEXT являются устаревшими ; избегайте их использования в новых приложениях.
Если для базы данных задана простая модель восстановления или модель восстановления с неполным протоколированием, некоторые операции DDL индекса минимально регистрируются независимо от того, выполняется операция в автономном или оперативном режиме. Минимально регистрируемые операции с индексами следующие:
Операции CREATE INDEX (включая индексированные представления).
Операции ALTER INDEX REBUILD или DBCC DBREINDEX.
Предупреждение
Оператор DBCC DBREINDEX является устаревшим ; Не используйте его в новых приложениях.
Примечание
Операции построения индекса используют минимальное ведение журнала, но могут задерживаться при одновременном выполнении резервного копирования. Эта задержка вызвана требованиями синхронизации страниц пула буферов с минимальным протоколированием при использовании простой модели восстановления или модели восстановления с неполным протоколированием.
DROP INDEX перестроение новой кучи (если применимо). Освобождение страницы индекса во время операции DROP INDEX — это , всегда полностью зарегистрировано.
Управление журналом транзакций
Резервное копирование журнала транзакций (модель полного восстановления)
Восстановление журнала транзакций (модель полного восстановления)
См. Также
Руководство по архитектуре журнала транзакций SQL Server и управлению им Свойства базы данных
Recovery Models (SQL Server)
Transaction Log Backups (SQL Server)
sys.dm_db_log_info (Transact-SQL)
sys.dm_db_log_space_usage (Transact-SQL)
Руководство по архитектуре и управлению журналом транзакций
— SQL Server
21. 09.2021
Читать 20 минут
Эта страница полезна?
Оцените свой опыт
да Нет
Любой дополнительный отзыв?
Отзыв будет отправлен в Microsoft: при нажатии кнопки «Отправить» ваш отзыв будет использован для улучшения продуктов и услуг Microsoft.Политика конфиденциальности.
Представлять на рассмотрение
В этой статье
Применимо к: SQL Server (все поддерживаемые версии) База данных SQL Azure Управляемый экземпляр SQL Azure Azure Synapse Analytics Platform System (PDW)
Каждая база данных SQL Server имеет журнал транзакций, в котором записываются все транзакции и модификации базы данных, сделанные каждой транзакцией.Журнал транзакций является важным компонентом базы данных, и в случае сбоя системы может потребоваться журнал транзакций, чтобы вернуть базу данных в согласованное состояние. В этом руководстве представлена информация о физической и логической архитектуре журнала транзакций. Понимание архитектуры может повысить эффективность управления журналами транзакций.
Логическая архитектура журнала транзакций
Журнал транзакций SQL Server работает логически так, как будто журнал транзакций представляет собой строку записей журнала.Каждая запись журнала идентифицируется порядковым номером журнала (LSN). Каждая новая запись журнала записывается в логический конец журнала с LSN, превышающим LSN предыдущей записи. Записи журнала хранятся в последовательной последовательности по мере их создания, так что если LSN2 больше LSN1, изменение, описанное записью журнала, на которую ссылается LSN2, произошло после изменения, описанного записью журнала LSN1. Каждая запись журнала содержит идентификатор транзакции, которой она принадлежит. Для каждой транзакции все записи журнала, связанные с транзакцией, индивидуально связаны в цепочку с использованием обратных указателей, которые ускоряют откат транзакции.
Записи журнала для изменений данных записывают либо выполненную логическую операцию, либо записывают образы измененных данных до и после. Изображение до — это копия данных до выполнения операции; остаточное изображение — это копия данных после выполнения операции.
Действия по восстановлению операции зависят от типа записи журнала:
Многие типы операций записываются в журнал транзакций. Эти операции включают:
Начало и конец каждой транзакции.
Каждое изменение данных (вставка, обновление или удаление). Сюда входят изменения с помощью системных хранимых процедур или операторов языка определения данных (DDL) в любую таблицу, включая системные таблицы.
Каждый экстент и выделение или освобождение страниц.
Создание или удаление таблицы или индекса.
Также регистрируются операции отката. Каждая транзакция резервирует место в журнале транзакций, чтобы убедиться, что в журнале достаточно места для поддержки отката, вызванного либо явным оператором отката, либо обнаруженной ошибкой. Объем зарезервированного пространства зависит от операций, выполняемых в транзакции, но обычно он равен количеству пространства, используемого для регистрации каждой операции. Это зарезервированное пространство освобождается после завершения транзакции.
Раздел файла журнала из первой записи журнала, которая должна присутствовать для успешного отката всей базы данных к последней записанной записи журнала, называется активной частью журнала, активным журналом или хвостом журнала . Это раздел журнала, необходимый для полного восстановления базы данных.Никакая часть активного журнала не может быть усечена. Порядковый номер журнала (LSN) этой первой записи журнала известен как минимальный LSN восстановления ( MinLSN ) . Дополнительные сведения об операциях, поддерживаемых журналом транзакций, см. В разделе Журнал транзакций (SQL Server).
Дифференциальные резервные копии и резервные копии журналов продвигают восстановленную базу данных на более позднее время, которое соответствует более высокому LSN.
Физическая архитектура журнала транзакций
Журнал транзакций в базе данных отображает один или несколько физических файлов.По сути, файл журнала представляет собой строку записей журнала. Физически последовательность записей журнала эффективно хранится в наборе физических файлов, реализующих журнал транзакций. Для каждой базы данных должен быть хотя бы один файл журнала.
Файлы виртуального журнала (VLF)
Компонент SQL Server Database Engine внутренне делит каждый физический файл журнала на несколько виртуальных файлов журнала (VLF). У виртуальных файлов журнала нет фиксированного размера, и нет фиксированного количества виртуальных файлов журнала для физического файла журнала.Компонент Database Engine динамически выбирает размер виртуальных файлов журнала при создании или расширении файлов журнала. Компонент Database Engine пытается поддерживать небольшое количество виртуальных файлов. Размер виртуальных файлов после расширения файла журнала представляет собой сумму размера существующего журнала и размера приращения нового файла. Размер или количество файлов виртуального журнала не могут быть настроены или установлены администраторами.
Примечание
Создание виртуального файла журнала (VLF) выполняется следующим образом:
Если следующий рост составляет менее 1/8 текущего физического размера журнала, то создайте 1 VLF, покрывающий размер роста (начиная с SQL Server 2014 (12.х))
Если следующий рост составляет более 1/8 от текущего размера журнала, используйте метод до 2014 года:
Если рост меньше 64 МБ, создайте 4 VLF, покрывающих размер роста (например, для увеличения на 1 МБ создайте четыре VLF по 256 КБ)
Если рост составляет от 64 МБ до 1 ГБ, создайте 8 VLF, покрывающих размер роста (например, для увеличения на 512 МБ создайте восемь VLF по 64 МБ)
Если рост превышает 1 ГБ, создайте 16 VLF, покрывающих размер роста (например, для увеличения на 8 ГБ создайте шестнадцать VLF по 512 МБ)
Если файлы журнала увеличиваются до большого размера с большим количеством небольших приращений, в них будет много виртуальных файлов журнала. Это может замедлить запуск базы данных, а также замедлить операции резервного копирования и восстановления журнала. И наоборот, если для файлов журнала задан большой размер с несколькими или только одним приращением, у них будет несколько очень больших виртуальных файлов журнала. Для получения дополнительной информации о правильной оценке требуемого размера и настройки автоматического увеличения журнала транзакций, обратитесь к разделу Рекомендации Руководства по управлению размером файла журнала транзакций.
Рекомендуется назначать файлам журнала значение размера , близкое к требуемому окончательному размеру, с использованием необходимых приращений для достижения оптимального распределения VLF, а также иметь относительно большое значение growth_increment .См. Совет ниже, чтобы определить оптимальное распределение VLF для текущего размера журнала транзакций.
Размер размер , установленный аргументом SIZE команды ALTER DATABASE , является начальным размером файла журнала.
Значение growth_increment (также называемое значением автоматического увеличения), установленное аргументом FILEGROWTH команды ALTER DATABASE , представляет собой объем пространства, добавляемого к файлу каждый раз, когда требуется новое пространство.
Дополнительные сведения об аргументах FILEGROWTH и SIZE для ALTER DATABASE см. В разделе Параметры файла и файловой группы ALTER DATABASE (Transact-SQL).
Подсказка
Чтобы определить оптимальное распределение VLF для текущего размера журнала транзакций всех баз данных в данном экземпляре и необходимые приращения роста для достижения требуемого размера, см. Этот сценарий.
Цикличность журнала транзакций
Журнал транзакций — это циклический файл.Например, рассмотрим базу данных с одним физическим файлом журнала, разделенным на четыре VLF. При создании базы данных логический файл журнала начинается с начала физического файла журнала. Новые записи журнала добавляются в конец логического журнала и расширяются к концу физического журнала. Усечение журнала освобождает любые виртуальные журналы, все записи которых появляются перед минимальным порядковым номером журнала восстановления (MinLSN). MinLSN — это порядковый номер самой старой записи журнала, которая требуется для успешного отката всей базы данных.Журнал транзакций в примере базы данных будет выглядеть так, как на следующем рисунке.
Когда конец логического журнала достигает конца физического файла журнала, новые записи журнала переходят в начало физического файла журнала.
Этот цикл повторяется бесконечно, пока конец логического журнала никогда не достигает начала логического журнала. Если старые записи журнала усекаются достаточно часто, чтобы всегда оставалось достаточно места для всех новых записей журнала, созданных через следующую контрольную точку, журнал никогда не заполняется.Однако, если конец логического журнала достигает начала логического журнала, происходит одно из двух:
Если для журнала включен параметр FILEGROWTH и на диске доступно пространство, файл расширяется на величину, указанную в параметре growth_increment , и новые записи журнала добавляются к расширению. Дополнительные сведения о параметре FILEGROWTH см. В разделе Параметры файла и файловой группы ALTER DATABASE (Transact-SQL).
Если параметр FILEGROWTH не включен или на диске, на котором хранится файл журнала, меньше свободного места, чем указано в growth_increment , генерируется ошибка 9002. Дополнительные сведения см. В разделе «Устранение неполадок с полным журналом транзакций».
Если журнал содержит несколько файлов физического журнала, логический журнал будет перемещаться по всем файлам физического журнала, прежде чем вернуться к началу первого файла физического журнала.
Усечение журнала
Усечение журнала необходимо для предотвращения заполнения журнала. При усечении журнала удаляются неактивные файлы виртуального журнала из журнала логических транзакций базы данных SQL Server, освобождая место в логическом журнале для повторного использования физическим журналом транзакций. Если журнал транзакций никогда не усекался, он в конечном итоге заполнил бы все дисковое пространство, выделенное для его физических файлов журнала. Однако, прежде чем журнал может быть усечен, должна произойти операция контрольной точки. Контрольная точка записывает текущие измененные страницы в памяти (известные как грязные страницы) и информацию журнала транзакций из памяти на диск.При выполнении контрольной точки неактивная часть журнала транзакций помечается как повторно используемая. После этого неактивная часть может быть освобождена путем усечения журнала. Дополнительные сведения о контрольных точках см. В разделе Контрольные точки базы данных (SQL Server).
На следующих рисунках показан журнал транзакций до и после усечения. На первом рисунке показан журнал транзакций, который никогда не усекался. В настоящее время логическим журналом используются четыре файла виртуального журнала. Логический журнал начинается в начале первого файла виртуального журнала и заканчивается виртуальным журналом 4.Запись MinLSN находится в виртуальном журнале 3. Виртуальный журнал 1 и виртуальный журнал 2 содержат только неактивные записи журнала. Эти записи могут быть усечены. Виртуальный журнал 5 все еще не используется и не является частью текущего логического журнала.
На второй иллюстрации показано, как выглядит журнал после усечения. Виртуальный журнал 1 и виртуальный журнал 2 освобождены для повторного использования. Логический журнал теперь начинается с начала виртуального журнала 3. Виртуальный журнал 5 все еще не используется и не является частью текущего логического журнала.
Усечение журнала происходит автоматически после следующих событий, за исключением случаев, когда по какой-либо причине задерживается:
По простой модели восстановления, после КПП.
При модели полного восстановления или модели восстановления с неполным протоколированием, после резервного копирования журнала, если контрольная точка произошла с момента предыдущего резервного копирования.
Усечение журнала может быть отложено по разным причинам. В случае длительной задержки усечения журнала журнал транзакций может заполниться.Дополнительные сведения см. В разделах «Факторы, которые могут задерживать усечение журнала» и «Устранение неполадок с полным журналом транзакций (ошибка SQL Server 9002)».
Журнал транзакций с упреждающей записью
В этом разделе описывается роль журнала транзакций с упреждающей записью в записи изменений данных на диск. SQL Server использует алгоритм ведения журнала с упреждающей записью (WAL), который гарантирует, что никакие изменения данных не будут записаны на диск до того, как соответствующая запись журнала будет записана на диск. Это поддерживает свойства ACID для транзакции.
Чтобы понять, как работает журнал упреждающей записи, важно знать, как измененные данные записываются на диск. SQL Server поддерживает буферный кеш, в который он считывает страницы данных, когда данные должны быть извлечены. Когда страница изменяется в буферном кэше, она не сразу записывается обратно на диск; вместо этого страница помечается как грязная . Страница данных может иметь более одной логической записи, прежде чем она будет физически записана на диск. Для каждой логической записи запись журнала транзакций вставляется в кэш журнала, в котором записано изменение.Записи журнала должны быть записаны на диск до того, как связанная грязная страница будет удалена из буферного кеша и записана на диск. Процесс контрольной точки периодически сканирует буферный кеш на наличие буферов со страницами из указанной базы данных и записывает все грязные страницы на диск. Контрольные точки экономят время при более позднем восстановлении, создавая точку, в которой все грязные страницы гарантированно будут записаны на диск.
Запись измененной страницы данных из буферного кеша на диск называется очисткой страницы.SQL Server имеет логику, которая предотвращает сброс грязной страницы до того, как будет записана связанная запись журнала. Записи журнала записываются на диск при очистке буферов журнала. Это происходит всякий раз, когда транзакция фиксируется или буферы журнала заполняются.
Резервные копии журналов транзакций
В этом разделе представлены концепции резервного копирования и восстановления (применения) журналов транзакций. В моделях полного восстановления и восстановления с неполным протоколированием для восстановления данных необходимо регулярное резервное копирование журналов транзакций ( резервных копий журналов, ).Вы можете создать резервную копию журнала во время выполнения любого полного резервного копирования. Дополнительные сведения о моделях восстановления см. В разделе Резервное копирование и восстановление баз данных SQL Server.
Прежде чем вы сможете создать первую резервную копию журнала, вы должны создать полную резервную копию, например резервную копию базы данных или первую в наборе резервных копий файлов. Восстановление базы данных с использованием только резервных копий файлов может оказаться сложным. Поэтому мы рекомендуем по возможности начинать с полной резервной копии базы данных. После этого необходимо регулярно выполнять резервное копирование журнала транзакций.Это не только минимизирует вероятность потери работы, но также позволяет усекать журнал транзакций. Обычно журнал транзакций обрезается после каждой стандартной резервной копии журнала.
Важно
Мы рекомендуем делать резервные копии журналов достаточно часто, чтобы соответствовать требованиям вашего бизнеса, в частности вашей терпимости к потерям в работе, например, из-за повреждения хранилища журналов. Подходящая частота создания резервных копий журналов зависит от вашей терпимости к риску потери работы, сбалансированной тем, сколько резервных копий журналов вы можете хранить, управлять и, возможно, восстанавливать.Подумайте о требуемых RTO и RPO при реализации стратегии восстановления, и особенно о периодичности резервного копирования журналов. Резервного копирования журнала каждые 15–30 минут может быть достаточно. Если ваш бизнес требует минимизировать риск потери работы, рассмотрите возможность более частого резервного копирования журналов. Дополнительное преимущество более частого резервного копирования журналов состоит в увеличении частоты усечения журналов, что приводит к уменьшению размера файлов журналов.
Важно
Чтобы ограничить количество резервных копий журналов, которые необходимо восстановить, важно регулярно выполнять резервное копирование данных.Например, вы можете запланировать еженедельное полное резервное копирование базы данных и ежедневное дифференциальное резервное копирование базы данных.
Опять же, подумайте о требуемых RTO и RPO при реализации стратегии восстановления, и особенно о периодичности полного и дифференциального резервного копирования базы данных.
Дополнительные сведения о резервных копиях журнала транзакций см. В разделе Резервные копии журнала транзакций (SQL Server).
Цепь из бревна
Непрерывная последовательность резервных копий журналов называется цепочкой журналов . Цепочка журналов начинается с полной резервной копии базы данных.Обычно новая цепочка журналов запускается только при первом резервном копировании базы данных или после переключения модели восстановления с простого восстановления на полное или восстановление с неполным протоколированием. Если вы не решите перезаписать существующие наборы резервных копий при создании полной резервной копии базы данных, существующая цепочка журналов останется нетронутой. Если цепочка журналов не повреждена, вы можете восстановить свою базу данных из любой полной резервной копии базы данных в наборе носителей с последующими резервными копиями журналов через точку восстановления. Точкой восстановления может быть конец последней резервной копии журнала или конкретная точка восстановления в любой из резервных копий журнала.Дополнительные сведения см. В разделе Резервное копирование журнала транзакций (SQL Server).
Чтобы восстановить базу данных до точки отказа, цепочка журналов должна быть неповрежденной. То есть непрерывная последовательность резервных копий журнала транзакций должна доходить до точки отказа. Где должна начинаться эта последовательность журнала, зависит от типа восстанавливаемых резервных копий данных: база данных, частичная или файловая. Для базы данных или частичного резервного копирования последовательность резервных копий журнала должна начинаться с конца базы данных или частичного резервного копирования. Для набора резервных копий файлов последовательность резервных копий журналов должна начинаться с начала полного набора резервных копий файлов.Дополнительные сведения см. В разделе Применение резервных копий журнала транзакций (SQL Server).
Восстановить резервные копии журналов
Восстановление резервной копии журнала повторяет изменения, которые были записаны в журнале транзакций, чтобы воссоздать точное состояние базы данных на момент начала операции резервного копирования журнала. Когда вы восстанавливаете базу данных, вам нужно будет восстановить резервные копии журналов, которые были созданы после полной резервной копии базы данных, которую вы восстанавливаете, или с начала первой резервной копии файла, которую вы восстанавливаете. Как правило, после восстановления самых последних данных или дифференциальной резервной копии необходимо восстановить серию резервных копий журналов, пока не будет достигнута точка восстановления.Затем вы восстанавливаете базу данных. Это откатывает все транзакции, которые были незавершенными на момент начала восстановления, и переводит базу данных в оперативный режим. После восстановления базы данных вы больше не сможете восстанавливать резервные копии. Дополнительные сведения см. В разделе Применение резервных копий журнала транзакций (SQL Server).
Контрольные точки и активная часть журнала
Контрольные точки сбрасывают страницы с грязными данными из буферного кеша текущей базы данных на диск. Это минимизирует активную часть журнала, которая должна быть обработана во время полного восстановления базы данных.Во время полного восстановления выполняются следующие типы действий:
Для журнальных записей модификаций, не сброшенных на диск перед остановкой системы, выполняется повтор транзакций.
Все модификации, связанные с незавершенными транзакциями, например транзакциями, для которых нет записи журнала COMMIT или ROLLBACK, откатываются.
КПП
Контрольная точка выполняет в базе данных следующие процессы:
Записывает запись в файл журнала, обозначающую начало контрольной точки.
Хранит информацию, записанную для контрольной точки, в цепочке записей журнала контрольной точки.
Одна часть информации, записанная в контрольной точке, — это порядковый номер журнала (LSN) первой записи журнала, которая должна присутствовать для успешного отката для всей базы данных. Этот номер LSN называется LSN минимального восстановления (MinLSN). MinLSN — это минимум:
LSN начала КПП.
LSN начала самой старой активной транзакции.
LSN начала самой старой транзакции репликации, которая еще не была доставлена в базу данных распространителя.
Записи контрольной точки также содержат список всех активных транзакций, которые изменили базу данных.
Если в базе данных используется простая модель восстановления, помечается для повторного использования пространство перед MinLSN.
Записывает все грязные страницы журнала и данных на диск.
Записывает в файл журнала запись, обозначающую конец контрольной точки.
Записывает LSN начала этой цепочки на загрузочную страницу базы данных.
Действия, вызывающие контрольную точку
Контрольные точки возникают в следующих ситуациях:
Оператор CHECKPOINT выполняется явно. Контрольная точка возникает в текущей базе данных для соединения.
В базе данных выполняется минимально регистрируемая операция; например, операция массового копирования выполняется в базе данных, которая использует модель восстановления с неполным протоколированием.
Файлы базы данных были добавлены или удалены с помощью ALTER DATABASE.
Экземпляр SQL Server останавливается инструкцией SHUTDOWN или службой SQL Server (MSSQLSERVER). Любое действие вызывает контрольную точку в каждой базе данных в экземпляре SQL Server.
Экземпляр SQL Server периодически генерирует автоматические контрольные точки в каждой базе данных, чтобы сократить время, которое потребуется экземпляру для восстановления базы данных.
Сделана резервная копия базы данных.
Выполняется действие, требующее завершения работы базы данных. Например, для параметра AUTO_CLOSE установлено значение ON, и последнее пользовательское соединение с базой данных закрыто, или при изменении параметра базы данных требуется перезапуск базы данных.
Автоматические контрольно-пропускные пункты
Компонент SQL Server Database Engine создает автоматические контрольные точки. Интервал между автоматическими контрольными точками зависит от объема используемого пространства журнала и времени, прошедшего с момента последней контрольной точки. Временной интервал между автоматическими контрольными точками может быть очень изменчивым и длинным, если в базу данных внесены небольшие изменения.Автоматические контрольные точки также могут возникать часто при изменении большого количества данных.
Используйте параметр конфигурации сервера интервал восстановления , чтобы вычислить интервал между автоматическими контрольными точками для всех баз данных на экземпляре сервера. Этот параметр указывает максимальное время, которое компонент Database Engine должен использовать для восстановления базы данных во время перезапуска системы. Компонент Database Engine оценивает, сколько записей журнала он может обработать за интервал восстановления во время операции восстановления.
Интервал между автоматическими контрольными точками также зависит от модели восстановления:
Если в базе данных используется модель восстановления с полным или неполным протоколированием, автоматическая контрольная точка создается всякий раз, когда количество записей журнала достигает числа, которое, по оценкам компонента Database Engine, оно может обработать в течение времени, указанного в параметре интервала восстановления.
Если база данных использует простую модель восстановления, автоматическая контрольная точка создается всякий раз, когда количество записей журнала достигает меньшего из этих двух значений:
Журнал заполняется на 70 процентов.
Число записей журнала достигает того числа, которое, по оценке компонента Database Engine, он может обработать в течение времени, указанного в параметре интервала восстановления.
Сведения о настройке интервала восстановления см. В разделе Настройка параметра конфигурации сервера для интервала восстановления.
Подсказка
Параметр расширенной настройки -k SQL Server позволяет администратору базы данных регулировать поведение ввода-вывода контрольной точки в зависимости от пропускной способности подсистемы ввода-вывода для некоторых типов контрольных точек.Параметр настройки -k применяется к автоматическим контрольным точкам и любым другим неуправляемым контрольным точкам.
Автоматические контрольные точки обрезают неиспользуемый раздел журнала транзакций, если база данных использует простую модель восстановления. Однако, если в базе данных используются модели восстановления с полным или неполным протоколированием, журнал не усекается автоматическими контрольными точками. Для получения дополнительной информации см. Журнал транзакций.
Оператор CHECKPOINT теперь предоставляет необязательный аргумент checkpoint_duration, который указывает запрошенный период времени в секундах для завершения контрольных точек.Для получения дополнительной информации см. КОНТРОЛЬНАЯ ТОЧКА.
Активный журнал
Раздел файла журнала от MinLSN до последней записанной записи журнала называется активной частью журнала или активным журналом. Это раздел журнала, необходимый для полного восстановления базы данных. Никакая часть активного журнала не может быть усечена. Все записи журнала должны быть вырезаны из частей журнала перед MinLSN.
На следующем рисунке показана упрощенная версия журнала завершения транзакции с двумя активными транзакциями.Записи контрольных точек были сжаты до единой записи.
LSN 148 — последняя запись в журнале транзакций. Во время обработки записанной контрольной точки в LSN 147 Транзакция 1 была зафиксирована, а Транзакция 2 была единственной активной транзакцией. Это делает первую запись журнала для Транса 2 самой старой записью журнала для транзакции, активной во время последней контрольной точки. Это делает LSN 142, запись начала транзакции для Транзакции 2, MinLSN.
Долгосрочные транзакции
Активный журнал должен включать каждую часть всех незафиксированных транзакций.Приложение, которое запускает транзакцию и не фиксирует ее или не откатывает ее, не позволяет компоненту Database Engine продвигать MinLSN. Это может вызвать два типа проблем:
Если система выключается после того, как транзакция выполнила много незафиксированных изменений, фаза восстановления последующего перезапуска может занять намного больше времени, чем время, указанное в опции интервал восстановления .
Журнал может вырасти очень большим, потому что журнал не может быть усечен за пределами MinLSN.Это происходит, даже если база данных использует простую модель восстановления, в которой журнал транзакций обычно усекается на каждой автоматической контрольной точке.
Начиная с SQL Server 2019 (15.x) и в базе данных SQL Azure, восстановления длительно выполняющихся транзакций и проблем, описанных выше, можно избежать с помощью ускоренного восстановления базы данных.
Транзакции репликации
Агент чтения журнала отслеживает журнал транзакций каждой базы данных, настроенной для репликации транзакций, и копирует транзакции, помеченные для репликации, из журнала транзакций в базу данных распространителя.Активный журнал должен содержать все транзакции, отмеченные для репликации, но еще не доставленные в базу данных распространителя. Если эти транзакции не реплицируются своевременно, они могут предотвратить усечение журнала. Дополнительные сведения см. В разделе Репликация транзакций.
См. Также
Мы рекомендуем следующие статьи и книги для получения дополнительной информации о журналах транзакций и передовых методах управления журналами.
Журнал транзакций (SQL Server)
Управление размером файла журнала транзакций
Резервные копии журнала транзакций (SQL Server)
Контрольные точки базы данных (SQL Server)
Настройка интервала восстановления Параметр конфигурации сервера
Ускоренное восстановление базы данных
sys.dm_db_log_info (Transact-SQL)
sys.dm_db_log_space_usage (Transact-SQL)
Общие сведения о ведении журнала и восстановлении в SQL Server, Пол Рэндал
Управление журналом транзакций SQL Server, Тони Дэвис и Гейл Шоу
Устранение неполадок с ошибкой полного журнала транзакций 9002 — SQL Server
23.11.2021
Читать 19 минут
Эта страница полезна?
Оцените свой опыт
да Нет
Любой дополнительный отзыв?
Отзыв будет отправлен в Microsoft: при нажатии кнопки «Отправить» ваш отзыв будет использован для улучшения продуктов и услуг Microsoft.Политика конфиденциальности.
Представлять на рассмотрение
В этой статье
Применимо к: SQL Server (все поддерживаемые версии)
, вариант 1. Выполните шаги непосредственно в исполняемой записной книжке через Azure Data Studio
.
Вариант 2: Выполните шаг вручную
В этом разделе обсуждаются возможные ответы на полный журнал транзакций и предлагается, как этого избежать в будущем.
Когда журнал транзакций заполняется, ядро СУБД SQL Server выдает ошибку 9002 . Журнал может заполняться, когда база данных находится в оперативном режиме или в процессе восстановления. Если журнал заполняется, когда база данных находится в оперативном режиме, база данных остается в оперативном режиме, но ее можно только читать, но не обновлять. Если журнал заполняется во время восстановления, компонент Database Engine помечает базу данных как RESOURCE PENDING. В любом случае требуется действие пользователя, чтобы освободить место для журнала.
Общие причины полного журнала транзакций
Соответствующий ответ на полный журнал транзакций зависит от того, при каких условиях журнал был заполнен.Общие причины включают:
Журнал не усекается
Диск заполнен
Размер журнала установлен на фиксированное максимальное значение или автоматический рост отключен
Не удается выполнить репликацию или синхронизацию группы доступности
Как разрешить полный журнал транзакций
Следующие конкретные шаги помогут найти причину полного журнала транзакций и решить проблему.
1. Обрезать журнал
Очень распространенное решение этой проблемы — обеспечить выполнение резервных копий журнала транзакций для вашей базы данных, что обеспечит усечение журнала.Если для базы данных с полным журналом транзакций не указана история журнала последних транзакций, решение проблемы простое: возобновить регулярное резервное копирование журнала транзакций базы данных.
Объяснение усечения журнала
Есть разница между усечением журнала транзакций и сжатием журнала транзакций. Усечение журнала обычно происходит во время резервного копирования журнала транзакций и представляет собой логическую операцию, которая удаляет зафиксированные записи внутри журнала, тогда как сжатие журнала освобождает физическое пространство в файловой системе за счет уменьшения размера файла.Усечение журнала происходит на границе виртуального файла журнала (VLF), и файл журнала может содержать много VLF. Файл журнала можно сжать только в том случае, если внутри файла журнала есть пустое место для восстановления. Само по себе сжатие файла журнала не может решить проблему полного файла журнала, вместо этого вы должны выяснить, почему файл журнала заполнен и не может быть усечен.
Предупреждение
Данные, перемещаемые для сжатия файла, могут быть размещены в любом доступном месте в файле. Это вызывает фрагментацию индекса и может снизить производительность запросов, выполняющих поиск в диапазоне индекса.Чтобы устранить фрагментацию, рассмотрите возможность восстановления индексов файла после сжатия. Дополнительные сведения см. В разделе «Сжать базу данных».
Что предотвращает усечение журнала?
Чтобы узнать, что мешает усечению журнала в данном случае, используйте столбцы log_reuse_wait и log_reuse_wait_desc представления каталога sys.databases . Дополнительные сведения см. В разделе sys.databases (Transact-SQL). Описание факторов, которые могут задерживать усечение журнала, см. В разделе Журнал транзакций (SQL Server).
Следующий набор команд T-SQL поможет вам определить, не усечен ли журнал транзакций базы данных, и причину этого. Следующий сценарий также порекомендует действия для решения проблемы:
УСТАНОВИТЬ БЕЗ СЧЕТА DECLARE @SQL VARCHAR (8000), @log_reuse_wait tinyint, @log_reuse_wait_desc nvarchar (120), @dbname sysname, @database_id int, @recovery_model_desc varchar (24) ЕСЛИ (OBJECT_id (N'tempdb .. # CannotTruncateLog_Db ') не равен нулю) НАЧИНАТЬ УДАЛИТЬ ТАБЛИЦУ #CannotTruncateLog_Db КОНЕЦ - получить информацию о журналах транзакций в каждой базе данных.Используйте DMV, который поддерживает все поддерживаемые версии ЕСЛИ (OBJECT_id (N'tempdb .. # dm_db_log_space_usage ') не равен нулю) НАЧИНАТЬ ОТКЛЮЧИТЬ ТАБЛИЦУ #dm_db_log_space_usage КОНЕЦ ВЫБЕРИТЕ * В #dm_db_log_space_usage ИЗ sys.dm_db_log_space_usage, где 1 = 0 ОБЪЯВЛЕНИЕ КУРСОРА log_space ДЛЯ ВЫБОРА ИМЕНИ ИЗ sys.databases ОТКРЫТЬ log_space ВЫБРАТЬ ДАЛЕЕ ИЗ log_space в @dbname ПОКА @@ FETCH_STATUS = 0 НАЧИНАТЬ установить @SQL = ' вставить в #dm_db_log_space_usage ( database_id, total_log_size_in_bytes, used_log_space_in_bytes, used_log_space_in_percent, log_space_in_bytes_since_last_backup ) Выбрать database_id, total_log_size_in_bytes, used_log_space_in_bytes, used_log_space_in_percent, log_space_in_bytes_since_last_backup из '+ @dbname +'.sys.dm_db_log_space_usage ' НАЧАТЬ ПОПРОБОВАТЬ exec (@SQL) КОНЕЦ ПОПЫТКИ НАЧАТЬ ЛОВ ВЫБРАТЬ ERROR_MESSAGE () AS ErrorMessage; КОНЕЦ ЗАХВАТ; ВЫБРАТЬ ДАЛЕЕ ИЗ log_space в @dbname КОНЕЦ ЗАКРЫТЬ log_space DEALLOCATE log_space - выберите затронутые базы данных ВЫБРАТЬ sdb.name как DbName, sdb.log_reuse_wait, sdb.log_reuse_wait_desc, log_reuse_wait_explanation = СЛУЧАЙ КОГДА log_reuse_wait = 1 ТОГДА 'С момента последнего усечения журнала не было контрольной точки, или заголовок журнала еще не переместился за пределы' WHEN log_reuse_wait = 2 THEN 'Перед усечением журнала транзакций требуется резервная копия журнала.' WHEN log_reuse_wait = 3 THEN 'Выполняется резервное копирование или восстановление данных (все модели восстановления). Подождите или отмените резервное копирование » WHEN log_reuse_wait = 4 THEN 'Длительно выполняющаяся активная транзакция или отложенная транзакция не позволяют усекать журнал. Вы можете попытаться создать резервную копию журнала, чтобы освободить место, или завершить / откатить длинную транзакцию. WHEN log_reuse_wait = 5 THEN 'Зеркальное отображение базы данных приостановлено или в режиме высокой производительности зеркальная база данных значительно отстает от основной базы данных.(Только для модели полного восстановления) ' WHEN log_reuse_wait = 6 THEN 'Во время репликации транзакций транзакции, относящиеся к публикациям, все еще не доставляются в базу данных распространителя. Изучите состояние агентов, участвующих в репликации или записи измененных данных (CDC). (Только для модели полного восстановления.) ' КОГДА log_reuse_wait = 7 ТОГДА 'Создается моментальный снимок базы данных. Это обычная и обычно кратковременная причина отложенного усечения журнала. WHEN log_reuse_wait = 8 THEN 'Выполняется сканирование журнала транзакций.Это обычная процедура, которая обычно является кратковременной причиной отложенного усечения журнала. WHEN log_reuse_wait = 9 THEN 'Вторичная реплика группы доступности применяет записи журнала транзакций этой базы данных к соответствующей вторичной базе данных. (Только для модели полного восстановления.) ' WHEN log_reuse_wait = 13 THEN 'Если база данных настроена на использование косвенных контрольных точек, самая старая страница в базе данных может быть старше, чем порядковый номер журнала контрольной точки (LSN).' WHEN log_reuse_wait = 16 THEN 'Контрольная точка OLTP в памяти не возникла с момента последнего усечения журнала, или заголовок журнала еще не переместился за пределы VLF.' ИНАЧЕ 'None' END, sdb.database_id, sdb.recovery_model_desc, lsu.used_log_space_in_bytes / 1024 как Used_log_size_MB, lsu.total_log_size_in_bytes / 1024 как Total_log_size_MB, 100 - lsu.used_log_space_in_percent как Percent_Free_Space INTO #CannotTruncateLog_Db ИЗ sys.databases КАК sdb ВНУТРЕННЕЕ СОЕДИНЕНИЕ #dm_db_log_space_usage lsu ON sdb.database_id = lsu.database_id ГДЕ log_reuse_wait> 0 ВЫБРАТЬ * ИЗ #CannotTruncateLog_Db ОБЪЯВЛЕНИЕ КУРСОРА no_truncate_db ДЛЯ ВЫБЕРИТЕ log_reuse_wait, log_reuse_wait_desc, dbname, database_id, recovery_model_desc FROM #CannotTruncateLog_Db; ОТКРЫТЬ no_truncate_db ПОЛУЧИТЬ СЛЕДУЮЩИЙ ИЗ no_truncate_db в @log_reuse_wait, @log_reuse_wait_desc, @dbname, @database_id, @recovery_model_desc ПОКА @@ FETCH_STATUS = 0 НАЧИНАТЬ если (@log_reuse_wait> 0) выберите '-' '' + @dbname + '' 'база данных имеет log_reuse_wait =' + @log_reuse_wait_desc + '-' как 'Индивидуальный отчет базы данных' если (@log_reuse_wait = 1) НАЧИНАТЬ выберите «Рассмотрите возможность запуска команды контрольной точки, чтобы попытаться решить эту проблему, в противном случае в процессе контрольной точки может потребоваться дополнительная t-съемка.Кроме того, проверьте журнал на наличие активных VLF в конце файла в качестве Рекомендации выберите 'USE' '' + @ dbname + '' '; CHECKPOINT 'как CheckpointCommand выберите 'select * from sys.dm_db_log_info (' + CONVERT (varchar, @ database_id) + ')' как VLF_LogInfo КОНЕЦ иначе, если (@log_reuse_wait = 2) НАЧИНАТЬ выберите модель восстановления '+ @recovery_model_desc +' предполагаемым выбором для базы данных '' '+ @ dbname +' ''? Просмотрите модели восстановления и определите, нужно ли вам их изменить. https://docs.microsoft.com / sql / relational-databases / backup-restore / recovery-models-sql-server 'как RecoveryModelChoice выберите «Чтобы усечь журнал, рассмотрите возможность резервного копирования журнала транзакций в базе данных» '' + @ dbname + '' ', которая находится в модели восстановления' + @recovery_model_desc + '. Помните о любых существующих цепочках резервного копирования журналов, которые могут быть нарушены »как Рекомендация. выберите 'BACKUP LOG [' + @dbname + '] TO DISK =' 'some_volume: \ some_folder \' + @dbname + '_LOG.trn' '' как BackupLogCommand КОНЕЦ иначе, если (@log_reuse_wait = 3) НАЧИНАТЬ выберите «Либо дождитесь, либо отмените все активные в данный момент резервные копии для базы данных» '' + @ dbname + '' '.Чтобы проверить наличие резервных копий, запустите эту команду: 'как Рекомендация выберите 'select * from sys.dm_exec_requests, где команда типа' 'backup%' 'или команда типа' 'restore%' '' в качестве FindBackupOrRestore КОНЕЦ иначе, если (@log_reuse_wait = 4) НАЧИНАТЬ выберите «Активные транзакции, которые в настоящее время выполняются для базы данных» '' + @ dbname + '' '. Чтобы проверить наличие активных транзакций, выполните следующие команды: 'как Рекомендация выберите 'DBCC OPENTRAN (' '' + @ dbname + '' ')' как FindOpenTran select 'select database_id, db_name (database_id) dbname, database_transaction_begin_time, database_transaction_state, database_transaction_log_record_count, database_transaction_log_bytes_used, database_transaction_begin_lsn, stran.session_id из sys.dm_tran_database_transactions dbtran оставил внешнее соединение sys.dm_tran_session_transactions stran на dbtran.transaction_id = stran.transaction_id, где database_id = '+ CONVERT (varchar, @database_id) as FindOpenTransAndSession КОНЕЦ иначе, если (@log_reuse_wait = 5) НАЧИНАТЬ выберите «Зеркальное отображение базы данных для базы данных» '' + @ dbname + '' 'отстает при синхронизации. Чтобы проверить состояние DBM, выполните следующие команды: 'как Рекомендация select 'выберите db_name (database_id), mirroring_state_desc, mirroring_role_desc, mirroring_safety_level_desc из sys.database_mirroring, где mirroring_guid не равно null, и mirroring_state <> 4 и database_id = '+ convert (sysname, @database_id) как CheckMirroringStatus выберите «Зеркальное отображение базы данных для базы данных» '' + @ dbname + '' 'может быть позади: проверьте unsent_log, send_rate, unrestored_log, recovery_rate, average_delay в этом выводе' в качестве рекомендации выберите 'exec msdb.sys.sp_dbmmonitoraddmonitoring 1; exec msdb.sys.sp_dbmmonitorresults '' '+ @ имя_базы +' '', 5, 0; ждать задержки '00: 01: 01 ''; exec msdb.sys.sp_dbmmonitorresults '' '+ @ dbname +' ''; exec msdb.sys.sp_dbmmonitordropmonitoring 'как CheckMirroringStatusAnd КОНЕЦ иначе, если (@log_reuse_wait = 6) НАЧИНАТЬ выберите «Транзакции репликации все еще не доставлены из базы данных издателя» '' + @ dbname + '' 'в базу данных распространения. Проверьте самую старую транзакцию нераспределенной репликации. Также проверьте, запущен ли агент чтения журнала и не возникли ли в нем какие-либо ошибки »в соответствии с рекомендациями. выберите DBCC OPENTRAN ('' '+ @dbname +' '') 'как CheckOldestNonDistributedTran select 'выберите топ 5 * из раздачи..MSlogreader_history, где runstatus в (6, 5) или error_id <> 0 и agent_id = find_in_mslogreader_agents_table упорядочены по времени по убыванию 'как LogReaderAgentState КОНЕЦ иначе, если (@log_reuse_wait = 9) НАЧИНАТЬ выберите «Всегда включенные транзакции, которые все еще не доставляются из первичной базы данных» '' + @ dbname + '' 'на вторичные реплики. Проверьте работоспособность узлов AG и, если есть задержка, выберите «Перемещение блока журнала на вторичные узлы» в качестве рекомендации. select 'select availability_group = cast (ag.name as varchar (30)), primary_replica = cast (ags.primary_replica как varchar (30)), primary_recovery_health_desc = cast (ags.primary_recovery_health_desc as varchar (30)), synchronization_health_desc = cast (ags.synchronization_health_desc as varchar (30)), ag.failure_condition_level_c_time_custom_condition_level_c._ automatic_backup_preference_desc как varchar (10)) из sys.availability_groups ag присоединиться к sys.dm_hadr_availability_group_states ags на ag.group_id = ags.group_id 'как CheckAGHealth выберите 'SELECT group_name = cast (arc.group_name как varchar (30)), replica_server_name = cast (arc.replica_server_name как varchar (30)), node_name = cast (arc.node_name как varchar (30)), role_desc = cast (ars.role_desc as varchar (30)), ar.availability_mode_Desc, operating_state_desc = cast (ars.operational_state_desc as varchar (30)), connected_state_desc = cast (ars.connected_state_desc as varchar (30)), recovery_health_desc = cast (ars.recovery_health_desc), cast (30) ars.synchronization_health_desc как varchar (30)), ars.last_connect_error_number, last_connect_error_description = литой (ars.last_connect_error_description, как VARCHAR (30)), ars.last_connect_error_timestamp, primary_role_allow_connections_desc = гипс (ar.primary_role_allow_connections_desc как VARCHAR (30)) от sys.dm_hadr_availability_replica_cluster_nodes дуги присоединяется sys.dm_hadr_availability_replica_cluster_states дуги на arc.replica_server_name = дугах. имя_сервера реплики присоединиться к sys.dm_hadr_availability_replica_states ars на arcs.replica_id = ars.replica_id присоединиться к sys.Availability_replicas ar на ars.replica_id = ar.replica_id присоединиться к sys.availability_groups ag на ag.group_id = arcs.group_id и ag.name = arc.group_name ORDER BY cast (arc.group_name as varchar (30)), cast (ars.role_desc как varchar (30)) 'как CheckReplicaHealth выберите 'select database_name = cast (drcs.database_name as varchar (30)), drs.database_id, drs.group_id, drs.replica_id, drs.is_local, drcs.is_failover_ready, drcs.is_pending_secondary_suspend, drcs.is_database_joined, drsuspended.is_ .is_commit_participant, suspend_reason_desc = cast (drs.suspend_reason_desc as varchar (30)), synchronization_state_desc = cast (drs.synchronization_state_desc as varchar (30)), synchronization_health_desc = cast (drs.synchronization_health_desc as varchar (30)), database_state_desc = cast (drs.d_state) aschar (30) drs.last_sent_lsn, drs.last_sent_time, drs.last_received_lsn, drs.last_received_time, drs.last_hardened_lsn, drs.last_hardened_time, drs.last_redone_lsn, drs.last_redone_time, drs.redo_rate, drs.filestream_send_rate, drs.end_of_log_lsn, drs.last_commit_lsn, drs.last_commit_time, drs.low_water_mark_for_ghosts, drs.recovery_lsn, drs.truncation_lsn, pr.file_id_id, pr.error_lsn, pr.file_id_id_page.error_id_pr. sys.dm_hadr_database_replica_cluster_states drcs присоединяются к sys.dm_hadr_database_replica_states drs на drcs.replica_id = drs.replica_id и drcs.group_database_id = drs.group_database_id_id_id_sys.dm_hadrs_database_sys.dm_hadrs_order_auto_sys.dm_hadrs.dre_autodatabase_id 'как LogMovementHealth выберите «Для получения дополнительной информации см. https://docs.microsoft.com/en-us/troubleshoot/sql/availability-groups/error-9002-transaction-log-large» в качестве OnlineDOCResource. КОНЕЦ иначе, если (@log_reuse_wait в (10, 11, 12, 14)) НАЧИНАТЬ выберите «Это состояние не задокументировано, ожидается, что оно будет редким и непродолжительным» в качестве Рекомендации КОНЕЦ иначе, если (@log_reuse_wait = 13) НАЧИНАТЬ выберите 'Самая старая страница в базе данных может быть старше, чем порядковый номер журнала контрольной точки (LSN).В этом случае самая старая страница может задержать усечение журнала. как находка выберите «Это состояние должно быть недолговечным, но если вы обнаружите, что оно занимает много времени, вы можете временно отключить косвенную контрольную точку» в качестве рекомендации выберите 'ALTER DATABASE [' + @ dbname + '] SET TARGET_RECOVERY_TIME = 0' как DisableIndirectCheckpointTempoporary КОНЕЦ иначе, если (@log_reuse_wait = 16) НАЧИНАТЬ select 'Для таблиц, оптимизированных для памяти, автоматическая контрольная точка берется, когда файл журнала транзакций становится больше 1.5 ГБ с момента последней контрольной точки (включая таблицы, оптимизированные для диска и памяти) 'в качестве поиска выберите «Обзор https://blogs.msdn.microsoft.com/sqlcat/2016/05/20/logging-and-checkpoint-process-for-memory-optimized-tables-2/» в качестве ReviewBlog. выберите 'use' + @ dbname + 'CHECKPOINT' в качестве RunCheckpoint КОНЕЦ ПОЛУЧИТЬ СЛЕДУЮЩИЙ ИЗ no_truncate_db в @log_reuse_wait, @log_reuse_wait_desc, @dbname, @database_id, @recovery_model_desc КОНЕЦ ЗАКРЫТЬ no_truncate_db DEALLOCATE no_truncate_db
LOG_BACKUP log_reuse_wait
Наиболее распространенные действия, которые вы можете здесь рассмотреть, — это просмотреть модель восстановления вашей базы данных и создать резервную копию журнала транзакций вашей базы данных.
Рассмотрим модель восстановления базы данных
Журнал транзакций может не усекать с категорией LOG_BACKUP log_reuse_wait, потому что вы никогда не создавали его резервную копию. Во многих из этих случаев ваша база данных использует модель восстановления FULL или BULK_LOGGED, но вы не выполняли резервное копирование журналов транзакций. Вам следует внимательно рассмотреть каждую модель восстановления базы данных: выполнить резервное копирование журналов транзакций для всех баз данных в моделях восстановления ПОЛНЫЙ или БОЛЬШОЙ ЗАПИСЬ, чтобы свести к минимуму возникновение ошибки 9002.Для получения дополнительной информации см. Модели восстановления.
Резервное копирование журнала
При модели восстановления FULL или BULK_LOGGED, если для журнала транзакций не выполнялось резервное копирование в последнее время, резервное копирование может быть тем, что препятствует усечению журнала. Вы должны создать резервную копию журнала транзакций, чтобы разрешить освобождение записей журнала и усечение журнала. Если для журнала никогда не выполнялось резервное копирование, необходимо создать две резервные копии журнала , чтобы компонент Database Engine усекал журнал до точки последнего резервного копирования.Усечение журнала освобождает логическое пространство для новых записей журнала. Чтобы журнал не заполнялся снова, делайте резервные копии журналов регулярно и чаще. Для получения дополнительной информации см. Модели восстановления.
Полная история всех операций резервного копирования и восстановления SQL Server на экземпляре сервера хранится в системной базе данных msdb . Чтобы просмотреть полную историю резервного копирования базы данных, используйте следующий пример сценария:
ВЫБРАТЬ bs.database_name , backuptype = CASE КОГДА bs.type = 'D' и bs.is_copy_only = 0 ТОГДА 'Полная база данных' КОГДА bs.type = 'D' и bs.is_copy_only = 1 ТОГДА 'База данных только для полного копирования' КОГДА bs.type = 'I' ТОГДА 'Дифференциальное резервное копирование базы данных' КОГДА bs.type = 'L' ТОГДА 'Журнал транзакций' КОГДА bs.type = 'F' ТОГДА 'Файл или файловая группа' КОГДА bs.type = 'G' ТОГДА 'Дифференциальный файл' КОГДА bs.type = 'P' ТОГДА 'Частично' КОГДА bs.type = 'Q' ТОГДА 'Частичный дифференциал' КОНЕЦ + 'Резервное копирование' , bs.recovery_model , BackupStartDate = bs.Backup_Start_Date , BackupFinishDate = bs.Backup_Finish_Date , LatestBackupLocation = bf.physical_device_name , резервный_размер_мб = bs.backup_size / 1024. / 1024. , compressed_backup_size_mb = bs.compressed_backup_size / 1024. / 1024. , database_backup_lsn - для tlog и дифференциальных резервных копий это checkpoint_lsn ПОЛНОЙ резервной копии, на которой она основана. , checkpoint_lsn , начинается_log_chain ИЗ msdb.dbo.backupset bs ЛЕВОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ msdb.dbo.backupmediafamily bf ON bs. [Media_set_id] = bf. [Media_set_id] ГДЕ recovery_model в ('FULL', 'BULK-LOGGED') И бс.backup_start_date> DATEADD (month, -2, sysdatetime ()) - смотреть только за последние два месяца ЗАКАЗАТЬ bs.database_name asc, bs.Backup_Start_Date desc;
Полная история всех операций резервного копирования и восстановления SQL Server на экземпляре сервера хранится в системной базе данных msdb . Дополнительные сведения об истории резервного копирования см. В разделе История резервного копирования и информация заголовка (SQL Server).
Создать резервную копию журнала транзакций
Пример резервного копирования журнала:
РЕЗЕРВНЫЙ ЖУРНАЛ [dbname] TO DISK = 'some_volume: \ some_folder \ dbname_LOG.trn '
ACTIVE_TRANSACTION log_reuse_wait
Действия по устранению причины ACTIVE_TRANSACTION включают в себя обнаружение длительной транзакции и ее разрешение (в некоторых случаях для этого используется команда KILL).
Обнаружение длительных транзакций
Очень длительная транзакция может привести к заполнению журнала транзакций. Для поиска длительных транзакций используйте одно из следующего:
Это динамическое административное представление возвращает информацию о транзакциях на уровне базы данных.Для долго выполняющейся транзакции столбцы, представляющие особый интерес, включают время первой записи журнала (database_transaction_begin_time), текущее состояние транзакции (database_transaction_state) и порядковый номер журнала (LSN) начальной записи в журнале транзакций ( database_transaction_begin_lsn).
DBCC OPENTRAN. Этот оператор позволяет идентифицировать идентификатор пользователя владельца транзакции, поэтому вы потенциально можете отследить источник транзакции для более упорядоченного завершения (фиксации, а не отката).
Завершить транзакцию
Иногда нужно просто завершить транзакцию; возможно, вам придется использовать оператор KILL. Пожалуйста, используйте этот оператор очень осторожно, особенно когда запущены критические процессы, которые вы не хотите убивать. Дополнительные сведения см. В разделе KILL (Transact-SQL)
.
AVAILABILITY_REPLICA log_reuse_wait
Если изменения транзакций в первичной реплике доступности еще не закреплены на вторичной реплике, журнал транзакций первичной реплики не может быть усечен.Это может привести к увеличению журнала и может произойти независимо от того, настроена ли вторичная реплика для синхронного или асинхронного режима фиксации. Для получения информации о том, как устранить этот тип проблемы, см. Ошибка 9002. Журнал транзакций для базы данных переполнен из-за ошибки AVAILABILITY_REPLICA
.
КОНТРОЛЬНАЯ ТОЧКА log_reuse_wait
С момента последнего усечения журнала контрольная точка не возникла, или заголовок журнала еще не переместился за пределы виртуального файла журнала (VLF). (Все модели рекавери)
Это обычная причина задержки усечения журнала.В случае задержки рассмотрите возможность выполнения команды CHECKPOINT в базе данных или изучения VLF-файлов журнала.
ИСПОЛЬЗОВАТЬ dbname; КОНТРОЛЬНО-ПРОПУСКНОЙ ПУНКТ выберите * из sys.dm_db_log_info (db_id ('dbname'))
Для получения дополнительной информации о коэффициентах log_reuse_wait
Дополнительные сведения см. В разделе «Факторы, которые могут задержать усечение журнала».
2. Разрешить полный объем диска
В некоторых ситуациях дисковый том, на котором размещен файл журнала транзакций, может заполняться. Вы можете выполнить одно из следующих действий, чтобы разрешить сценарий переполнения журнала, который возникает из-за переполнения диска:
Свободное место на диске
Вы можете освободить место на диске, содержащем файл журнала транзакций для базы данных, удалив или переместив другие файлы.Освободившееся дисковое пространство позволяет системе восстановления автоматически увеличивать размер файла журнала.
Перенести файл журнала на другой диск
Если вы не можете освободить достаточно места на диске, который в настоящее время содержит файл журнала, подумайте о перемещении файла на другой диск с достаточным пространством.
Важно
Файлы журнала никогда не следует помещать в сжатые файловые системы.
См. Перемещение файлов базы данных для получения информации о том, как изменить расположение файла журнала.
Добавить файл журнала на другой диск
Добавьте новый файл журнала в базу данных на другом диске, на котором достаточно места, используя ALTER DATABASE ADD LOG FILE . Наличие нескольких файлов журнала для одной базы данных следует рассматривать как временное условие для решения проблемы с пространством, а не как долгосрочное условие. В большинстве баз данных должен быть только один файл журнала транзакций. Продолжайте исследовать причину, по которой журнал транзакций переполнен и не может быть усечен.Рассмотрите возможность добавления временных дополнительных файлов журнала транзакций в качестве расширенного шага по устранению неполадок.
Для получения дополнительной информации см. Добавление файлов данных или журналов в базу данных.
Служебный скрипт рекомендуемых действий
Эти шаги можно частично автоматизировать, запустив этот сценарий T-SQL, который определит файлы журналов, которые используют большой процент дискового пространства, и предложит действия:
ОБЪЯВИТЬ @log_reached_disk_size BIT = 0 ВЫБРАТЬ имя LogName, физическое_имя, ПРЕОБРАЗОВАТЬ (bigint, size) * 8/1024 LogFile_Size_MB, volume_mount_point, available_bytes / 1024/1024 Доступное_пространство_диска_МБ, (ПРЕОБРАЗОВАТЬ (bigint, размер) * 8.0/1024) / (available_bytes / 1024/1024) * 100 file_size_as_percentage_of_disk_space, db_name (mf.database_id) DbName FROM sys.master_files mf CROSS APPLY sys.dm_os_volume_stats (mf.database_id, file_id) ГДЕ mf. [Type_desc] = 'LOG' И (ПРЕОБРАЗОВАТЬ (bigint, size) * 8.0 / 1024) / (available_bytes / 1024/1024) * 100> 90 --log - это 90% диска ЗАКАЗАТЬ ПО РАЗМЕРУ УДАЛ. если @@ ROWCOUNT> 0 НАЧИНАТЬ установить @log_reached_disk_size = 1 - Обнаружение, если какие-либо журналы близки или полностью заполнены дисковым томом, на котором они находятся.- Либо добавить новый файл на новый диск, либо сжать существующий файл - Если не удается сжать, перейдите к разделу «Невозможно усечь» ЗАЯВИТЬ @db_name_filled_disk sysname, @log_name_filled_disk sysname, @go_beyond_size bigint ОБЪЯВЛЕНИЕ КУРСОРА log_filled_disk ДЛЯ ВЫБРАТЬ db_name (mf.database_id), имя FROM sys.master_files mf CROSS APPLY sys.dm_os_volume_stats (mf.database_id, file_id) ГДЕ mf. [Type_desc] = 'LOG' И (преобразовать (bigint, size) * 8.0/1024) / (available_bytes / 1024/1024) * 100> 90 --log - это 90% диска ЗАКАЗАТЬ ПО размеру по убыванию ОТКРЫТЬ log_filled_disk ПОЛУЧИТЬ СЛЕДУЮЩИЙ ИЗ log_filled_disk в @db_name_filled_disk, @log_name_filled_disk ПОКА @@ FETCH_STATUS = 0 НАЧИНАТЬ SELECT 'Журнал транзакций для базы данных "' + @db_name_filled_disk + '" почти или полностью заполнен дисковый том, на котором он находится!' Как находка SELECT 'Рассмотрите возможность использования одной из следующих команд, чтобы уменьшить размер файла журнала транзакций "' + @log_name_filled_disk + '" или добавить новый файл в НОВЫЙ том' AS Рекомендация ВЫБЕРИТЕ 'DBCC SHRINKFILE (' '' + @log_name_filled_disk + '' ')' AS Shrinkfile_Command ВЫБЕРИТЕ 'ALTER DATABASE' + @db_name_filled_disk + 'ADD LOG FILE (NAME = N' '' + @log_name_filled_disk + '_new' ', FILENAME = N''NEW_VOLUME_AND_FOLDER_LOCATION \' + @log_name_filled_disk.LDF '', SIZE = 81920KB, FILEGROWTH = 65536KB) 'AS AddNewFile SELECT 'Если сжатие не приводит к уменьшению размера файла, вероятно, это связано с тем, что он не был усечен. Пожалуйста, просмотрите следующий раздел ниже. См. Https://docs.microsoft.com/sql/t-sql/database-console-commands/dbcc-shrinkfile-transact-sql 'AS TruncateFirst ВЫБЕРИТЕ 'Можете ли вы освободить место на этом томе? Если да, сделайте это, чтобы журнал продолжал расти, когда это необходимо ». Как FreeDiskSpace ПОЛУЧИТЬ СЛЕДУЮЩИЙ ИЗ log_filled_disk в @db_name_filled_disk, @log_name_filled_disk КОНЕЦ ЗАКРЫТЬ log_filled_disk DEALLOCATE log_filled_disk КОНЕЦ
3.Измените ограничение размера журнала или включите Autogrow
Ошибка 9002 может быть сгенерирована, если размер журнала транзакций был установлен на верхний предел или автоматический рост не разрешен. В этом случае включение автоматического увеличения или увеличение размера журнала вручную может помочь решить проблему. Используйте эту команду T-SQL, чтобы найти такие файлы журналов, и следуйте предоставленным рекомендациям:
ВЫБРАТЬ DB_NAME (database_id) DbName, имя LogName, физическое_имя, type_desc, ПРЕОБРАЗОВАТЬ (bigint, SIZE) * 8/1024 LogFile_Size_MB, ПРЕОБРАЗОВАТЬ (bigint, max_size) * 8/1024 LogFile_MaxSize_MB, (РАЗМЕР * 8.0/1024) / (максимальный_размер * 8,0 / 1024) * 100 процентов_полного_макс_размера, СЛУЧАЙ, КОГДА рост = 0 ТОГДА 'AUTOGROW_DISABLED' ELSE 'Autogrow_Enabled' END как AutoGrow ИЗ sys.master_files ГДЕ file_id = 2 И (РАЗМЕР * 8,0 / 1024) / (макс_размер * 8,0 / 1024) * 100> 90 И max_size не в (-1, 268435456) ИЛИ рост = 0 если @@ ROWCOUNT> 0 НАЧИНАТЬ ЗАЯВИТЬ @db_name_max_size sysname, @log_name_max_size sysname, @configured_max_log_boundary bigint, @auto_grow int ОБЪЯВИТЬ КУРСОР ВЫБЕРИТЕ db_name (database_id), имя, ПРЕОБРАЗОВАТЬ (bigint, РАЗМЕР) * 8/1024, рост ОТ sys.master_files ГДЕ file_id = 2 И ((РАЗМЕР * 8,0 / 1024) / (макс_размер * 8,0 / 1024) * 100> 90 И max_size не в (-1, 268435456) ИЛИ рост = 0) ОТКРЫТЬ достигнуто_макс_размер ВЫБРАТЬ СЛЕДУЮЩИЙ ИЗ достигнутое_макс_размер в @ имя_бд_макс_размер, @ имя_журнала_max_size, @configured_max_log_boundary, @auto_grow ПОКА @@ FETCH_STATUS = 0 НАЧИНАТЬ ЕСЛИ @auto_grow = 0 НАЧИНАТЬ ВЫБЕРИТЕ 'База данных "' + @ db_name_max_size + '" содержит файл журнала "' + @log_name_max_size + '", автоматическое увеличение которого было ОТКЛЮЧЕНО' как поиск SELECT 'Рассмотрите возможность включения автоматического увеличения или увеличения размера файла с помощью этих команд ALTER DATABASE' в качестве рекомендации ВЫБЕРИТЕ 'ALTER DATABASE' + @db_name_max_size + 'MODIFY FILE (NAME = N' '' + @log_name_max_size + '' ', FILEGROWTH = 65536KB)' как AutoGrowth КОНЕЦ ЕЩЕ НАЧИНАТЬ SELECT 'База данных «' + @ db_name_max_size + '» содержит файл журнала «' + @log_name_max_size + '», максимальный предел которого установлен в' + convert (varchar (24), @configured_max_log_boundary) + 'МБ, и этот предел был достигнут ! ' как находка SELECT 'Рассмотрите возможность использования одной из следующих команд ALTER DATABASE либо для изменения размера файла журнала, либо для добавления нового файла' в качестве рекомендации КОНЕЦ ВЫБЕРИТЕ 'ALTER DATABASE' + @db_name_max_size + 'MODIFY FILE (NAME = N' '' + @log_name_max_size + '' ', MAXSIZE = UNLIMITED)' как UnlimitedSize ВЫБЕРИТЕ 'ALTER DATABASE' + @db_name_max_size + 'ИЗМЕНИТЬ ФАЙЛ (NAME = N' '' + @log_name_max_size + '' ', MAXSIZE = something_larger_than_' + CONVERT (varchar (24), @configured_max_log_boundary) + 'MB) ВЫБЕРИТЕ 'ALTER DATABASE' + @db_name_max_size + 'ADD LOG FILE (NAME = N' '' + @log_name_max_size + '_new' ', FILENAME = N''SOME_FOLDER_LOCATION \' + @log_name_max_size + '_NEW.LDF '', SIZE = 81920KB, FILEGROWTH = 65536KB) 'как AddNewFile ВЫБРАТЬ СЛЕДУЮЩИЙ ИЗ достигнутое_макс_размер в @ имя_бд_макс_размер, @ имя_журнала_max_size, @configured_max_log_boundary, @auto_grow КОНЕЦ ЗАКРЫТЬ достигнуто_макс_размер DEALLOCATE достигнуто_макс_размер КОНЕЦ ЕЩЕ ВЫБЕРИТЕ 'Не найдено файлов с максимальным размером файла журнала' в качестве результатов
Увеличьте размер файла журнала или включите Autogrow
Если на диске журнала доступно место, вы можете увеличить размер файла журнала.Максимальный размер файлов журнала составляет два терабайта (ТБ) на файл журнала.
Если автоматическое увеличение отключено, база данных находится в оперативном режиме и на диске достаточно места, выполните одно из следующих действий:
Примечание
В любом случае, если достигнут текущий предел размера, увеличьте значение MAXSIZE.
См. Также
ALTER DATABASE (Transact-SQL)
Управление размером файла журнала транзакций
Резервное копирование журнала транзакций (SQL Server)
sp_add_log_file_recover_suspect_db (Transact-SQL)
MSSQLSERVER_9002
Как структура файла журнала может повлиять на время восстановления базы данных
— Microsoft Tech Community
Руководство для начинающих по журналам транзакций SQL Server
Что такое журнал транзакций?
Журнал транзакций — это файл — неотъемлемая часть каждой базы данных SQL Server.Он содержит записи журнала, созданные в процессе ведения журнала в базе данных SQL Server. Журнал транзакций является наиболее важным компонентом базы данных SQL Server, когда дело доходит до аварийного восстановления, однако он не должен быть поврежден. После каждого изменения базы данных — возникновения транзакции в журнал транзакций записывается запись журнала. Все изменения записываются последовательно
Что хранится в журнале транзакций SQL Server?
В журнале транзакций хранятся все транзакции, выполненные в базе данных SQL Server, за исключением тех, которые минимально регистрируются, например BULK IMPORT или SELECT INTO.Внутри он разделен на более мелкие части, называемые виртуальными файлами журнала (VLF). Когда один VLF становится полным, продолжайте запись в следующий доступный в журнале транзакций. Файл журнала транзакций может быть представлен в виде кольцевого файла. Когда ведение журнала достигает конца файла, оно начинается снова с начала, но только в том случае, если все требования были соблюдены, а неактивные части были усечены. Процесс усечения необходим, чтобы пометить все неактивные части, чтобы их можно было использовать снова и перезаписать
Запись журнала больше не требуется в журнале транзакций, если выполняются все следующие условия:
Сделка, частью которой он является, совершила
Все измененные страницы базы данных были записаны на диск контрольной точкой
Запись журнала не требуется для резервного копирования (полного, дифференциального или журнала)
Запись журнала не требуется для какой-либо функции, которая читает журнал (например, зеркального отображения или репликации базы данных) [1]
Логический журнал является активной частью журнала транзакций.Порядковый номер журнала (LSN) идентифицирует каждую транзакцию в журнале транзакций. MinLSN — это начальная точка самой старой активной транзакции в онлайн-журнале транзакций
Может ли база данных SQL Server работать без журнала транзакций?
Нет, это невозможно из-за конструкции SQL Server и соответствия ACID. ACID означает атомарность, последовательность, изоляцию и долговечность. Все транзакции должны соответствовать этим характеристикам:
Атомарная транзакция либо полностью завершена, либо вообще не начата
Транзакция обеспечивает согласованность в состоянии системы, гарантируя, что в конце любой транзакции система находится в допустимом состоянии
Когда транзакция выполняется в изоляции , кажется, что это единственное действие, которое система выполняет одновременно
Транзакция долговечна. означает, что после успешного завершения все изменения, внесенные в систему, становятся постоянными. [2]
Может ли одна база данных SQL Server иметь более одного журнала транзакций?
Да, это возможно, но рекомендуется только в определенных ситуациях.Добавление нескольких файлов журнала транзакций никоим образом не улучшит производительность базы данных SQL Server. Запись может происходить только в один файл одновременно, поэтому параллельные операции ввода-вывода невозможны
Рекомендуется иметь несколько файлов журнала транзакций, только если первый из них заполнен или на диске не хватает места. В любом случае эти проблемы должны быть решены раньше и решены путем создания резервных копий журнала транзакций и мониторинга доступного места на диске
.
Почему растет журнал транзакций SQL Server?
За каждой транзакцией следует запись в онлайн-журнал транзакций.Во время работы SQL Server журнал транзакций увеличивается, если в базу данных вносятся изменения, поэтому ведение журнала транзакций имеет решающее значение для правильной работы SQL Server.
В SQL Server доступны три модели восстановления, в зависимости от того, какая из них используется, рост журнала транзакций проявляется по-разному:
Простая модель восстановления — резервные копии журнала транзакций не поддерживаются. Процесс усечения автоматизирован, и пространство освобождается для повторного использования. Существует риск потери данных, поскольку обнаруживаются изменения с момента последней резервной копии базы данных.В простом восстановлении вероятность увеличения журнала транзакций невелика — только в определенных ситуациях, когда существует длительная транзакция или транзакция, которая создает много изменений
Модель восстановления с неполным протоколированием — резервные копии журналов транзакций поддерживаются и необходимы на регулярной основе. Автоматического процесса усечения журнала транзакций нет, резервные копии журнала транзакций необходимо делать регулярно, чтобы отмечать неиспользуемое пространство, доступное для перезаписи. Модель восстановления с неполным протоколированием сокращает использование пространства журнала транзакций за счет использования минимального протоколирования для большинства массовых операций
Модель полного восстановления — резервные копии журналов транзакций поддерживаются и необходимы на регулярной основе.В нормальных условиях риск потери данных отсутствует. Автоматического процесса усечения журнала транзакций нет, резервные копии журнала транзакций необходимо делать регулярно, чтобы отмечать неиспользуемое пространство, доступное для перезаписи. В режиме полного восстановления наибольшая вероятность увеличения журнала транзакций, потому что все транзакции регистрируются
Как вести журнал транзакций в SQL Server?
Ведение журнала транзакций — важная задача в администрировании SQL Server. Мониторинг рекомендуется ежедневно или даже чаще, если база данных SQL Server имеет большой объем трафика.Пространство журнала транзакций можно контролировать с помощью команды DBCC SQLPREF:
DBCC SQLPERF (ПРОБЕЛ);
ГО
Имя базы данных — имя базы данных для отображаемой статистики журнала
Размер журнала (МБ) — текущий размер журнала. Это значение всегда меньше объема, первоначально выделенного для пространства журнала, поскольку компонент Database Engine резервирует небольшой объем дискового пространства для внутренней информации заголовка
Используемое пространство журнала (%) — процентная доля файла журнала, в настоящее время занятая информацией журнала транзакций
Статус — Статус файла журнала.Всегда 0
[3]
Для журнала транзакций необходимо регулярно выполнять резервное копирование, чтобы избежать операции автоматического увеличения и заполнения файла журнала транзакций. Пространство в журнале транзакций можно усечь (очистить) с помощью SQL Server Management Studio, выбрав Журнал транзакций в качестве типа резервной копии, или через интерфейс командной строки, выполнив следующую команду:
РЕЗЕРВНЫЙ ЖУРНАЛ ACMEDB
НА ДИСК = ‘C: \ ACMEDB.РНН ‘
ГО
Это резервное пространство можно использовать повторно, и оно будет перезаписано новыми транзакциями. Некоторые операции нельзя совмещать, их нужно выполнять отдельно:
Нужны ли мне резервные копии журнала транзакций SQL Server?
Да, это один из самых важных ресурсов при аварийном восстановлении. Они не нужны (и доступны) только в том случае, если используется простая модель восстановления, но существует риск потери данных. Большинство администраторов баз данных используют 15-минутный интервал или даже меньше для баз данных SQL Server с высоким трафиком.Резервные копии журналов транзакций важны, потому что при их создании они отмечают неактивные VLF, которые могут использоваться для записи новых транзакций

Иван — специалист по SQL Server и компьютерный фанат с многолетним опытом работы в сфере ИТ и SQL Server. Он начал с компьютерных игр, продолжил программированием и системным администрированием. Он специализируется в области аварийного восстановления, аудита и соответствия SQL Server.
Просмотреть все сообщения Ивана Станковича
Последние сообщения Ивана Станковича (просмотреть все)
Операции резервного копирования, усечения и сжатия журнала транзакций SQL Server
В этой статье мы рассмотрим операции резервного копирования журнала транзакций SQL Server, операции усечения и сжатия с обзором и примерами, охватывающими все обсуждаемое.
Если эта статья является вашим первым посещением серии журналов транзакций SQL Server, я рекомендую вам ознакомиться с предыдущими статьями (см. Оглавление ниже), в которых мы описали внутреннюю структуру журнала транзакций SQL Server, важную роль, которую выполняет транзакция. Журнал играет в поддержании базы данных в согласованном состоянии и восстановлении поврежденной базы данных или ошибочно измененной таблицы до определенного момента времени.В этой серии мы также обсудили три модели восстановления: полное, простое и с неполным протоколированием, которые контролируют, как транзакции будут записываться в файл журнала транзакций SQL Server, и, наконец, как управлять ростом журнала транзакций SQL Server и контролировать его.
Основываясь на всей базовой информации из предыдущих статей, мы готовы подробно обсудить в этой статье разницу между концепциями резервного копирования, усечения и сжатия журнала транзакций SQL Server, а также способы выполнения этих операций.
Резервное копирование журнала транзакций
При настройке вашей базы данных с использованием простой модели восстановления журнал транзакций SQL Server будет помечен как неактивный и автоматически усечен после фиксации активной транзакции. Это не относится к моделям восстановления базы данных с полным и неполным протоколированием. Когда для базы данных настроена модель полного восстановления, журнал транзакций SQL Server в файле журнала транзакций будет помечен как неактивный после фиксации транзакции без автоматического усечения, так как это будет , ожидая выполнения резервного копирования журнала транзакций . .Напомним, что только резервная копия журнала транзакций, но НЕ полная резервная копия базы данных, будет усекать журналы транзакций из файла журнала транзакций и делать его доступным для повторного использования. Если из базы данных не берется резервная копия журнала транзакций, файл журнала транзакций будет постоянно увеличиваться без усечения, пока в нем не закончится свободное пространство.
Резервная копия журнала транзакций SQL Server может быть взята только из базы данных, если модель восстановления этой базы данных является полной или с неполным протоколированием.Модель восстановления базы данных можно проверить на вкладке Параметры окна Свойства базы данных, как показано ниже:
Если вы попытаетесь сделать резервную копию журнала транзакций для базы данных, для которой настроена модель простого восстановления, операция резервного копирования завершится сбоем с сообщением об ошибке ниже:
Кроме того, для резервного копирования журнала транзакций необходимо, чтобы из этой базы данных была взята по крайней мере одна полная резервная копия в качестве начальной точки для новой цепочки резервных копий.Если вы попытаетесь сделать резервную копию журнала транзакций из базы данных, в которой ранее не выполнялось полное резервное копирование, операция резервного копирования завершится сбоем с сообщением об ошибке ниже:
Давайте сделаем полную резервную копию базы данных, чтобы иметь возможность делать резервную копию журнала транзакций для этой базы данных. Мы будем использовать команду T-SQL BACKUP DATABASE для выполнения операции полного резервного копирования базы данных в нашем примере. Дополнительные сведения о различных способах и вариантах выполнения резервного копирования базы данных в SQL Server см. В серии «Резервное копирование и восстановление SQL Server».Полную резервную копию базы данных можно сделать с помощью сценария T-SQL ниже:
РЕЗЕРВНОЕ КОПИРОВАНИЕ БАЗЫ ДАННЫХ [TSQL]
НА ДИСК = N’C: \ Ahmad Yaseen \ TSQL.bak ‘WITH NOFORMAT, NOINIT,
NAME = N’TSQL-Full Backup Database’, SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10
GO
После того, как будет выполнено полное резервное копирование базы данных, мы начнем создавать резервные копии журнала транзакций для базы данных.Первая резервная копия журнала транзакций создаст резервную копию всех транзакций, произошедших в базе данных с момента последней полной резервной копии. Резервную копию журнала транзакций можно сделать с помощью команды T-SQL BACKUP LOG ниже:
РЕЗЕРВНЫЙ ЖУРНАЛ [TSQL]
НА ДИСК = N’C: \ Ahmad Yaseen \ TSQL_2.TRN ‘WITH NOFORMAT, NOINIT,
NAME = N’TSQL-TRN Backup Database’, SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10
GO
С другой стороны, резервные копии журнала транзакций, которые следует за , первая резервная копия журнала транзакций будет создавать резервные копии для всех транзакций, которые произошли в базе данных с момента остановки последнего резервного копирования журнала транзакций.Полная резервная копия и все последующие резервные копии журнала транзакций до создания новой полной резервной копии называются Backup Chain . Эта цепочка резервного копирования важна для восстановления базы данных до определенного момента времени в случае любого ошибочно выполненного изменения или повреждения базы данных. Частота резервного копирования журнала транзакций зависит от того, насколько важны ваши данные, размер базы данных и какой тип рабочей нагрузки эта база данных обслуживает. В базах данных с большим количеством транзакций рекомендуется увеличить частоту резервного копирования журнала транзакций, чтобы минимизировать потерю данных, и усечь журналы транзакций, чтобы сделать их доступными для повторного использования.
Если база данных повреждена, рекомендуется создать резервную копию хвостового журнала, чтобы вы могли восстановить базу данных на текущий момент времени. Резервное копирование хвостового журнала используется для сбора всех записей журнала, для которых еще не было выполнено резервное копирование. Это поможет предотвратить потерю данных и сохранить целостность цепочки журналов.
Предположим, что вы по ошибке выполнили приведенный ниже оператор DELETE, не указав предложение WHERE. Это означает, что все записи таблицы будут удалены:
Если вы разработали подходящее решение для резервного копирования, данные можно легко восстановить, восстановив базу данных до определенного момента времени перед выполнением оператора DELETE.В окне «Восстановить базу данных» SQL Server вернет полную цепочку резервных копий, взятую из этой базы данных. Если вы знаете точный файл, который берется непосредственно перед удалением данных, вы можете остановиться на этом конкретном файле, как показано ниже:
Но если вам известно точное время выполнения оператора DELETE, вы можете восстановить базу данных обратно в этот конкретный момент времени до выполнения оператора DELETE, без необходимости знать, какой файл журнала транзакций содержит этот момент времени.Этого можно добиться, щелкнув опцию Timeline и указав время, как показано ниже:
Усечение журнала транзакций
Усечение журнала транзакций SQL Server — это процесс, в котором все VLF, помеченные как неактивные, удаляются из файла журнала транзакций SQL Server и становятся доступными для повторного использования. Если есть одна активная запись журнала в VLF, общий VLF будет считаться активным журналом и не может быть усечен.
Журнал транзакций SQL Server для базы данных, настроенной с использованием модели восстановления Simple , может быть автоматически усечен, если:
Сработал оператор контрольной точки
Транзакция базы данных зафиксирована
Журнал транзакций SQL Server для базы данных, для которой настроена модель восстановления Full или Bulk-Logged , может быть усечен автоматически:
После выполнения процесса резервного копирования журнала транзакций, когда журнал транзакций не ожидает активной транзакции или какой-либо функции высокой доступности, такой как зеркалирование, репликация или группа доступности AlwaysOn
Измените модель восстановления базы данных на Simple
Например, если мы изменим модель восстановления указанной ниже базы данных на Простую и выполним контрольную точку напрямую, журнал транзакций будет автоматически усечен и будет доступен для повторного использования, как показано ниже:
TRUNCATE_ONLY Параметр резервного копирования журнала транзакций, который прерывает цепочку резервного копирования базы данных и усекает доступные журналы транзакций.(Доступно только до SQL Server 2008.)
Если вы попытаетесь усечь журнал транзакций базы данных с помощью параметра TRUNCATE_ONLY в экземпляре SQL Server версии 2008 и более поздних версий, выполнение инструкции завершится ошибкой с сообщением об ошибке ниже:
Уменьшение журнала транзакций
Когда файл журнала транзакций базы данных усекается, усеченное пространство освобождается и становится доступным для повторного использования.Но размер файла журнала транзакций не будет уменьшен, так как усеченное пространство не будет освобождено. С другой стороны, процесс восстановления пространства журнала транзакций путем освобождения свободных VLF и возврата их обратно в операционную систему называется сжатием журнала транзакций . операция.
Операция сжатия файла журнала транзакций может быть выполнена только при наличии свободного места в файле журнала транзакций, которое может быть доступно большую часть времени после усечения неактивной части журнала транзакций.Операция сжатия будет полезна после выполнения операции, которая создает большое количество журналов транзакций.
Файл журнала транзакций базы данных можно уменьшить, щелкнув базу данных правой кнопкой мыши и выбрав параметр «Сжать» -> «Файлы» в меню «Задачи», как показано ниже:
На странице «Сжать файл» измените Тип файла на Журнал и выберите файл журнала транзакций, который нужно сжать. На этой странице у вас есть три варианта:
Тот же файл журнала транзакций можно уменьшить с помощью инструкции DBCC SHRINKFILE T-SQL ниже:
ИСПОЛЬЗОВАТЬ [AdventureWorks2016CTP3]
GO
DBCC SHRINKFILE (N’AdventureWorks2016CTP3_Log ‘, 0, TRUNCATEONLY)
GO
Сжать файл журнала транзакций до размера, меньшего, чем размер виртуального файла журнала, невозможно, даже если это пространство не используется.Это связано с тем, что файл журнала транзакций можно сжать только до границы VLF. В этом случае ядро СУБД SQL Server освободит как можно больше места, а затем выдаст информационное сообщение, как показано ниже:
В следующей статье этой серии мы обсудим лучшие практики, которые следует применять к журналу транзакций, чтобы получить от него оптимальную производительность. Будьте на связи!
Содержание
Ахмад Ясин (Ahmad Yaseen) — инженер Microsoft по большим данным с глубокими знаниями и опытом в областях SQL BI, администрирования баз данных SQL Server и разработки.
Он является сертифицированным экспертом по решениям Microsoft в области управления данными и аналитикой, сертифицированным партнером по решениям Microsoft в области администрирования и разработки баз данных SQL, партнером разработчика Azure и сертифицированным инструктором Microsoft.
Кроме того, он публикует свои советы по SQL во многих блогах.
Посмотреть все сообщения от Ahmad Yaseen
Последние сообщения от Ahmad Yaseen (посмотреть все)
Журнал транзакций — обзор
MySQL
Журнал транзакций в MySQL не включен по умолчанию и должен быть включен для регистрации транзакций.Чтобы определить, активен ли журнал транзакций, вы можете использовать оператор «показать двоичные журналы»:
SHOW BINARY LOGS;
Если двоичное ведение журнала отключено, вы получите сообщение об ошибке «вы не используете двоичное ведение журнала». Если он включен, будут возвращены имена всех журналов, как показано ниже:
+ ——————————— + ———— +
| Log_name | File_size |
+ ——————————— + ————— +
| РЗ-ДЭВ-03-бин.000001 | 99362 |
| РЗ-ДЭВ-03-бин.000002 | 1699 |
| РЗ-ДЭВ-03-бин.000003 | 177 |
| РЗ-ДЭВ-03-бин.000004 | 177 |
| РЗ-ДЭВ-03-бин.000005 | 154 |
+ ——————————— + ————— +
Когда ведение журнала настроено, первые журналы транзакций MySQL будут иметь расширение *. 000001 и увеличиваются каждый раз, когда сервер перезагружается, журнал достигает заданного размера или сбрасывается. Чтобы определить, где хранятся журналы, вы можете использовать следующий запрос:
SHOW VARIABLES LIKE ‘% HOME%’;
Значение innodb_log_group_home_dir в результатах — это расположение файлов журнала.В следующих примерах результатов журналы хранятся в корневом каталоге MySQL (. \):
+ ——————————— + ———— +
| Имя_переменной | Значение |
+ ——————————— + ———— +
| innodb_data_home_dir | |
| innodb_log_group_home_dir | . \ |
+ ——————————— + ———— +
Чтобы вывести список транзакций из журнала транзакций, вы можете использовать встроенную утилиту MySQL mysqlbinlog на серверах, отличных от Windows, и команду MySQL линейный клиент в Windows.
В следующем примере запроса показано, как вернуть список всех транзакций, записанных в файле RZ-DEV-03-bin.000001.
mysqlbinlog ‘c: \ Program Files \ MySQL \ RZ-DEV-03-bin.000001’> z: \ transactionlog.txt.
Ниже приведены примеры результатов, которые показывают ранее выполненные операторы, записанные в файл журнала, в удобочитаемой форме
BEGIN
/ *! * /;
# at 4155
# 120114 0:30:34 идентификатор сервера 1 end_log_pos 4272 Запрос thread_id = 16 exec_time = 0 error_code = 0
use world / *! * /;
УСТАНОВИТЬ ВРЕМЯ = 1326519034 / *! * /;
обновить набор городов name = ‘Ashburn’, где name = ‘Kabul’
/ *! * /;
# at 4272
# 120114 0:30:34 идентификатор сервера 1 end_log_pos 4342 Query thread_id = 16 exec_time = 0 error_code = 0
SET TIMESTAMP = 1326519034 / *! * /;
COMMIT
/ *! * /;
# at 4342
# 120114 0:30:52 идентификатор сервера 1 end_log_pos 4411 запрос thread_id = 16 exec_time = 0 error_code = 0
SET TIMESTAMP = 1326519052 / *! * /;
НАЧАТЬ
/ *! * /;
# at 4411
# 120114 0:30:52 идентификатор сервера 1 end_log_pos 4514 Query thread_id = 16 exec_time = 0 error_code = 0
SET TIMESTAMP = 1326519052 / *! * /;
удалить из города, где name = ‘Ashburn’
/ *! * /;
# at 4514
# 120114 0:30:52 идентификатор сервера 1 end_log_pos 4584 Query thread_id = 16 exec_time = 0 error_code = 0
SET TIMESTAMP = 1326519052 / *! * /;
COMMIT
/ *! * /;
РАЗДЕЛИТЕЛЬ;
# Конец файла журнала
ROLLBACK / * добавлено mysqlbinlog * /;
/ *! 50003 SET [электронная почта защищена] _COMPLETION_TYPE * /;
Журнал транзакций — Академия резервного копирования Sql Server
Журнал транзакций является важной частью каждой базы данных, в которой записываются все транзакции и изменения базы данных, сделанные каждой транзакцией.Журнал транзакций предназначен для записи всех изменений, внесенных в базу данных. Рассмотрим пример с рисунка ниже:
Пользователь вносит некоторые изменения в базу данных.
Этот запрос выполняется, и эта операция немедленно записывается в журнал транзакций.
При сохранении записи запрос возвращается пользователю. А как насчет записи в файле данных?
Файл данных позже обновляется во время контрольной точки. Это работает так, потому что файл данных может нуждаться в расширении, чтобы приспособиться к изменениям.
Еще одна вещь, о которой следует упомянуть, — это то, что база данных может иметь один или несколько файлов журнала транзакций. Использование двух или более журналов транзакций не ускорит работу вашей базы данных, потому что запись может происходить только в один файл за раз, а это означает, что параллельные операции ввода-вывода невозможны. Сценарий, при котором рекомендуется несколько файлов журнала транзакций, — это когда первый из них больше не может расти.
Файлы виртуального журнала
В журнале транзакций хранятся все транзакции, сделанные в базе данных, кроме тех, которые минимально регистрируются (например, SELECT INTO или BULK IMPORT).Каждая запись журнала транзакций имеет свой собственный уникальный номер, называемый порядковым номером журнала (LSN), и хранится в виртуальном файле журнала транзакций (VLF), размер которого не фиксирован. Журнал транзакций может иметь любое количество файлов виртуального журнала:
Усечение журнала транзакций
Файл журнала будет увеличиваться до тех пор, пока не заполнит все свободное пространство на диске, на котором он расположен, если записи журнала не будут удалены. Со временем старые записи журнала становятся ненужными для процесса восстановления, поэтому их необходимо удалить, чтобы освободить место для новых записей журнала.Такой процесс в SQL Server, когда все ненужные записи удаляются для уменьшения размера файла журнала, называется усечением журнала транзакций .
То, как происходит это усечение, зависит от модели восстановления, выбранной для вашей базы данных.
Модель простого восстановления
Журнал транзакций усекается при возникновении контрольной точки. В это время все зафиксированные транзакции записываются в файл данных, и файлы виртуального журнала можно использовать повторно. Посмотрите на картинку ниже:
После срабатывания контрольной точки файлы виртуального журнала 1 и 2 больше не используются, поскольку транзакция 11 и 12 была зафиксирована.SQL Server помечает виртуальный файл журнала 1 и 2 как повторно используемый. Такой процесс называется усечением журнала транзакций. Все зафиксированные транзакции были усечены, но физический размер журнала транзакций остался прежним. Если необходимо уменьшить размер файла журнала транзакций, включите параметр AUTO_SHRINK, и он будет физически сжимать файл журнала (где это возможно) через определенные промежутки времени:
ALTER DATABASE your_database SET AUTO_SHRINK ON ALTER DATABASE your_database SET AUTO_SHRINK OFF
Чтобы настроить автоматическое сжатие с помощью SSMS, щелкните правой кнопкой мыши базу данных, для которой вы хотите настроить автоматическое сжатие журнала транзакций, выберите «Свойства», затем «Параметры».Выберите «Auto Shrink» и переключитесь с «False» на «True», а затем нажмите «OK».
Итак, после того, как транзакция была зафиксирована, SQL Server может повторно использовать пространство. Но будьте осторожны с этой опцией, так как нет возможности контролировать запуск автоматического сжатия. Кроме того, такие операции, при которых файл растет, затем сжимается, затем снова увеличивается и снова сжимается, требуют больше ресурсов.
Модели восстановления с полным или неполным протоколированием
В этом случае журнал транзакций усекается только во время резервного копирования журнала транзакций.В модели восстановления с полным или неполным протоколированием, когда возникает контрольная точка, все грязные страницы записываются на диск, но SQL Server не помечает какие-либо файлы виртуального журнала как повторно используемые. Журнал транзакций будет усечен только после завершения резервного копирования журнала транзакций:
РЕЗЕРВНЫЙ ЖУРНАЛ your_database TO DISK = 'log.bak'
Помните, что если база данных работает по модели полного восстановления или восстановления с неполным протоколированием, а полная резервная копия никогда не создавалась, журнал транзакций будет усечен на каждой контрольной точке.
Ведение журнала транзакций
Как упоминалось выше, журнал транзакций автоматически усекается при простой модели восстановления, но как вы можете управлять журналом транзакций, если в базе данных используется модель восстановления с полным или неполным протоколированием? Это достигается за счет регулярного резервного копирования журналов транзакций.
Кроме того, рекомендуется следить за пространством журнала транзакций. Используйте следующую команду:
DBCC SQLPERF (ПРОБЕЛ)
Это возвращает следующую таблицу:
Database Name — имя базы данных
Размер журнала (МБ) — текущий размер журнала транзакций
Используемое пространство журнала (%) — показывает, какой процент занятого места в журнале транзакций в файле журнала
Статус — статус файла журнала (всегда «0»)
Еще одна полезная команда, которая может помочь узнать, сколько виртуальных журналов находится в файле журнала транзакций, который используется в данный момент:
DBCC LOGINFO
FileId — показывает, в каком физическом файле хранится VLF.
FileSize — размер файла журнала транзакций (в байтах).
StartOffset — используется как столбец сортировки для вывода. Обратите внимание, что размер первого VLF всегда составляет 8192 байта.
FSeqNo (порядковый номер файла) — указывает порядок использования VLF. VLF с наивысшим номером FSeqNo — это VLF, в который записываются текущие записи журнала.
Статус — есть два возможных значения: 0 и 2. VLF с 0 указывает, что его можно использовать повторно, VLF со значением 2 указывает, что его нельзя использовать повторно.
Четность — имеет два значения: 64 и 128. Он переключается каждый раз при повторном использовании VLF.
CreateLSN — указывает, когда VLF был создан. Если значение равно 0, это означает, что VLF был создан при создании базы данных. Если у VLF одинаковое значение, это означает, что они были созданы одновременно.

{{#if (eqw this. forbidden true)}} {{> productAddToCartForbiddenTemplate}} {{else}} {{#if (and (neqw this.stock null) (neqw (uppercase this.stock.stockLevelStatus.code) «OUTOFSTOCK») (neqw this.price null))}} {{else}} Товар недоступен {{/if}} {{/if}} Арт. {{this.code}} {{#if this.stock}} {{#if (neqw this.stock.stockStatusText null)}} {{{ this.stock.stockStatusText }}} {{else}} {{#if (eqw (uppercase this.stock.stockLevelStatus.code) «ONREQUEST»)}} Под заказ {{else}} {{#if (neqw (uppercase this.stock.stockLevelStatus.code) «OUTOFSTOCK»)}} В наличии {{else}} Нет в наличии {{/if}} {{/if}} {{/if}} {{/if}} {{/each}} {{#each fields}}
{{@key}}	{{this}}
Торговая марка	{{#if (neqw this. trademark null)}} {{this.trademark.name}} {{/if}}
Рейтинг	{{#if (eqw this.ratingWidth null)}} {{this.averageRating}}{{#if (eqw this.averageRating null)}}0{{/if}}
{{#unless eaistPopup}} Отсутствующий товар: {{/unless}}	Выберите товары для замены:
{{#if (gt @index 0)}} {{/if}} {{#if (eqw this. forbidden true)}} {{> productAddToCartForbiddenTemplate}} {{else}} {{#if (and (neqw this.stock null) (neqw (uppercase this.stock.stockLevelStatus.code) «OUTOFSTOCK») (neqw this.price null))}} {{else}} Товар недоступен {{/if}} {{/if}} Арт. {{this.code}} {{#if this.stock}} {{#if (neqw this.stock.stockStatusText null)}} {{{ this.stock.stockStatusText }}} {{else}} {{#if (eqw (uppercase this.stock.stockLevelStatus.code) «ONREQUEST»)}} Под заказ {{else}} {{#if (neqw (uppercase this.stock.stockLevelStatus.code) «OUTOFSTOCK»)}} В наличии {{else}} Нет в наличии {{/if}} {{/if}} {{/if}} {{/if}} {{/each}}
{{@key}}	{{this}}
Торговая марка	{{#if (neqw this. trademark null)}} {{this.trademark.name}} {{/if}}
Рейтинг	{{#if (eqw this.ratingWidth null)}} {{this.averageRating}}{{#if (eqw this.averageRating null)}}0{{/if}}

Подробные характеристики
Сфера применения:	в медицинских учреждениях

значение log_reuse_wait	значение log_reuse_wait_desc	Описание
0	НИЧЕГО	В настоящее время существует один или несколько повторно используемых файлов виртуального журнала (VLF).
1	КОНТРОЛЬНАЯ ТОЧКА	С момента последнего усечения журнала контрольная точка не возникла, или заголовок журнала еще не переместился за пределы виртуального файла журнала (VLF). (Все модели восстановления) Это обычная причина задержки усечения журнала. Дополнительные сведения см. В разделе Контрольные точки базы данных (SQL Server).
2	LOG_BACKUP	Перед усечением журнала транзакций требуется резервная копия журнала. (Только для моделей восстановления с полным или неполным протоколированием) По завершении следующего резервного копирования журнала часть пространства журнала может стать повторно используемым.
3	ACTIVE_BACKUP_OR_RESTORE	Выполняется резервное копирование или восстановление данных (все модели восстановления). Если резервное копирование данных предотвращает усечение журнала, отмена операции резервного копирования может помочь решить немедленную проблему.
4	АКТИВНОЕ ПЕРЕДАЧА	Транзакция активна (все модели восстановления): Длительная транзакция могла существовать в начале резервного копирования журнала. В этом случае для освобождения места может потребоваться еще одна резервная копия журнала.Обратите внимание, что длительные транзакции предотвращают усечение журнала во всех моделях восстановления, включая простую модель восстановления, при которой журнал транзакций обычно усекается на каждой автоматической контрольной точке. Транзакция отложена. Отложенная транзакция фактически является активной транзакцией, откат которой заблокирован из-за недоступности ресурса. Для получения информации о причинах отложенных транзакций и о том, как вывести их из отложенного состояния, см. Отложенные транзакции (SQL Server). Длительные транзакции также могут заполнить журнал транзакций tempdb. Tempdb неявно используется пользовательскими транзакциями для внутренних объектов, таких как рабочие таблицы для сортировки, рабочие файлы для хеширования, рабочие таблицы курсора и управление версиями строк. Даже если пользовательская транзакция включает в себя только чтение данных ( `SELECT` запросов), внутренние объекты могут быть созданы и использованы в пользовательских транзакциях. После этого можно заполнить журнал транзакций tempdb.
5	БАЗА ДАННЫХ_ЗЕРКАЛЬНОЕ ЗЕРКАЛО	Зеркальное отображение базы данных приостановлено или в режиме высокой производительности зеркальная база данных значительно отстает от основной базы данных.(Только для модели полного восстановления) Дополнительные сведения см. В разделе «Зеркальное отображение базы данных (SQL Server)».
6	РЕПЛИКАЦИЯ	Во время репликации транзакций транзакции, относящиеся к публикациям, все еще не доставляются в базу данных распространителя. (Только для модели полного восстановления) Для получения информации о репликации транзакций см. Репликация SQL Server.
7	DATABASE_SNAPSHOT_CREATION	Создается моментальный снимок базы данных.(Все модели восстановления) Это стандартная и обычно кратковременная причина отложенного усечения журнала.
8	LOG_SCAN	Происходит сканирование журнала. (Все модели восстановления) Это стандартная и обычно кратковременная причина отложенного усечения журнала.
9	AVAILABILITY_REPLICA	Вторичная реплика группы доступности применяет записи журнала транзакций этой базы данных к соответствующей вторичной базе данных.(Модель полного восстановления) Дополнительные сведения см. В разделе Обзор групп доступности AlwaysOn (SQL Server).
10	–	Только для внутреннего использования
11	–	Только для внутреннего использования
12	–	Только для внутреннего использования
13	СТАРАЯ СТРАНИЦА	Если база данных настроена на использование косвенных контрольных точек, самая старая страница в базе данных может быть старше, чем порядковый номер журнала контрольной точки (LSN).В этом случае самая старая страница может задерживать усечение журнала. (Все модели восстановления) Для получения информации о косвенных контрольных точках см. Контрольные точки базы данных (SQL Server).
14	ДРУГОЙ_ПЕРЕВОД	Это значение в настоящее время не используется.
16	XTP_CHECKPOINT	Необходимо выполнить контрольную точку OLTP в памяти. Для таблиц, оптимизированных для памяти, автоматическая контрольная точка берется, когда файл журнала транзакций становится больше 1.5 ГБ с момента последней контрольной точки (включает как дисковые, так и оптимизированные для памяти таблицы) Дополнительные сведения см. В разделах «Операция контрольной точки для таблиц, оптимизированных для памяти» и [Процесс ведения журнала и контрольной точки для таблиц, оптимизированных для памяти] (https: // blogs. msdn.microsoft.com/sqlcat/2016/05/20/logging-and-checkpoint-process-for-memory-optimized-tables-2/)