Это интересно
- ОКД
- ЗКС
- ИПО
- КНПВ
- Мондиоринг
- Большой ринг
- Французский ринг
- Аджилити
- Фризби
Опрос
Полезные ссылки
РКФ
Все о дрессировке собак
Стрижка собак в Коломне
Поиск по сайту
Устранение неполадок при переполнении журнала транзакций (ошибка 9002). Windows журнал транзакций
Общие сведения о журналах транзакций
Эта документация перемещена в архив и не поддерживается.
Каждая база данных SQL Server 2005 имеет журнал транзакций, в котором фиксируются все изменения данных, произведенные в каждой транзакции. Журнал транзакций является критическим компонентом базы данных и в случае системного сбоя может потребоваться для приведения базы данных в согласованное состояние. Журнал транзакций нельзя ни удалять, ни изменять, если только не известны возможные последствия.
Журнал транзакций поддерживает следующие операции:
восстановление отдельных транзакций;
восстановление всех незавершенных транзакций при запуске SQL Server;
накат восстановленной базы данных, файла, файловой группы или страницы до момента сбоя;
поддержка репликации транзакций;
поддержка решений с резервными серверами.
Восстановление отдельных транзакций
Если приложение выполняет инструкцию ROLLBACK или если компонент Database Engine обнаруживает ошибку, такую как потеря связи с клиентом, записи журнала используются для отката изменений, сделанных незавершенной транзакцией.
Восстановление всех незавершенных транзакций при запуске SQL Server
Если на сервере, где работает SQL Server, происходит сбой, базы данных могут остаться в таком состоянии, в котором часть изменений не была переписана из буферного кэша в файлы данных, и могут быть изменения в файлах данных, совершенные незаконченными транзакциями. Когда экземпляр SQL Server будет запущен, он выполнит восстановление каждой базы данных. Будет выполнен накат каждого записанного в журнал изменения, которое, возможно, не было переписано в файл данных. Чтобы сохранить целостность базы данных, будет также произведен откат каждой незавершенной транзакции, найденной в журнале транзакций.
Откат восстановленной базы данных, файла, файловой группы или страницы на момент до возникновения сбоя
После потери оборудования или сбоя диска, затрагивающего файлы базы данных, можно восстановить базу данных на момент, предшествующий сбою. Сначала восстановите последнюю полную резервную копию и последнюю дифференциальную резервную копию базы данных, затем восстановите последующую серию резервных копий журнала транзакций до момента возникновения сбоя. Поскольку восстанавливается каждая резервная копия журнала, компонент Database Engine повторно применяет все модификации, записанные в журнале, для наката всех транзакций. Когда последняя резервная копия журнала будет восстановлена, тогда компонент Database Engine начнет использовать данные журнала для отката всех транзакций, которые не были завершены на момент сбоя.
Поддержка репликации транзакций
Агент чтения журнала следит за журналами транзакций всех баз данных, которые настроены для репликации транзакций, и копирует отмеченные для репликации транзакции из журнала транзакций в базу данных распространителя. Дополнительные сведения см. в разделе Как работает репликация транзакций.
Поддержка решений с резервными серверами
В сценарии зеркального отражения базы данных каждое обновление в базе данных, основной базе данных, будет немедленно воспроизведено в отдельной полной копии базы данных, зеркальной базе данных. Экземпляр основного сервера немедленно отсылает каждую запись журнала на экземпляр зеркального сервера, который применяет поступающие записи журнала к зеркальной базе данных, путем ее непрерывного наката. Дополнительные сведения см. в разделе Обзор зеркального отображения базы данных.
Далее следуют характеристики журнала транзакций SQL Server Database Engine.
Журнал транзакций выполнен как отдельный файл или набор файлов в базе данных. Кэш журнала управляется отдельно от буферного кэша для страниц данных, что приводит к простому, быстрому и устойчивому коду в пределах компонента Database Engine.
Формат записей журнала и страниц не обязан следовать формату страниц данных.
Журнал транзакций может располагаться в нескольких файлах. В определении этих файлов с помощью установки значения FILEGROWTH для журнала может быть предусмотрена возможность автоматического расширения. Это снижает вероятность исчерпания пространства журнала транзакций, в то же самое время уменьшая административные издержки. Дополнительные сведения см. в разделе ALTER DATABASE (Transact-SQL).
Механизм многократного использования пространства в файлах журналов действует быстро и оказывает минимальное влияние на пропускную способность транзакций.
Справочник
Основные понятия
Другие ресурсы
technet.microsoft.com
Физическая архитектура журнала транзакций
Журнал транзакций используется для обеспечения целостности данных в базе данных и восстановления данных. В этом подразделе приводятся сведения о физической структуре журнала транзакций. Понимание физической архитектуры может помочь в повышении эффективности работы с журналами транзакций.
Журнал транзакций в базе данных сопоставляет один или несколько физических файлов. По сути, файл журнала представляет собой строку записей журнала. Физически последовательность записей журнала эффективно хранится в наборе физических файлов, которые образуют журнал транзакций.
Компонент SQL Server Database Engine делит каждый физический файл журнала на несколько виртуальных файлов журнала. Виртуальные файлы журнала не имеют фиксированных размеров. Не существует также и определенного числа виртуальных файлов журнала, приходящихся на один физический файл журнала. Компонент Database Engine динамически определяет размер виртуальных файлов журнала при создании или расширении файлов журнала. Компонент Database Engine стремится обслуживать небольшое число виртуальных файлов. После расширения файла журнала размер виртуальных файлов определяется как сумма размера существующего журнала и размера нового приращения файла. Администраторы не могут настраивать или устанавливать размеры и число виртуальных файлов журнала.
Виртуальные файлы журнала влияют на производительность системы лишь в том случае, если эти файлы журнала определяются малыми значениями size и growth_increment. Если эти файлы журнала в результате большого числа малых приращений будут разрастаться до крупных размеров, они будут иметь множество виртуальных файлов журнала. В итоге может увеличиться время запуска базы данных, а также снизиться скорость операций резервного копирования и восстановления. Рекомендуется выбирать для файлов журнала значение параметра size, близкое к окончательному требуемому размеру, а также задавать относительно большое значение growth_increment.
Журнал транзакций является оборачиваемым файлом. Рассмотрим пример. Пусть база данных имеет один физический файл журнала, разделенный на четыре виртуальных файла журнала. При создании базы данных логический файл журнала начинается в начале физического файла журнала. Новые записи журнала добавляются в конце логического журнала и приближаются к концу физического файла журнала. Усечение журнала освобождает любые виртуальные журналы, все записи которых находятся перед минимальным регистрационным номером восстановления в журнале транзакций (MinLSN). MinLSN является в журнале транзакций регистрационным номером самой старой записи, которая необходима для успешного отката на уровне всей базы данных. Журнал транзакций рассматриваемой в данном примере базы данных будет выглядеть примерно так же, как на следующей иллюстрации.
Когда конец логического журнала достигнет конца физического файла журнала, новые записи журнала будут размещаться в начале физического файла журнала.
Этот цикл повторяется бесконечно, пока конец логического журнала не совмещается с началом этого логического журнала. Если старые записи журнала усекаются достаточно часто, так что при этом всегда остается место для новых записей журнала, созданных с новой контрольной точки, журнал постоянно остается незаполненным. Однако, если конец логического журнала совмещается с началом этого логического журнала, происходит одно из двух событий, перечисленных ниже.
Если для данного журнала применена установка FILEGROWTH и на диске имеется свободное место, файл расширяется на величину, указанную в growth_increment, и новые записи журнала добавляются к этому расширению. Дополнительные сведения о настройке FILEGROWTH см. в разделе ALTER DATABASE (Transact-SQL).
Если установка FILEGROWTH не применяется или диск, на котором размещается файл журнала, имеет меньше свободного места, чем это указано в growth_increment, формируется ошибка 9002.
Если в журнале содержится несколько физических файлов журнала, логический журнал будет продвигаться по всем физическим файлам журнала до тех пор, пока он не вернется на начало первого физического файла журнала.
technet.microsoft.com
Журнал транзакций (SQL Server)
Опубликовано: Ноябрь 2016
Каждая база данных SQL Server имеет журнал транзакций, в котором фиксируются все изменения данных, произведенные в каждой из транзакций. Журнал транзакций необходимо регулярно усекать, чтобы избежать его переполнения. Но при этом по ряду причин его усечение может быть отложено, поэтому очень важно следить за размером журнала. Некоторые операции можно выполнять с минимальным протоколированием, чтобы сократить их вклад в размер журнала транзакций.
Журнал транзакций является критическим компонентом базы данных и в случае системного сбоя может потребоваться для приведения базы данных в согласованное состояние. Журнал транзакций нельзя ни удалять, ни изменять, если только не известны возможные последствия.
Известные рабочие точки, от которых следует начинать применение журналов транзакций при восстановлении базы данных, создаются контрольными точками. Дополнительные сведения см. в разделе Контрольные точки базы данных (SQL Server). |
В этом разделе.
Журнал транзакций поддерживает следующие операции:
восстановление отдельных транзакций;
восстановление всех незавершенных транзакций при запуске SQL Server;
накат восстановленной базы данных, файла, файловой группы или страницы до момента сбоя;
поддержка репликации транзакций;
Поддержка решений высокой уровня доступности и аварийного восстановления: Группы доступности AlwaysOn, зеркальное отображение базы данных и доставка журналов.
Процесс усечения журнала освобождает место в файле журнала для повторного использования журналом транзакций. Усечение журнала необходимо для предотвращения переполнения журнала. При усечении журнала удаляются неактивные виртуальные файлы журнала из логического журнала транзакций базы данных SQL Server, что приводит к освобождению пространства в логическом журнале для повторного использования физическим журналом транзакций. Если усечение журнала транзакций не выполняется, со временем он заполняет все доступное место на диске, отведенное для файлов физического журнала.
В целях предотвращения этой проблемы усечение журнала выполняется автоматически после следующих событий, за исключением тех случаев, когда оно по каким-то причинам задерживается.
В простой модели восстановления — после достижения контрольной точки.
Для моделей полного восстановления и моделей восстановления с неполным протоколированием, если контрольная точка была создана после предыдущего резервного копирования, усечение происходит после резервного копирования журнала (если только это не резервная копия журнала только для копирования).
Дополнительные сведения см. в подразделе Факторы, которые могут вызвать задержку усечения журнала ниже в этом разделе.
Усечение журнала не приводит к уменьшению размера физического файла журнала. Для уменьшения реального размера физического файла журнала необходимо выполнить его сжатие. Сведения о сжатии физического файла журнала см. в разделе Управление размером файла журнала транзакций. |
Когда записи журнала остаются активными длительное время, усечение журнала транзакций откладывается и возникает вероятность переполнения журнала транзакций.
Усечение журнала может быть задержано из-за множества факторов. Чтобы определить причину, препятствующую усечению журнала транзакций в конкретном случае, выполните запрос по столбцам log_reuse_wait и log_reuse_wait_desc представления каталога sys.database. В следующей таблице описаны значения этих столбцов.
| 0 | NOTHING; | В данный момент существует один или более виртуальных файлов журнала, доступных для повторного использования. |
| 1 | CHECKPOINT | С момента последнего усечения журнала не было новых контрольных точек, либо заголовок журнала не перемещался за пределы виртуального файла журнала. (Все модели восстановления) Это широко распространенная причина задержки усечения журнала. Дополнительные сведения см. в разделе Контрольные точки базы данных (SQL Server). |
| 2 | LOG_BACKUP | Требуется выполнить резервное копирование журналов, поскольку лишь после этого журнал транзакций может быть усечен. (Только для моделей полного восстановления и моделей восстановления с неполным протоколированием) После завершения создания следующей резервной копии журнала некоторое пространство журнала может освободиться для повторного использования. |
| 3 | ACTIVE_BACKUP_OR_RESTORE | Выполняется резервное копирование или восстановление данных (для всех моделей восстановления). Если усечению журнала препятствует резервное копирование данных, то проблему может решить отмена операции резервного копирования. |
| 4 | ACTIVE_TRANSACTION | Активна одна из транзакций (для всех моделей восстановления). - Во время начала создания резервной копии журнала может существовать длительная транзакция. В этом случае, чтобы освободить пространство, может потребоваться создание другой резервной копии журнала. Note: Длительные транзакции препятствуют усечению журнала во всех моделях восстановления, включая простую модель восстановления, в которой журнал транзакций обычно усекается на каждой автоматической контрольной точке.- Транзакция отложена.Отложенная транзакция — это активная транзакция, откат которой был заблокирован по причине недоступности какого-либо ресурса. Дополнительные сведения о причинах, вызывающих появление отложенных транзакций, и о том, как их можно вывести из такого состояния, см. в разделе Отложенные транзакции (SQL Server). |
| 5 | DATABASE_MIRRORING | Зеркальное отображение базы данных приостановлено или в режиме высокой производительности зеркальная база данных намного отстает от основной. (Только для модели полного восстановления) Дополнительные сведения см. в разделе Зеркальное отображение базы данных (SQL Server). |
| 6 | REPLICATION | Во время репликации транзакций в базу данных распространителя не доставляются транзакции, имеющие отношение к публикациям. (Только для модели полного восстановления) Дополнительные сведения о репликации транзакций см. в разделе Репликация SQL Server. |
| 7 | DATABASE_SNAPSHOT_CREATION | Создается моментальный снимок базы данных. (Все модели восстановления) Это очень распространенная (и обычно кратковременная) причина задержки усечения журнала транзакций. |
| 8 | LOG_SCAN | Производится просмотр журнала. (Все модели восстановления) Это очень распространенная (и обычно кратковременная) причина задержки усечения журнала транзакций. |
| 9 | AVAILABILITY_REPLICA | Вторичная реплика группы доступности применяет записи журнала транзакций этой базы данных к соответствующей базе данных-получателю. (Модель полного восстановления) Дополнительные сведения см. в разделе Обзор групп доступности AlwaysOn (SQL Server). |
| 10 | — | Только для внутреннего применения |
| 11 | — | Только для внутреннего применения |
| 12 | — | Только для внутреннего применения |
| 13 | OLDEST_PAGE | Если база данных настроена для использования косвенных контрольных точек, самая старая страница в базе данных может быть старше контрольной точки с номером LSN. В этом случае самая старая страница может задержать усечение журнала. (Все модели восстановления) Дополнительные сведения о косвенных контрольных точках см. в разделе Контрольные точки базы данных (SQL Server). |
| 14 | OTHER_TRANSIENT | Эта значение сейчас не используется. |
| 16 | XTP_CHECKPOINT | Если база данных имеет оптимизированную для памяти файловую группу, журнал транзакций может не усекаться до срабатывания автоматической контрольной точки In-Memory OLTP (что происходит при росте размера журнала на каждые 512 МБ). Note: Чтобы усечь размер журнала транзакций до достижения 512 МБ, выполните команду Checkpoint вручную для соответствующей базы данных. |
Минимальное протоколирование — это протоколирование только информации, необходимой для восстановления транзакции без поддержки восстановления на момент времени. В этом разделе определяются операции, которые подлежат минимальному протоколированию в модели восстановления с неполным протоколированием (как и в простой модели восстановления, кроме случаев, когда выполняется резервное копирование).
Минимальное протоколирование не поддерживается для оптимизированных для памяти таблиц. |
В модели полного восстановления все массовые операции полностью протоколируются. Однако для набора массовых операций можно использовать минимальное протоколирование, временно переключив базу данных на модель восстановления с неполным протоколированием во время массовых операций. Минимальное протоколирование более эффективно, чем полное, и снижает вероятность того, что во время массовой операции большого объема будет заполнено все доступное пространство журнала транзакций. Однако, если при включенном минимальном протоколировании база данных будет повреждена или потеряна, ее нельзя будет восстановить до точки сбоя. |
Следующие операции, выполняемые с полным протоколированием в модели полного восстановления, осуществляются с минимальным протоколированием в простой модели восстановления и модели восстановления с неполным протоколированием:
Операции массового импорта (bcp, BULK INSERT и INSERT... SELECT). Дополнительные сведения о том, когда массовый импорт в таблицу подлежит минимальному протоколированию, см. в разделе Предварительные условия для минимального протоколирования массового импорта данных.
Примечание Если включена репликация транзакций, операции BULK INSERT полностью протоколируются даже в модели с неполным протоколированием.
Операции SELECT INTO.
Примечание Если включена репликация транзакций, операции 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 всегда протоколируется полностью.
Managing the transaction log
Резервное копирование журнала транзакций (модель полного восстановления)
Восстановление журнала транзакций (модель полного восстановления)
Управление устойчивостью транзакцийПредварительные условия для минимального протоколирования массового импорта данныхРезервное копирование и восстановление баз данных SQL ServerКонтрольные точки базы данных (SQL Server)Просмотр или изменение свойств базы данныхМодели восстановления (SQL Server)
msdn.microsoft.com
Создание резервных копий журналов транзакций
- 12/15/2008
- Время чтения: 2 мин
В этой статье
Изменения: 17 июля 2006 г.
Этот раздел относится только к тем базам данных, которые используют полную модель восстановления или модель восстановления с неполным протоколированием.
В этом разделе рассматриваются вопросы резервного копирования журнала транзакций и предоставляются ссылки на процедуры для создания резервных копий журналов. Дополнительные сведения о резервных копиях журналов транзакций см. в разделе Использование резервных копий журналов транзакций.
Условия для резервного копирования журнала транзакций
Перед созданием любой резервной копии журнала необходимо иметь как минимум одну полную резервную копию. После этого резервное копирование журнала транзакций может выполняться во время любого резервного копирования, за исключением другого резервного копирования журнала. Рекомендуется периодически производить резервное копирование журнала для снижения вероятности потери результатов работы и разрешения усечения журнала.
Обычно перед восстановлением базы данных, необходимо попытаться создать резервную копию заключительного фрагмента журнала. Дополнительные сведения о создании резервной копии заключительного фрагмента журнала и об ситуациях, при которых такое резервное копирование не требуется, см. в разделе Резервные копии заключительного фрагмента журнала.
Работа последовательности резервных копий журнала
Администратор базы данных обычно создает полную резервную копию базы данных по прошествии определенного интервала времени, например каждую неделю. Дополнительно администратор создает разностную резервную копию на более коротком интервале, например каждый день. А резервные копии журнала транзакций создаются с периодичностью в 10 минут. Оптимальный интервал между моментами выполнения резервного копирования зависит от множества факторов: важности данных, размера базы данных и рабочей нагрузки сервера.
Если журнал транзакций поврежден, будут потеряны все результаты работы начиная с момента самого последнего резервного копирования журнала. Это подчеркивает важность помещения файлов журнала в отказоустойчивое хранилище.
Последовательность резервных копий журналов транзакций не зависит от полных резервных копий базы данных. Можно сделать одну последовательность резервных копий журналов транзакций, а затем периодически делать полные резервные копии базы данных, используемые для начала операции восстановления. Например, предположим, что имеется следующая последовательность событий:
8:00 утра | Резервное копирование базы данных. |
Полдень | Резервное копирование журнала транзакций. |
16:00 | Резервное копирование журнала транзакций. |
18:00 | Резервное копирование базы данных. |
20:00 | Резервное копирование журнала транзакций. |
Резервная копия журналов транзакций, созданная в 20:00, содержит записи журнала транзакций с 16:00 до 20:00. В этом же временном диапазоне, а именно в 18:00, была создана полная резервная копия базы данных. Последовательность резервных копий журнала транзакций продолжается непрерывно от момента создания начальной полной резервной копии в 8:00 и до создания последней резервной копии журнала транзакций в 20:00.
Сведения о применении этих журналов транзакции приводятся в примере в разделе Применение резервных копий журнала транзакций.
Создание резервных копий журналов транзакций
базовый синтаксис BACKUP для создания полной резервной копии:
BACKUP LOG имя_базы_данных TO <устройство_резервного_копирования>
Создание резервной копии журнала транзакций
Расписание заданий резервного копирования
См. также
Основные понятия
Транзакции (компонент Database Engine)Использование резервных копий журналов транзакций
Справка и поддержка
Получение помощи по SQL Server 2005
Журнал изменений
msdn.microsoft.com
Ведение журнала и восстановление в SQL Server - CyberGuru.ru
Written on 09 Февраля 2009. Posted in MS SQL Server
Страница 3 из 5
Журнал транзакций
Восстановление после сбоя возможно только в том случае, если не пострадал журнал транзакций. На деле журнал транзакций является самой важной частью базы данных — это единственное место, в котором в случае сбоя гарантируется наличие описаний всех изменений базы данных.
Если журнал транзакций отсутствует или поврежден после сбоя, тогда восстановление после сбоя выполнить невозможно, в результате чего база данных становится сомнительной. В этом случае базу данных необходимо восстанавливать из резервных копий или использовать для восстановления менее желательные режимы, такие как аварийное восстановление. (Эти процедуры выходят за рамки данной статьи, но будут глубоко обсуждаться в последующих статьях в течение этого года.)
Журнал транзакций представляет собой специальный файл, необходимой любой базе данных для надлежащего функционирования. В нем содержатся записи журнала, создаваемые в процессе ведения журнала, и журнал используется для повторного чтения этих записей во время восстановления (или любого другого, упоминавшегося ранее, использования процедуры ведения журнала). Так же, как пространство, занятое собственно записями журнала, транзакция в журнале транзакций резервирует также пространство для любых потенциальных записей журнала, которые потребовались бы в случае необходимости отменить транзакцию и выполнить откат. Этим объясняется поведение, которое можно наблюдать, когда, например, для транзакции, обновляющей 50 МБ данных в базе данных, на деле в журнале транзакций может потребоваться пространство в 100 МБ.
Когда создается новая база данных, журнал транзакций, по существу, пуст. По мере возникновения транзакций записи журнала последовательно записываются в журнал транзакций, из чего следует, что создание нескольких файлов журнала транзакций не дает никакого выигрыша в производительности, что является широко распространенным заблуждением. Журнал транзакций будет использовать все файлы журнала по очереди.
В журнале транзакций могут перемежаться записи журнала для параллельных транзакций. Следует помнить о том, что записи журнала для одной транзакции связаны посредством своих LSN, поэтому нет необходимости все записи журнала, относящиеся к одной транзакции, группировать в одном журнале. Практически, номера LSN можно представлять себе как метку времени.
Физическая архитектура журнала транзакций показана на рис. 1. Внутренне он разбит на небольшие части, называемые виртуальными файлами журналов (или файлами VLF). Это просто вспомогательные средства для облегчения внутреннего управления журналом транзакций. Когда файл VLF заполняется, процедура ведения журнала автоматически переходит к следующему VLF в журнале транзакций. Можно было бы подумать, что, в конце концов, журнал транзакций столкнется с нехваткой места, но именно в этом вопросе журнал транзакций решительно отличается от файлов данных.
Рис. 1 Физическая архитектура журнала транзакций
В действительности журнал транзакций является кольцевым файлом, поскольку записи журнала в начале журнала транзакций отбрасываются (или очищаются). Затем, когда процедура ведения жунала достигает конца журнала транзакций, она снова заворачивает в начало и начинает писать поверх того, что было там ранее.
Итак, как осуществляется отбрасывание записей журнала, позволяющее занимаемое ими пространство использовать повторно? Запись журнала транзакций становится не нужной, если имеют место следующие факты.
- Транзакция, частью которой является эта запись, зафиксирована.
- Все страницы базы данных, которые она изменила, записаны на диск процедурой контрольной точки.
- Данная запись журнала не требуется для резервного копирования (полного, выборочного или журнала).
- Эта запись журнала не требуется никакому компоненту, читающему журнал (например, средству зеркального отображения базы данных или репликации).
Запись журнала, потребность в которой сохраняется, называется активной, и файл VLF, имеющий по крайней мере одну активную запись журнала, также называется активным. Время от времени журнал транзакций проверяется с целью выяснения, являются ли активными все записи журнала в заполненном VLF, или нет; если они все не активны, VLF помечается как отброшенный (что означает, что VLF можно перезаписывать, когда исчерпается свободное место в журнале транзакций). Когда VLF отбрасывается, он никак не перезаписывается и не опустошается, а просто помечается как отброшенный и впоследствии может быть использован повторно.
Этот процесс называется усечением журнала, что не следует путать с реальным сокращением размера журнала транзакций. При усечении журнала никогда не изменяется физический размер журнала транзакций, а изменяется только состояние частей журнала транзакций на активное или неактивное. На рис. 2 показан журнал транзакций из рис. 1 после проведения усечения.
Рис. 2 Журнал транзакций после усечения журнала
Активные VLF образуют логический журнал, являющийся частью журнала транзакций, содержащей активные записи журналов. Сама база данных знает, с какого места процедура восстановления после сбоя должна начинать чтение записей журнала в активной части журнала — с начала самой старой активной транзакции в журнале, MinLSN (она хранится в загрузочной странице базы данных).
Процедуре восстановления после сбоя не известно, в каком месте следует прекратить чтение записей журнала, поэтому она продолжает до тех пор, пока не достигнет пустого раздела журнала транзакций (если журнал транзакций еще не исчерпал свое свободное пространство) или записи журнала, чьи биты четности не соответствуют последовательности из предыдущей записи журнала.
По мере того, как файлы VLF становятся отброшенными, а новые файлы — активными, логический журнал перемещается в физическом файле журнала транзакций и, в конце концов, вынужден снова завернуть в начало, как показано на рис. 3.
Рис. 3 Циклический характер журнала транзакций
Проверка того, возможно ли усечение журнала при каком либо из следующих условий:
- При возникновении контрольной точки в модели восстановления SIMPLE или в других моделях восстановления, если никогда не выполнялось полное резервное копирование. (При этом предполагается, что база данных, после вывода из модели SIMPLE, остается в модели восстановления псевдо-SIMPLE до тех пор, пока не будет выполнено полное резервное копирование базы данных.)
- При завершении резервного копирования журнала.
Следует помнить, что усечение журнала может оказаться невозможным, поскольку существует много причин, по которым запись журнала должна оставаться активной. Если усечение журнала невозможно, файлы VLF не могут быть отброшены, и, в конечном счете, журнал должен увеличить свой размер (или должен быть добавлен еще один журнал транзакций). Чрезмерное разрастание журнала транзакций может привести к проблемам с производительностью вследствие эффекта, известного под названием фрагментация VLF. Устранение фрагментации VLF иногда может привести к впечатляющему повышению производительности действий, связанных с журналом.
Усечению журнала могут воспрепятствовать две широко известные проблемы:
- Длительно выполняющаяся активная транзакция. Весь журнал транзакций, с первой записи журнала из самой старой активной транзакции, никогда не может быть усечен до тех пор, пока эта транзакция не будет зафиксирована или аварийно завершена.
- Переключение на модель восстановления FULL, выполнение полной резервной копии и полный отказ от создания резервных копий журнала. Весь журнал транзакций остается активным в ожидании резервного копирования процедурой резервного копирования журнала.
Если журнал транзакций исчерпал весь объем и не может продолжить дальнейшее увеличение, поступает сообщение об ошибке 9002, и вам потребуется предпринять шаги для предоставления дополнительного пространства, например увеличить объем файла журнала, добавить еще один файл журнала или устранить все, что мешает усечению журнала.
Ни при каких обстоятельствах не следует удалять журнал транзакций, пытаться восстановить его с помощью недокументированных команд или просто обрезать его с помощью параметров NO_LOG или TRUNCATE_ONLY команды BACKUP LOG (которая удалена из SQL Server 2008). Эти параметры приведут либо к несогласованности с точки зрения транзакций (и, что более вероятно, к повреждению файла), либо лишат возможности надлежащего восстановления базы данных.
www.cyberguru.ru
Устранение неполадок при переполнении журнала транзакций (ошибка 9002)
В этом разделе описаны возможные действия при переполнении журнала транзакций, а также советы о том, как его избежать. Когда журнал транзакций переполняется, в компоненте SQL Server Database Engine происходит ошибка 9002. Журнал может заполниться, когда база данных работает в оперативном режиме или находится в процессе восстановления. Если журнал заполняется, когда база данных находится в оперативном режиме, база данных остается в оперативном режиме, но доступной только для чтения, но не для обновления. Если журнал заполняется, когда база данных находится в процессе восстановления, компонент Database Engine помечает базу данных как RESOURCE PENDING. В любом случае необходимо вмешательство пользователя, чтобы сделать журнал транзакций доступным.
Действия при переполнении журнала транзакций
Ответные действия при переполнении журнала транзакций частично зависят от условий, которые вызвали переполнение журнала. Чтобы определить, что препятствует усечению журнала транзакций в конкретном случае, используйте столбцы log_reuse_wait и log_reuse_wait_desc представления каталога sys.database. Дополнительные сведения см. в разделе sys.databases (Transact-SQL). Описание причин, которые могут задержать усечение журнала, см. в разделе Факторы, могущие вызвать задержку усечения журнала.
Если при возникновении ошибки 9002 база данных находилась в состоянии восстановления, то после устранения проблемы восстановите базу данных с помощью инструкции ALTER DATABASE имя_базы_данных SET ONLINE. |
Важно! При переполнении журнала транзакций предусмотрены следующие ответные действия:
создание резервной копии журнала;
освобождение места на диске, чтобы журнал мог автоматически расти;
перемещение файла журнала на диск с достаточным объемом свободного места;
увеличение размера файла журнала;
добавление файла журнала на другой диск;
завершение или уничтожение длительной транзакции.
Эти возможности описаны в следующих разделах. Выберите ответное действие, наиболее подходящее в конкретной ситуации.
Создание резервной копии журнала
Для полных моделей восстановления и моделей с неполным протоколированием резервное копирование может предотвратить усечение журнала транзакций, если оно не было сделано недавно. Если резервная копия журнала создается в первый раз, необходимо сделать вторую резервную копию журнала, чтобы разрешить компоненту Database Engine усечение журнала до точки последнего резервного копирования. Усечение журнала освобождает пространство для новых записей журнала. Чтобы избежать повторного переполнения журнала, следует чаще выполнять резервное копирование.
Создание резервной копии журнала транзакций
Освободите место на диске
Возможно, следует освободить место на диске, где находится файл журнала транзакций для базы данных. Для этого можно удалить или переместить другие файлы. Освобожденное место на диске позволит системе восстановления автоматически увеличить размер файла журнала.
Перемещение файла журнала на другой диск
Если на текущем диске невозможно освободить достаточное количество места, следует переместить файл на другой диск, где места достаточно.
Файлы журнала ни в коем случае не следует размещать в файловых системах со сжатием. |
Перемещение файла журнала
Увеличение размера файла журнала
Если на диске, на котором находится журнал, доступно свободное место, можно увеличить размер файла журнала. Максимальный объем файлов журнала составляет 2 терабайта (ТБ) на файл журнала.
Увеличение размера файла
Если автоувеличение отключено, база данных находится в оперативном режиме и на диске достаточно свободного места, выполните одно из следующих действий.
Вручную увеличьте размер файла для получения одного шага роста размера файла.
Включить свойство автоматического увеличения при помощи инструкции ALTER DATABASE, чтобы установить отличное от нуля значение шага роста для параметра FILEGROWTH.
В любом случае, если достигнут текущий предел размера файла, увеличьте значение MAXSIZE. |
Примечание Добавление файла журнала на другой диск
Добавьте новый файл журнала базы данных на другом диске, где достаточно места, с помощью инструкции ALTER DATABASE <имя_базы_данных> ADD LOG FILE.
Добавление файла журнала
Идентификация и управление длительной транзакцией
msdn.microsoft.com
Устранение неполадок при переполнении журнала транзакций (ошибка 9002)
- 12/15/2008
- Время чтения: 3 мин
В этой статье
Изменения: 14 апреля 2006 г.
В этом разделе описаны возможные действия при переполнении журнала транзакций, а также советы о том, как его избежать. Когда журнал транзакций переполняется, в компоненте SQL Server Database Engine происходит ошибка 9002. Журнал может заполниться, когда база данных работает в оперативном режиме или находится в процессе восстановления. Если журнал заполняется, когда база данных находится в оперативном режиме, база данных остается в оперативном режиме, но доступной только для чтения, но не для обновления. Если журнал заполняется, когда база данных находится в процессе восстановления, компонент Database Engine помечает базу данных как RESOURCE PENDING. В любом случае необходимо вмешательство пользователя, чтобы сделать журнал транзакций доступным.
Действия при переполнении журнала транзакций
Ответные действия при переполнении журнала транзакций частично зависят от условий, которые вызвали переполнение журнала. Чтобы определить, что препятствует усечению журнала транзакций в конкретном случае, используйте столбцы log_reuse_wait и log_reuse_wait_desc представления каталога sys.database. Дополнительные сведения см. в разделе sys.databases (Transact-SQL). Описание причин, которые могут задержать усечение журнала, см. в разделе Факторы, вызывающие задержку усечения журнала.
| Если при возникновении ошибки 9002 база данных находилась в состоянии восстановления, то после устранения проблемы восстановите базу данных с помощью инструкции ALTER DATABASE имя_базы_данных SET ONLINE. |
Важно! При переполнении журнала транзакций предусмотрены следующие ответные действия:
- создание резервной копии журнала;
- освобождение места на диске, чтобы журнал мог автоматически расти;
- перемещение файла журнала на диск с достаточным объемом свободного места;
- увеличение размера файла журнала;
- добавление файла журнала на другой диск;
- завершение или уничтожение длительной транзакции.
Эти возможности описаны в следующих разделах. Выберите ответное действие, наиболее подходящее в конкретной ситуации.
| Принудительное усечение журнала прерывает цепочку журналов и оставляет базу данных уязвимой до тех пор, пока не будет сделана следующая полная резервная копия. Поэтому параметр TRUNCATE_ONLY будет удален из инструкции BACKUP в будущей версии SQL Server. Избегайте использования данного параметра в новых разработках и запланируйте модификацию приложений, которые сейчас его используют. |
Создание резервной копии журнала
Для полных моделей восстановления и моделей с неполным протоколированием резервное копирование может предотвратить усечение журнала транзакций, если оно не было сделано недавно. Если резервная копия журнала создается в первый раз, необходимо сделать вторую резервную копию журнала, чтобы разрешить компоненту Database Engine усечение журнала до точки последнего резервного копирования. Усечение журнала освобождает пространство для новых записей журнала. Чтобы избежать повторного переполнения журнала, следует чаще выполнять резервное копирование.
Создание резервной копии журнала транзакций
Освободите место на диске
Возможно, следует освободить место на диске, где находится файл журнала транзакций для базы данных. Для этого можно удалить или переместить другие файлы. Освобожденное место на диске позволит системе восстановления автоматически увеличить размер файла журнала.
Перемещение файла журнала на другой диск
Если на текущем диске невозможно освободить достаточное количество места, следует переместить файл на другой диск, где места достаточно.
| Файлы журнала ни в коем случае не следует размещать в файловых системах со сжатием. |
Перемещение файла журнала
Увеличение размера файла журнала
Если на диске, на котором находится журнал, доступно свободное место, можно увеличить размер файла журнала.
Увеличение размера файла
Если режим автоувеличения отключен, база данных находится в оперативном режиме и на диске достаточно свободного места, выполните одно из следующих действий.
- Вручную увеличьте размер файла для получения одного шага роста размера файла.
- Включить свойство автоматического увеличения при помощи инструкции ALTER DATABASE, чтобы установить отличное от нуля значение шага роста для параметра FILEGROWTH.
| В любом случае, если достигнут текущий предел размера файла, увеличьте значение MAXSIZE. |
Добавление файла журнала на другой диск
Добавьте новый файл журнала базы данных на другом диске, где достаточно места, с помощью инструкции ALTER DATABASE <имя_базы_данных> ADD LOG FILE.
Добавление файла журнала
Идентификация и управление длительной транзакцией
Дополнительные сведения см. в разделе Управление длительными транзакциями.
См. также
Основные понятия
Создание резервных копий журналов транзакцийФакторы, вызывающие задержку усечения журналаОбзор моделей восстановленияЗнакомство с журналами транзакцийИспользование резервных копий журналов транзакций
Другие ресурсы
ALTER DATABASE (Transact-SQL)Управление журналом транзакцийsp_add_log_file_recover_suspect_db (Transact-SQL)
Справка и поддержка
Получение помощи по SQL Server 2005
Журнал изменений
14 апреля 2006 г. | Новое содержимое
|
technet.microsoft.com
