Ошибка журнала транзакций на томе содержащем файл шаблонов

Содержание:

1.       Журнал транзакций в 1С

2.       Ошибка Журнал транзакций переполнен  

1.    Журнал транзакций в 1С

В данной статье будет описана возможная ошибка в системе 1С, а именно – в СУБД, которая связана с переполнением журнала транзакций в 1С. Далее будут приведены возможные методы устранения данной неполадки, среди которых уменьшение журнала транзакций для базы данных.

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

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

1.     Восстановление транзакций;

2.     Восстановление транзакций, которые не были окончены;

3.     Поддерживать повторения транзакций;

4.     Производить восстановление базы данных, из-за системного сбоя.  


2.    Ошибка Журнал транзакций переполнен

В СУБД 1С может появляться ошибка, которая содержит следующий текст: «Журнал транзакций для базы данных «zup» заполнен». Также, в тексте ошибки может приводиться столбец и таблица, к которым следует обратиться.

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

Рассмотрим два возможных способа для устранения ошибки «Журнал транзакций для базы данных переполнен»:

·        В первом способе будем следовать такому алгоритму:

1.     Проверить наличие и величину свободного места на дисках, в случае, когда места нет – соответственно, нет места и для записи лога;

2.     Если место есть, то ошибка «Журнал транзакций для базы переполнен» является ошибкой MicrosoftSQLServer, то есть – лог с транзакциями был полностью заполнен, но не очищен. Это можно исправить при помощи очистки, которая является стандартной, но эта опция не всегда может помочь устранить неполадку. В случае, если она не сработала – стоит использовать следующий код SQLServer:

код SQLServer

В данном коде: 20 – это величина лога в Мб, а «myDataBase» — название нужной базы с данными.

·        Следующий способ – это сразу приступить к уменьшению размера журнала с транзакциями.

Так как с журналом транзакций в SQLServer часто проводится много довольно весомых манипуляций, которые связаны с модификацией данных в СУБД, то такие действия приводят к увеличению размеров файловых данных внутри журнала с транзакциями. В данном случае очень важно вовремя удалять не нужные записи из журнала транзакций SQL, в связи с созданием более актуальных. Если не проводить удаления вовремя, то прошлые файлы в журнале транзакций начинают заполнять всё место на диске и далее станет невозможно работать с СУБД.

Так что, в своём роде, данный способ – это предотвращение ошибки «Журнал транзакций переполнен» в 1С.

В таком случае, удаляем те записи, которые больше не нужны, при помощи команды «BACKUPLOG», следующий шаг – это сделать меньше файл из журнала транзакций MSSQL– при помощи команды «DBCCSHRINKFILE». Таким образом, нужный нам код, для предотвращения ошибки, будет выглядеть таким образом:

Предотвращение ошибки Журнал транзакций переполнен

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

Специалист компании «Кодерлайн»

Айдар Фархутдинов

  • Remove From My Forums
  • Question

  • We have a very peculiar situation and are unable to shrink the transaction log. We have tried both with the Simple and Full recovery models and when we run DBCC SHRINKFILE(<DBNAME>, 0), we get the following error message:

    Cannot shrink log file 2 (XXX_log) because of minimum log space required.

    Appreciate any help!


    Jagannathan

Answers

  • Guys, I see a lot of mention about replication being broken etc., IMHO and experience having used replication extensively in SQL Server 2000, nowhere does replication cause the TX log to grow even if it is broken unless the distribution db is down or the
    log reader agent is broken etc., As long as the Distribution database is available, all transactions marked for replication are captured in the distribution database at which point the TX log entries are marked as being captured for replication. The distribution
    database captures replicated commands (INSERT, DELETE and UPDATEs) from the TX log and then at that point the TX log should be available for truncation. In fact, you should be able run a SQL command against the distribution database to see the actual command
    waiting to be replicated.

    As for the main issue, what we found was that a «full» backup, immediately followed by a TX log backup and finally a DBCC SHRINKFILE resolved the issue. Thanks for all of the replies!


    Jagannathan

    • Marked as answer by

      Tuesday, May 18, 2010 3:08 PM

  • Remove From My Forums
  • Question

  • We have a very peculiar situation and are unable to shrink the transaction log. We have tried both with the Simple and Full recovery models and when we run DBCC SHRINKFILE(<DBNAME>, 0), we get the following error message:

    Cannot shrink log file 2 (XXX_log) because of minimum log space required.

    Appreciate any help!


    Jagannathan

Answers

  • Guys, I see a lot of mention about replication being broken etc., IMHO and experience having used replication extensively in SQL Server 2000, nowhere does replication cause the TX log to grow even if it is broken unless the distribution db is down or the
    log reader agent is broken etc., As long as the Distribution database is available, all transactions marked for replication are captured in the distribution database at which point the TX log entries are marked as being captured for replication. The distribution
    database captures replicated commands (INSERT, DELETE and UPDATEs) from the TX log and then at that point the TX log should be available for truncation. In fact, you should be able run a SQL command against the distribution database to see the actual command
    waiting to be replicated.

    As for the main issue, what we found was that a «full» backup, immediately followed by a TX log backup and finally a DBCC SHRINKFILE resolved the issue. Thanks for all of the replies!


    Jagannathan

    • Marked as answer by

      Tuesday, May 18, 2010 3:08 PM

  • Remove From My Forums
  • Вопрос

Ответы

  • Сделал
    CHKDSK – есть вопросы см. ссылку
    :

    http://s40.radikal.ru/i088/1103/f8/43700d911acc.jpg

     и вот ещё вопросик (если можно?) у меня на другом серваке вот такая проблема:

    происходит ошибка
    № 333

    http://i076.radikal.ru/1103/11/24b687a8c38f.jpg

    расшифровка мини дампа дала следующие результаты,

    http://s14.radikal.ru/i187/1103/ae/59900a8a8447.jpg

    короче виноват файл
     ntkrnlpa.exe, вот подсказали как этот файл или драйвер

    от какого устройства заменить – чтоб перестала вылетать ошибка
    333

    Вот решение ошибки 333.

    http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q246/1/83.ASP&NoWebContent=1

    И пояснение на русском, с русскоязычного форума.

    Была такая радость. Вылечил по
    статье
    причем вышел на нее только когда увидел более-менее четкие проблемы с планировщиком, до этого искал по EventID 333 и ничего не нашел.
    Смысл: сначала пробуем запустить службу Protected Storage, ибо проблема растет оттуда. Затем, если ее сознательно никто не отрубал, смотрим, есть ли ветка в реестре HKEY_USERS.DefaultSoftwareMicrosoftCryptographyProvidersType 001, если есть — удаляем
    и перезагружаем ПК. Если ее нет, то идем в «C:Documents and SettingsAll UsersApplication DataMicrosoftCryptoRSAS-1-5-18», удаляем в ней все (для этого надо включить отображение скрытых и системных файлов), перезагружаем ПК
    Мне помогло — ошибка 333 после этого исчезла, а так весь лог был полон и, что самое страшное — останавливалась ISA, все тормозило и блокировался весь сетевой трафик. После ребута шуршал около суток и снова валился туда же. При этом сбрасывались параметры логина
    для заданий планировщика :)

    Спасибо всем кто мне помогал с ошибкой
    ID 57,вроде бы с помощью совета
    «chkdsk», туф, тфу она исчезла. Вот теперь бы побороть  ID
    333
    !

    Как пишет
    piligrim2180 начать нужно с запуска  «Protected
    Storage»,

    http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q246/1/83.ASP&NoWebContent=1

    А
    если у меня нет службы
    Protected Storage и не когда не было с чего начать?

    http://i010.radikal.ru/1103/3a/cd8c24cba401.jpg

    • Помечено в качестве ответа

      6 апреля 2011 г. 11:19

Журнал транзакций также называется журналом повторов. Функция журнала транзакций в Oracle и SQL Server аналогична. В отличие от Oracle, при добавлении файла журнала повторов в базу данных вы можете указать такие атрибуты, как начальный размер, скорость роста и максимальный размер, как файл данных базы данных SQL Server. При добавлении файла журнала транзакций в базу данных Oracle вы можете указать только начальный размер, а не скорость роста, максимальный размер и другие атрибуты.

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

SQL Server опирается на журналы для обеспечения согласованности (конечно, журналы имеют много функций, но согласованность является основной функцией журналов, а другие функции можно рассматривать как дополнительные функции).
Журнал транзакций поддерживает следующие операции:

  • Восстановить отдельные транзакции
    Если приложение выдает инструкцию ROLLBACK или ядро ​​базы данных обнаруживает ошибку (например, потерю связи с клиентом), используйте журнал, чтобы откатить изменения, сделанные незавершенными транзакциями.
  • Восстановление всех незавершенных транзакций при запуске SQL Server
    При сбое сервера под управлением SQL Server база данных может находиться в таком состоянии: некоторые изменения не были записаны из кэша в файл данных, и в файле данных есть незавершенные транзакции Изменения. Когда экземпляр SQL Server запущен, он выполнит операцию восстановления для каждой базы данных, найдет каждую ожидающую транзакцию в журнале транзакций и откатит ее, чтобы обеспечить целостность базы данных. Это восстановление называетсяВосстановление экземпляра
  • Повернуть восстановленную базу данных, файл, файловую группу или страницу до точки отказа
    После того, как аппаратные потери или сбой диска влияют на файлы базы данных, пользователи используют прошлые резервные копии базы данных для восстановления базы данных. Прошлые данные резервной копии базы данных, очевидно, являются состоянием на момент резервного копирования и не будут включать данные, сгенерированные в течение периода от завершения резервного копирования до момента сбоя базы данных, поскольку все модификации данных записываются в файле журнала повторов.SQL Server будет применять записи операций в журнале транзакций к восстановленному файлу данных., Чтобы база данных могла быть восстановлена ​​до того момента, когда произойдет сбой носителя хранения данных, этот вид восстановления называетсяВосстановление медиа
  • Поддержка репликации транзакций
    Принцип репликации транзакций состоит в том, чтобы сначала отправлять начальный моментальный снимок в базе данных издателя каждому подписчику, а затем отслеживать изменения в данных в базе данных издателя, фиксировать отдельные изменения данных и изменять Данные отправляются подписчику. Агент чтения журнала отслеживает журнал транзакций каждой базы данных, настроенной для репликации транзакций, и копирует транзакции, помеченные для репликации, из журнала транзакций в базу данных распространителя. Только подтвержденные транзакции могут быть отправлены в базу данных распространения.
  • Поддержка решений высокой доступности и аварийного восстановления
    Альтернативные серверные решения, группы доступности AlwaysOn, зеркалирование базы данных и доставка журналов в значительной степени зависят от журналов транзакций.

Организация файлов журнала транзакций

4444657-60b9fec9cf15f408.png

1. Журнал транзакций физической архитектуры

Журнал транзакций — это просто файл журнала, в котором записывается поведение транзакций и изменения базы данных в соответствующей базе данных. Когда вы создаете новую базу данных вместе с файлом базы данных, будет файл журнала транзакций с расширением ldf по умолчанию. Конечно, база данных также может быть оснащена несколькими файлами журналов.
SQL Server логически делит физический файл журнала на несколько виртуальных файлов журнала (Virtual Log File, VLF). Используя аналогию, файл журнала (ldf) похож на поезд, а каждая машина представляет собой файл виртуального журнала (VLF).

4444657-2767ef79e169e1cf.png

Тогда почему SQL Server делит файл журнала на несколько VLF? Потому что SQL Server заставляет механизм хранения более эффективно управлять журналом транзакций. Физический журнал увеличивается, сжимается и использует виртуальный журнал (VLF) в качестве наименьшей единицы. При ведении журнала необходимо поддерживать только небольшое количество VLF, чтобы повторное использование пространства журнала было более эффективным.

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

4444657-44cdf7cac3ca54ee.png

Количество VLF и размер каждого VLF автоматически определяются SQL Server в соответствии с размером и скоростью роста файла журнала, то есть VLF не имеет фиксированного размера, а количество VLF, содержащихся в файле журнала, не является фиксированным. Когда размер файла журнала увеличивается, SQL Server также перепланирует количество VLFS.

Когда SQL Server создает базу данных, в соответствии с размером файла журнала (ldf) формула для числа сгенерированных VLF выглядит следующим образом:

4444657-5289d0a0b4fd4793.png

Из приведенной выше диаграммы формул видно, что если файл журнала постепенно увеличивается, например, 1M1M, то при достижении 64M генерируется 64×4 VLF; но если файл журнала Прямое увеличение 64M, окончательное количество VLFs только 8. Если эти файлы журнала увеличатся до большого размера из-за большого количества маленьких приращений, у них будет много VLF, чтоФрагментация файла журналаЭто замедлит запуск базы данных и зарегистрирует операции резервного копирования и восстановления.

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

VLF может существовать в одном из следующих 4 состояний:

  • active: содержит активные транзакции. Активные транзакции относятся к незавершенным транзакциям.
  • Восстанавливаемый: не включает активные транзакции, но в настоящее время база данных находится в состоянии поддержания полной последовательности журнала, и эти VLF не были зарезервированы, поэтому их нельзя перевести в состояние многократного использования, чтобы их можно было использовать повторно. Если они перезаписываются путем повторного использования, полный журнал Последовательность не является непрерывной.
  • возможность многократного использования: резервное копирование выполнялось в режиме полного восстановления или в режиме простого восстановления, активные транзакции не включаются.
  • unused: этот VLF никогда не использовался.
2. Логическая архитектура журнала транзакций

Прежде чем любые изменения, внесенные в объекты базы данных, будут сохранены в базе данных, соответствующие записи логической операции базы данных сначала будут записаны в файл журнала. Эта запись будет записана последовательно до логического конца файла журнала, и будет назначен глобально уникальный порядковый номер журнала (LSN). Этот порядковый номер идет в точном порядке. Если в журнале есть два порядковых номера LSN2> LSN1, это означает, что LSN2 расположен после LSN1.

4444657-bbb4aa300265919e.png

Журнал транзакций в базе данных отображается в одном или нескольких физических файлах. Концептуально, журнал транзакций SQL Server работает логически,Это как если бы журнал транзакций представлял собой строку записей журнала. Физически последовательность записей журнала эффективно сохраняется в наборе физических файлов, который реализует журнал транзакций.

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

4444657-a69dd37c895ff131.png

SQL Server использует записи журнала для обеспечения основных свойств транзакций и восстановления базы данных.

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

4444657-4550880464963d90.png

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

4444657-79ecdb4827d03d87.png

LSN 148 — последняя запись в журнале транзакций. При обработке контрольной точки, зарегистрированной в LSN 147, Тран 1 был зафиксирован, и Тран 2 является единственной активной транзакцией. Это делает первую запись в журнале Tran 2 временем последней контрольной точкиАктивная транзакция(В активном состоянии, которое еще не зафиксировано, откат могут выполнять только неподтвержденные транзакции) самая старая запись журнала. Это делает LSN 142 (начальную запись транзакции Tran 2) MinLSN.

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

Усечение журнала

Перемотка физического журнала
Журнал транзакций представляет собой файл перемотки. Например, предположим, что существует база данных, которая содержит физический файл журнала, разделенный на четыре виртуальных файла журнала. Когда база данных создана,Файл логического журнала (VLF с записями журнала)ИзФайл физического журнала (включая все VLF)Начало начало. Новые записи журнала добавляются вКонец логического журнала, А затем разверните до конца физического журнала. Усечение журнала освободит все виртуальные журналы, все записи которых отображаются до минимального порядкового номера журнала восстановления (MinLSN), а усеченные части журнала помечаются как повторно используемые.

4444657-28592813890ae0d4.png

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

4444657-1a97d97434edda33.png

Этот цикл повторяется непрерывно, пока конец логического журнала не достигает начала логического журнала.

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

Усечение журнала
Усечение журнала в основном используется для предотвращения заполнения журнала.Усечение журнала изменяет состояние VLF файла журнала базы данных, который не содержит активных транзакций (незавершенных транзакций), на повторное использование, освобождая пространство в логическом журнале, чтобы физический журнал транзакций мог повторно использовать пространство.Если журнал транзакций никогда не усекается, он в итоге заполнит все дисковое пространство, выделенное для физического файла журнала. но,Перед усечением журнала необходимо выполнить операцию контрольной точки, чтобы записать грязные страницы и информацию журнала транзакций в текущую память из памяти на диск.
На следующих рисунках показан журнал транзакций до и после усечения. На первом рисунке показан журнал транзакций, который никогда не был усечен. В настоящее время логический журнал использует четыре виртуальных файла журнала. Логический журнал начинается до первого файла логического журнала и заканчивается в виртуальном журнале 4. Запись MinLSN находится в виртуальном журнале 3. Виртуальный журнал 1 и виртуальный журнал 2 содержат только неактивные записи журнала. Эти записи могут быть усечены. Виртуальный журнал 5 все еще не используется и не принадлежит текущему логическому журналу.

4444657-9a994643a79fb524.png

На втором рисунке показана ситуация после усечения журнала. Виртуальный журнал 1 и виртуальный журнал 2 были освобождены для повторного использования. Теперь логический журнал начинается с начала виртуального журнала 3. Виртуальный журнал 5 по-прежнему не используется, он не принадлежит текущему логическому журналу.

4444657-b2a4740a4ec16e68.png

Если по какой-либо причине нет задержки, усечение журнала будет происходить автоматически после следующих событий:

  • В простом режиме восстановления происходит после контрольной точки.
  • В модели полного восстановления или модели массового восстановления происходит после резервного копирования журнала (если с момента последнего резервного копирования была создана контрольная точка).

Как просмотреть записи журнала транзакций

Всем известно, что при полной модели восстановления SQLSERVER будет записывать операции, выполняемые каждой транзакцией. Эти записи будут храниться в журнале транзакций. Тогда как вы просматриваете записи журнала транзакций и что в них записывается?
В записи журнала транзакций можно увидеть множество вещей, в которых записана очень подробная информация об активности в базе данных. Откройте следующую инструкцию SQL для просмотра записей журнала транзакций базы данных:

USE [GPOSDB] - база данных для просмотра записей журнала транзакций
GO
SELECT * FROM [sys].[fn_dblog](NULL,NULL)

4444657-395db3809ea1dd80.png

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

  • CurrentLSN: текущий номер LSN. Каждая запись в журнале транзакций идентифицируется уникальным порядковым номером журнала (LSN). LSN сортируется следующим образом: если LSN2 больше, чем LSN1, изменение, описанное записью журнала, идентифицированной LSN2, происходит после изменения, описанного записью журнала LSN1.
  • Операция, выполняемая соответствующим номером LSN, записывается в столбце «Операция». Несколько общих и важных значений Операции перечислены ниже:
  • Начало транзакции LOP_BEGIN_XACT
  • LOP_LOCK_XACT получить блокировку
  • LOP_MODIFY_ROW изменить строку (конкретный измененный объект можно просмотреть в AllocUnitName)
  • LOP_COMMIT_XACT совершить транзакцию
  • LOP_DELETE_ROWS удалить данные
  • LOP_INSERT_ROWS вставить данные
  • Контекст: контекст операции.
  • Имя транзакции показывает имя созданной базы данных.
  • TransactoinID: идентификационный номер транзакции.
  • Фиксированная длина записи журнала: фиксированная длина файла виртуального журнала, записанного LSN.
  • Предыдущий номер LSN: предыдущий номер LSN.
  • AllocUnitID: идентификатор единицы выделения, которой принадлежит измененный фрагмент данных
  • AllocUnitName: имя таблицы измененных данных.
  • Идентификатор слота: первая запись страницы данных, на которой расположены данные
  • PartitionID: идентификатор раздела страницы данных, на которой расположены данные

Куратор(ы):  

KT   

Автор Сообщение
 
Прилепленное (важное) сообщение

СообщениеДобавлено: 05.09.2005 22:35 

[профиль]

Member

Статус: Не в сети
Регистрация: 06.05.2005
Откуда: Moldova

ПРОСЯ О ПОМОЩИ, ВЫКЛАДЫВАЙТЕ S.M.A.R.T. ПРОБЛЕМНОГО НАКОПИТЕЛЯ!

Его можно посмотреть программами Everest, AIDA 64, Victoria 4.x, Dtemp, HDDScan, HD Tune, Crystal Disk Info, SpeedFan… Обращайте внимание на DATA/RAW-параметры, это главные и основные показатели здоровья диска.

>>>При использовании Crystal Disk Info в меню Сервис>Дополнительно>Raw-значения выберите вариант «10 [DEC]» это несколько упростит восприятие информации утилиты форумчанами.<<<

<<Скриншоты>>

При выкладке скриншотов не забываем ограничения накладываемы пунктом 3.12 правил конференции. А именно: «Размещать в тегах «Img» картинки объемом свыше 500 кБ на сообщение. Допускаются картинки до 2 МБ под тегом «spoiler=«, а также прямые ссылки на картинки любого размера. Ссылки на страницы, где картинка отображается среди рекламы, запрещены, применяющие их сайты блокируются автоцензором.»
Немного о том, как ПРАВИЛЬНО создавать скриншоты для выкладки в форуме: http://forums.overclockers.ru/viewtopic … 4&t=373001

Для лучшего понимания сути вопроса смотрите информацию на первой странице темы, составленную камрадом Ing-Syst.

Так же помочь разобраться в показаниях СМАРТ может очень подробный материал размещенный на сайте ixbt.com: Оцениваем состояние дисков при помощи S.M.A.R.T.

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

Связанные темы

[FAQ] Всё о винчестерах Western Digital
[FAQ] по винчестерам Seagate
[FAQ] Всё о винчестерах Hitachi
[FAQ] Всё о винчестерах Samsung

Восстановление данных
Ремонт HDD

Сигейт официально признал проблему с 7200.11

Полезные сообщения участников этой темы:

Обнуление некоторых параметров СМАРТ на винчестерах Samsung
Как найти файлы на которые приходятся кандидаты на ремап.
Отключение парковки на винчестерах Seagate 7200.14 без батников и автозагрузки (нуждается в проверке)
Remap и Advanced remap, erase и erase delays — назначение команд утилиты Victoria (1,2)
Смена режима контроллера с IDE на AHCI при наличии уже установленной операционной системы Win 7 Win XP

ShutUp — программа камрада CoolCMD для предотвращения частых парковок HDD.

https://disk.yandex.ru/d/x3UITAgo3EGqub

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

Учёт и поиск запчастей к жестким дискам — R.baza.

Последний раз редактировалось KT 29.11.2021 18:36, всего редактировалось 15 раз(а).

Реклама

Партнер
 
mol61

Member

Статус: В сети
Регистрация: 15.06.2010
Откуда: Калуга
Фото: 19

Grom517 писал(а):

на одной линии висят все винты и сидюк, всего 5 штук..

Не очень хорошо. Лучше раскидать. Но больше зависит от качества контактов и самого БП.


_________________
Лужу, паяю, не шалю, никого не трогаю, починяю примус (ЭВМ). Я не фанат INTEL, я просто не люблю AMD.

 
Grom517

Member

Статус: Не в сети
Регистрация: 10.01.2010

mol61
Так это, hx850W всё-таки..
Чуть позже пересоберу на разных линиях, а пока диск в гарантию.
Самому разбирать чтобы чистить — поцарапаю, нарушу условия договора гарантии.

Добавлено спустя 1 минуту 28 секунд:
P.S. Если новый винт не будет сбоить, значит дело было не в бп?
Или это со временем может проявляться?

 
UltroZero

Junior

Статус: Не в сети
Регистрация: 11.04.2015

Здравствуйте! Начались проблемы с жестким диском: 3.5″ 4TB Seagate

Мое железо:
1.Мат. плата: ASUS CROSSHAIR V FORMULA-Z
2.Процессор: AMD FХ8350 FRHK BOX
3.Видеокарта: ASUS Radeon R9 290X 4096Mb DCII OC (R9290X-DC2OC-4GD5)
4.Модуль памяти: DDR3 16GB (2x8GB) 2133 MHz G.Skill (F3-2133C10D-16GSR)
6.Блок питания: CHIEFTEC 1000W (APS-1000C)
7.Накопитель SSD: 2.5″ 256GB Samsung (MZ-7PD256BW) — на нем Винда
8.Жесткий диск: 3.5″ 4TB Seagate (ST4000NM0033) — Больной пациент

Что произошло:
Установил и запустил на машине, именно на HDD диске, он разбит на четыре раздела (в разделе — том «I»), программу Asus GPU Tweak, сделал ею настройки видеокарты, сохранил и попытался закрыть программку, но винда вдруг зависла намертво, не реагировало ничего, ни мышь, ни клавиатура, очень долго, пришлось вырубать кнопкой питания на системнике.

После перезагрузки запустился CHKDSK и попытался что-то исправить, но не завершив свою работу вылетел в BSOD. Пришлось опять перезагружаться и софтинка CHKDSK снова зависла на каком то этапе работы, но уже без BSOD. Перезагрузился еще раз отменив работу CHKDSK, и о чудо, HDD диск начал сильно тормозить, пропадать и т.д. Загрузка и окончание работы винды происходят очень долго когда диск иннициализируется системой, зайти в него можно, но папки открыть невозможно — «ошибка ввода/вывода», ничего нельзя скопировать или перенести. В управлении дисками отображается нормально, никаких проблем не видно. Бывает после перезагрузки он вообще нигде не отображается, ни в проводнике, ни в управлении дисками, ни в диспетчере устройств и очень редко, но даже не отображается в биосе (очень редко). Ничего пока не предпринимал так как весь софт стоял именно на нем, на SSD голая (обнаженная) винда, правда пробовал еще исправить ошибки из под винды стандартными методами через «свойства» диска, но ничего не запускается, окно сразу закрывается, пробовал еще утилиту CHKDSK при перезагрузке, она нашла и исправила в томе «I» какие-то файлы, но ничего не имзенилось.

Когда диск не отображается в системе, виндовс работает быстро, без проблем, не тормозит. Иногда после перезагрузки все четыре тома находятся в разделе «другие» со знаком вопроса и ни на что не реагируют.

В журнале событий виндовс такие ошибки и предупреждения:
1.Структура файловой системы на диске повреждена и непригодна к использованию. Запустите программу CHKDSK на томе I: .
2.Драйвер обнаружил ошибку контроллера DeviceHarddisk2DR2.
3.Сбой при запуске службы «AODDriver4.2.0» из-за ошибки. Системе не удается найти указанный путь.
4.Не удалось инициализировать аварийный дамп.
5.Системе не удалось очистить данные журнала транзакций. Возможно повреждение данных.
6. Обнаружена ошибка на устройстве DeviceHarddisk1DR1 во время выполнения операции страничного обмена.
7. Драйвер обнаружил ошибку контроллера DeviceIdeIdePort4.
8. Служба «ASGT» помечена как интерактивная. Однако в конфигурации системы интерактивные службы не допускаются. Возможна неправильная работа службы.
9. Используемый по умолчанию диспетчер ресурсов транзакций на томе P: обнаружил неповторяемую ошибку, и его запуск невозможен. Данные содержат код ошибки.

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

Последний раз редактировалось KT 24.04.2015 2:09, всего редактировалось 1 раз.
Поправил форматирование текста
 
mol61

Member

Статус: В сети
Регистрация: 15.06.2010
Откуда: Калуга
Фото: 19

UltroZero Как много слов… Подыхает пациент. СМАРТ смотри и Viktoria прогони тест поверхности. По результатам будем посмотреть.

Добавлено спустя 3 минуты 17 секунд:

UltroZero писал(а):

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

SeaTools имеет опцию тотальной зачистки. Она меня один раз спасла, точнее такого пациента. Софт-бэды вылечились.


_________________
Лужу, паяю, не шалю, никого не трогаю, починяю примус (ЭВМ). Я не фанат INTEL, я просто не люблю AMD.

Последний раз редактировалось mol61 11.04.2015 13:00, всего редактировалось 1 раз.

 
Sania.

Member

Статус: Не в сети
Регистрация: 22.12.2012
Фото: 1

Да не, надо смарт глянуть, всё что написано и правда ничего не даёт узнать о состоянии пациента.

 
mol61

Member

Статус: В сети
Регистрация: 15.06.2010
Откуда: Калуга
Фото: 19

Вот, и спец подключился, щас реанимируем (или закопаем).


_________________
Лужу, паяю, не шалю, никого не трогаю, починяю примус (ЭВМ). Я не фанат INTEL, я просто не люблю AMD.

 
Sania.

Member

Статус: Не в сети
Регистрация: 22.12.2012
Фото: 1

Ну, какой я спец, спец у нас Tomset.

 
mol61

Member

Статус: В сети
Регистрация: 15.06.2010
Откуда: Калуга
Фото: 19

Sania. писал(а):

Ну, какой я спец

Не прибедняйся. Хотя скромность украшает… :oops:
Поциэнт то пропал. Или комп разобрал? :D
У меня у самого только один комп в сеть выйти способен, мобила убогинькая, для инвалидов по зрению и слуху. Но в случае бяды смогу за час собрать и запустить резервный. На работе другое дело, только у меня их три.


_________________
Лужу, паяю, не шалю, никого не трогаю, починяю примус (ЭВМ). Я не фанат INTEL, я просто не люблю AMD.

 
UltroZero

Junior

Статус: Не в сети
Регистрация: 11.04.2015

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

 
Pavel12

Member

Статус: Не в сети
Регистрация: 06.07.2012

Эта та ещё дрянь, даже файлопомойку на ней бы не держал, только под BackUp-файлопомойки положить на полку, что я и сделал :)
Ресурс там, что то мало, всего 2400 часов насчитали в поддержке ;) Ну мне хватит, по 7 часов раз в месяц для снятия бэкапов.


_________________
Смотри-ка какой усатый

Последний раз редактировалось Pavel12 11.04.2015 14:00, всего редактировалось 3 раз(а).

 
ShadovV

Member

Статус: Не в сети
Регистрация: 13.11.2012
Откуда: Майкоп

UltroZero писал(а):

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

Для начала поменяй все sata кабели, или проверь как они в разъемах держатся.


_________________
ASRock Fatal1ty X370 Professional Gaming, AMD Ryzen 7 1700x, Samsung 2x16Gb M378A2K43CB1-CRC@3333MHz, MSI 1080ti Armor OC.

 
UltroZero

Junior

Статус: Не в сети
Регистрация: 11.04.2015

С кабелями все в порядке, до этой проблемы, пока не вырубил кнопкой, было все отлично, я на всякий случай кабеля по перетыкивал, но ничего не поменялось.
Ребята, а что СМАРТ говорит, а то я ничего не понимаю в нем?

 
Sania.

Member

Статус: Не в сети
Регистрация: 22.12.2012
Фото: 1

mol61 писал(а):

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

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

Pavel12 писал(а):

Ресурс там, что то мало, всего 2400 часов насчитали в поддержке

Это бред, вы не так поняли спеки.

UltroZero писал(а):

Ребята, а что СМАРТ говорит, а то я ничего не понимаю в нем?

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

 
silver63rus

Member

Статус: Не в сети
Регистрация: 06.09.2010
Откуда: Самара

Sania. Да, замена кабеля не даст расти показателю CRC ошибок при передаче. Но Вы, похоже, напрочь игнорируете 184 ошибку — ошибку хеш контроллера диска. Которая никак, не связана со 199 ошибкой. И которая, даёт понять , что у диска серьёзные проблемы, и срочно требуется бэкап.

 
Sania.

Member

Статус: Не в сети
Регистрация: 22.12.2012
Фото: 1

Silver63rus как раз может быть связана, если бы на атрибуте 199 было нули, возможно можно было предположить проблему с кэшем или совместимостью с контроллером матери. Там не 184 ошибки, немного меньше 25. Этот диск, после замены кабеля надо было бы прописать нулями. Вот если не поможет, попробовать на другой машине, нет, гарантия.

 
Sumen

Member

Статус: Не в сети
Регистрация: 21.10.2014

UltroZero писал(а):

Информация на нем есть очень важная и

поэтому про чекдиск лучше забыть.
Если действительно ценная, то лучше перестать самостоятельно его ковырять. Максимум, что можно «починить» в домашних условиях на диске с ценными данными — поменять интерфейсный кабель и почистить контакты в гермозону. И все. Остальные действия либо деструктивны, либо усугубляют ситуацию.
При «массовом отказе» (а именно — зависание, запуск чекдиска с последующими BSOD) есть очень большой шанс «ввести диск в ступор», не забывайте, что каждый сбой диск расценивает как единичный и будет пытаться его переназначить. А если у него с «головами» проблемы начались, или царапина на поверхности? То тесты Victoria (которые, в принципе, ничего не покажут, зато драгоценного времени украдут вагон) могут его вполне добить.

Добавлено спустя 36 секунд:

Sania. писал(а):

Этот диск, после замены кабеля надо было бы прописать нулями.

А на данные забить?

 
Sania.

Member

Статус: Не в сети
Регистрация: 22.12.2012
Фото: 1

Sumen писал(а):

А на данные забить?

Если не нужны, да. :-) Я же думаю что тс не идиот и скопировал или скопирует всё нужное.

 
Sumen

Member

Статус: Не в сети
Регистрация: 21.10.2014

Sania. писал(а):

Я же думаю что тс не идиот и скопировал или скопирует всё нужное.

ТС-то не идиот, но:

UltroZero писал(а):

Структура файловой системы на диске повреждена и непригодна к использованию.

И если это не кабель, то…

 
Sania.

Member

Статус: Не в сети
Регистрация: 22.12.2012
Фото: 1

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

 
Sumen

Member

Статус: Не в сети
Регистрация: 21.10.2014

Sania. писал(а):

Надо диагностировать, что угодно может быть.

Поддерживаю:

Sumen писал(а):

Максимум, что можно «починить» в домашних условиях на диске с ценными данными — поменять интерфейсный кабель и почистить контакты в гермозону.

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

UltroZero писал(а):

Информация на нем есть очень важная

Хотя, если стоит вопрос про «отправлять по гарантии», то ценность информации явно меньше стоимости нового диска.
UltroZero, Вы же в курсе, что данные бесплатно не восстанавливают? ;) Даже по гарантии

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Лаборатория

Новости

Ошибка СУБД Microsoft SQL Server Native Client 11.0: «Журнал транзакций для базы данных переполнен». Причина: «LOG_BACKUP». HRESULT=80040E14, SQLSrvr: SQLSTATE=42000, state=2, Severity=11, native=9002, line=1

Описание ошибки:
В это публикации будет рассмотрена не только сама ошибка СУБД о переполнении журнала транзакций, но описание того, как уменьшить (очистить, сократить) журнал транзакций.

Найденные решения:

1C 8 ошибка СУБД SQL, журнал транзакций для базы данных переполнен

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

Рассмотрим 

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

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

Запускается SQL Server Management Studio. В ветке «Базы данных» дерева «Обозревателя объектов» находим базу данных по названию. Вызываем контекстное меню правой кнопкой мыши и в нем выбираем пункт «Создать запрос» и вводим текст:

BACKUP LOG [name_db] WITH TRUNCATE_ONLY
go
DBCC SHRINKFILE ([log_file])
go

, где [name_db] — имя (название) базы данных СУБД. В примере — «Бухгалтерия»;
, а [log_file] имя или путь к файлу журнала (лога) транзакций формата *.ldf. О том, как определить его название и местоположение см. ниже, в примере — «Бухгалтерия_log.ldf»

1С 8, ошибка, журнал транзакций для базы данных переполнен, как уменьшить, сократить журнал

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

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

1С 8, руководство, инструкция, как сократить, уменьшить, файл, лог журнала транзакций SQL

В открывшемся окне «Свойств базы данных» переходим на страницу «Файлы». И смотрим «Путь» и «Имя файла» журнала транзакций в колонках таблицы «Файлы базы данных». Эти сведения и используем для заполнения в запросе для параметра [log_file].

1С 8, разрастается журнал транзакций *_log.ldf, MS SQL, как уменьшить, сократить

Так же можно на будущее настроить автоматическое сжатие журнала транзакций. Это изложено в документации на сайте SQL: настройка авторасширения и автосжатия в SQL Server

Оцените, помогло ли Вам предоставленное описание решения ошибки?




© www.azhur-c.ru 2014-2020. Все права защищены. Использование текстов и изображений с данной страницы без письменного разрешения владельца запрещено. При использовании материалов с данной страницы обязательно указание ссылки на данную страницу.

04-08-2021

Журавлев А.С.
(Сайт azhur-c.ru)

В MS SQL очистка журнала транзакций необходима в том случае, если настроена полная модель восстановления базы данных. Если журнал транзакций переполнился, то ваша база данных откажется работать и будет выдавать ошибку: «журнал транзакций для базы данных заполнен». Почему такое происходит и как этого избежать? Рассмотрим два решения, которые помогут быстро устранить ошибку и продолжить работу с базой.

Увеличиваем размер журнала транзакций.

Запускаем SQL Server Management Studio, заходим в свойства базы и выбираем пункт [Файлы].

img 2018 02 22 14 45 12

Для типа файла «Журнал» увеличиваем максимальный размера файла для авторасширения.

img 2018 03 07 11 29 12

Сжимаем файл журнала транзакций.

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

Запускаем SQL Server Management Studio, заходим в свойства базы и выбираем пункт [Параметры]. Модель восстановления выбираем «Простая» и нажимаем ОК.

img 2018 03 07 17 15 27

Далее правой клавишей мышки по базе и выбираем из контекстного меню [Задачи] — [Сжать] — [Файлы]

img 2018 03 07 17 18 26

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

img 2018 03 07 17 28 26

Теперь нужно вернуться в свойства базы к пункту [Параметры] и переключить модель восстановления на «Полная».

  • Remove From My Forums
  • Вопрос

  • taskhostex 6515 не удалось открыть файл «C:UsersН.А.АндрееваAppDataLocalMicrosoftWindowsWebCacheWebCacheV01.dat»
    только для чтения, системная ошибка  

    32 (0x00000020) «процесс не может получить доступ к файлу, так как файл  занят другим процессом.». Операция открытия
    файла не может быть выполнена, ошибка:  
    -1032 (0xfffffbf8)

    как с этим бороться ?

Ответы

  • Ничего особенного в работе без дисков нет, информация пользователей будет размещаться в их профилях, на диске C:Users. Отключить диски профилей пользователей можно через свойства коллекции, очистив соответствующий чекбокс. 

    • Помечено в качестве ответа

      13 марта 2013 г. 6:58

Содержание:

1.       Журнал транзакций в 1С

2.       Ошибка Журнал транзакций переполнен  

1.    Журнал транзакций в 1С

В данной статье будет описана возможная ошибка в системе 1С, а именно – в СУБД, которая связана с переполнением журнала транзакций в 1С. Далее будут приведены возможные методы устранения данной неполадки, среди которых уменьшение журнала транзакций для базы данных.

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

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

1.     Восстановление транзакций;

2.     Восстановление транзакций, которые не были окончены;

3.     Поддерживать повторения транзакций;

4.     Производить восстановление базы данных, из-за системного сбоя.  


2.    Ошибка Журнал транзакций переполнен

В СУБД 1С может появляться ошибка, которая содержит следующий текст: «Журнал транзакций для базы данных «zup» заполнен». Также, в тексте ошибки может приводиться столбец и таблица, к которым следует обратиться.

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

Рассмотрим два возможных способа для устранения ошибки «Журнал транзакций для базы данных переполнен»:

·        В первом способе будем следовать такому алгоритму:

1.     Проверить наличие и величину свободного места на дисках, в случае, когда места нет – соответственно, нет места и для записи лога;

2.     Если место есть, то ошибка «Журнал транзакций для базы переполнен» является ошибкой MicrosoftSQLServer, то есть – лог с транзакциями был полностью заполнен, но не очищен. Это можно исправить при помощи очистки, которая является стандартной, но эта опция не всегда может помочь устранить неполадку. В случае, если она не сработала – стоит использовать следующий код SQLServer:

код SQLServer

В данном коде: 20 – это величина лога в Мб, а «myDataBase» — название нужной базы с данными.

·        Следующий способ – это сразу приступить к уменьшению размера журнала с транзакциями.

Так как с журналом транзакций в SQLServer часто проводится много довольно весомых манипуляций, которые связаны с модификацией данных в СУБД, то такие действия приводят к увеличению размеров файловых данных внутри журнала с транзакциями. В данном случае очень важно вовремя удалять не нужные записи из журнала транзакций SQL, в связи с созданием более актуальных. Если не проводить удаления вовремя, то прошлые файлы в журнале транзакций начинают заполнять всё место на диске и далее станет невозможно работать с СУБД.

Так что, в своём роде, данный способ – это предотвращение ошибки «Журнал транзакций переполнен» в 1С.

В таком случае, удаляем те записи, которые больше не нужны, при помощи команды «BACKUPLOG», следующий шаг – это сделать меньше файл из журнала транзакций MSSQL– при помощи команды «DBCCSHRINKFILE». Таким образом, нужный нам код, для предотвращения ошибки, будет выглядеть таким образом:

Предотвращение ошибки Журнал транзакций переполнен

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

Специалист компании «Кодерлайн»

Айдар Фархутдинов

title description author ms.author ms.date ms.service ms.subservice ms.topic helpviewer_keywords

Troubleshoot full transaction log error 9002

Learn about possible responses to a full transaction log in SQL Server and how to avoid the problem in the future.

MashaMSFT

mathoma

09/14/2021

sql

supportability

troubleshooting

logs [SQL Server], full

troubleshooting [SQL Server], full transaction log

9002 (Database Engine error)

transaction logs [SQL Server], truncation

back up transaction logs [SQL Server], full logs

transaction logs [SQL Server], full log

full transaction logs [SQL Server]

Troubleshoot a Full Transaction Log (SQL Server Error 9002)

[!INCLUDE SQL Server]

Option 1: Run the steps directly in an executable notebook via Azure Data Studio

[!NOTE]
Before attempting to open this notebook, check that Azure Data Studio is installed on your local machine. To install, go to Learn how to install Azure Data Studio.

[!div class=»nextstepaction»]
Open Notebook in Azure Data Studio

Option 2: Follow the step manually

This topic discusses possible responses to a full transaction log and suggests how to avoid it in the future.

When the transaction log becomes full, [!INCLUDEssDEnoversion] issues a 9002 error. The log can fill when the database is online, or in recovery. If the log fills while the database is online, the database remains online but can only be read, not updated. If the log fills during recovery, the [!INCLUDEssDE] marks the database as RESOURCE PENDING. In either case, user action is required to make log space available.

[!NOTE]
This article is focused on SQL Server. For more specific information on this error in Azure SQL Database and Azure SQL Managed Instance, see Troubleshooting transaction log errors with Azure SQL Database and Azure SQL Managed Instance. Azure SQL Database and Azure SQL Managed Instance are based on the latest stable version of the Microsoft SQL Server database engine, so much of the content is similar though troubleshooting options and tools may differ.

Common reasons for a full transaction log

The appropriate response to a full transaction log depends on what conditions caused the log to fill. Common causes include:

  • Log not being truncated
  • Disk volume is full
  • Log size is set to a fixed maximum value or autogrow is disabled
  • Replication or availability group synchronization that is unable to complete

How to resolve a full transaction log

The following specific steps will help you find the reason for a full transaction log and resolve the issue.

1. Truncate the Log

A very common solution to this problem is to ensure transaction log backups are performed for your database which will ensure the log is truncated. If no recent transaction log history is indicated for the database with a full transaction log, the solution to the problem is straightforward: resume regular transaction log backups of the database.

Log truncation explained

There’s a difference between truncating a transaction log and shrinking a transaction log. Log Truncation occurs normally during a transaction log backup, and is a logical operation which removes committed records inside the log, whereas log shrinking reclaims physical space on the file system by reducing the file size. Log truncation occurs on a virtual-log-file (VLF) boundary, and a log file may contain many VLFs. A log file can be shrunk only if there’s empty space inside the log file to reclaim. Shrinking a log file alone can’t solve the problem of a full log file, instead, you must discover why the log file is full and can’t be truncated.

[!WARNING]
Data that is moved to shrink a file can be scattered to any available location in the file. This causes index fragmentation and might slow the performance of queries that search a range of the index. To eliminate the fragmentation, consider rebuilding the indexes on the file after shrinking. For more information, see Shrink a database.

What is preventing log truncation?

To discover what is preventing log truncation in a given case, use the log_reuse_wait and log_reuse_wait_desc columns of the sys.databases catalog view. For more information, see sys.databases (Transact-SQL). For descriptions of factors that can delay log truncation, see The Transaction Log (SQL Server).

The following set of T-SQL commands will help you identify if a database transaction log isn’t truncated and the reason for it. The following script will also recommend steps to resolve the issue:

SET NOCOUNT ON
DECLARE @SQL VARCHAR (8000), @log_reuse_wait tinyint, @log_reuse_wait_desc nvarchar(120), @dbname sysname, @database_id int, @recovery_model_desc varchar (24)


IF ( OBJECT_id (N'tempdb..#CannotTruncateLog_Db') is not null)
BEGIN
    DROP TABLE #CannotTruncateLog_Db
END


--get info about transaction logs in each db. Use a DMV which supports all supported versions

IF ( OBJECT_id (N'tempdb..#dm_db_log_space_usage') is not null)
BEGIN
    DROP TABLE #dm_db_log_space_usage 
END
SELECT * INTO #dm_db_log_space_usage FROM sys.dm_db_log_space_usage where 1=0

DECLARE log_space CURSOR FOR SELECT NAME FROM sys.databases
OPEN log_space 

FETCH NEXT FROM log_space into @dbname

WHILE @@FETCH_STATUS = 0
BEGIN

	set @SQL = '
	insert into #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
	)
	select
	database_id, 
	total_log_size_in_bytes, 
	used_log_space_in_bytes, 
	used_log_space_in_percent, 
	log_space_in_bytes_since_last_backup
	from ' + @dbname +'.sys.dm_db_log_space_usage'

	
	BEGIN TRY  
		exec (@SQL)
	END TRY  

	BEGIN CATCH  
        SELECT ERROR_MESSAGE() AS ErrorMessage;  
	END CATCH;

	FETCH NEXT FROM log_space into @dbname
END

CLOSE log_space 
DEALLOCATE log_space 

--select the affected databases 
SELECT 
    sdb.name as DbName, 
    sdb.log_reuse_wait, sdb.log_reuse_wait_desc, 
    log_reuse_wait_explanation = CASE

        WHEN log_reuse_wait = 1 THEN 'No checkpoint has occurred since the last log truncation, or the head of the log has not yet moved beyond'
        WHEN log_reuse_wait = 2 THEN 'A log backup is required before the transaction log can be truncated.'
        WHEN log_reuse_wait = 3 THEN 'A data backup or a restore is in progress (all recovery models). Please wait or cancel backup'
        WHEN log_reuse_wait = 4 THEN 'A long-running active transaction or a defferred transaction is keeping log from being truncated. You can attempt a log backup to free space or complete/rollback long transaction'
        WHEN log_reuse_wait = 5 THEN 'Database mirroring is paused, or under high-performance mode, the mirror database is significantly behind the principal database. (Full recovery model only)'        
        WHEN log_reuse_wait = 6 THEN 'During transactional replication, transactions relevant to the publications are still undelivered to the distribution database. Investigate the status of agents involved in replication or Changed Data Capture (CDC). (Full recovery model only.)'        

        WHEN log_reuse_wait = 7 THEN 'A database snapshot is being created. This is a routine, and typically brief, cause of delayed log truncation.'
        WHEN log_reuse_wait = 8 THEN 'A transaction log scan is occurring. This is a routine, and typically a brief cause of delayed log truncation.'
        WHEN log_reuse_wait = 9 THEN 'A secondary replica of an availability group is applying transaction log records of this database to a corresponding secondary database. (Full recovery model only.)'
        WHEN log_reuse_wait = 13 THEN 'If a database is configured to use indirect checkpoints, the oldest page on the database might be older than the checkpoint log sequence number (LSN).'
        WHEN log_reuse_wait = 16 THEN 'An In-Memory OLTP checkpoint has not occurred since the last log truncation, or the head of the log has not yet moved beyond a VLF.'
    ELSE 'None' END,

    sdb.database_id,
    sdb.recovery_model_desc,
    lsu.used_log_space_in_bytes/1024 as Used_log_size_MB,
	lsu.total_log_size_in_bytes /1024 as Total_log_size_MB,
    100 - lsu.used_log_space_in_percent as Percent_Free_Space
INTO #CannotTruncateLog_Db
FROM sys.databases AS sdb INNER JOIN #dm_db_log_space_usage lsu ON sdb.database_id = lsu.database_id
WHERE log_reuse_wait > 0

SELECT * FROM #CannotTruncateLog_Db 


DECLARE no_truncate_db CURSOR FOR
    SELECT log_reuse_wait, log_reuse_wait_desc, DbName, database_id, recovery_model_desc FROM #CannotTruncateLog_Db;


OPEN no_truncate_db

FETCH NEXT FROM no_truncate_db into @log_reuse_wait, @log_reuse_wait_desc, @dbname, @database_id, @recovery_model_desc

WHILE @@FETCH_STATUS = 0
BEGIN
    if (@log_reuse_wait > 0)
        select '-- ''' + @dbname +  ''' database has log_reuse_wait = ' + @log_reuse_wait_desc + ' --'  as 'Individual Database Report'


    if (@log_reuse_wait = 1)
    BEGIN
        select 'Consider running the checkpoint command to attempt resolving this issue or further t-shooting may be required on the checkpoint process. Also, examine the log for active VLFs at the end of file' as Recommendation
        select 'USE ''' + @dbname+ '''; CHECKPOINT' as CheckpointCommand
        select 'select * from sys.dm_db_log_info(' + CONVERT(varchar,@database_id)+ ')' as VLF_LogInfo
    END
    else if (@log_reuse_wait = 2)
    BEGIN
        select 'Is '+ @recovery_model_desc +' recovery model the intended choice for ''' + @dbname+ ''' database? Review recovery models and determine if you need to change it. https://learn.microsoft.com/sql/relational-databases/backup-restore/recovery-models-sql-server' as RecoveryModelChoice
        select 'To truncate the log consider performing a transaction log backup on database ''' + @dbname+ ''' which is in ' + @recovery_model_desc +' recovery model. Be mindful of any existing log backup chains that could be broken' as Recommendation
        select 'BACKUP LOG [' + @dbname + '] TO DISK = ''some_volume:some_folder' + @dbname + '_LOG.trn ''' as BackupLogCommand
    END
    else if (@log_reuse_wait = 3)
    BEGIN
        select 'Either wait for or cancel any active backups currently running for database ''' +@dbname+ '''. To check for backups, run this command:' as Recommendation
        select 'select * from sys.dm_exec_requests where command like ''backup%'' or command like ''restore%''' as FindBackupOrRestore
    END
    else if (@log_reuse_wait = 4)
    BEGIN
        select 'Active transactions currently running  for database ''' +@dbname+ '''. To check for active transactions, run these commands:' as Recommendation
        select 'DBCC OPENTRAN (''' +@dbname+ ''')' as 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 from sys.dm_tran_database_transactions dbtran left outer join sys.dm_tran_session_transactions stran on dbtran.transaction_id = stran.transaction_id where database_id = ' + CONVERT(varchar, @database_id) as FindOpenTransAndSession
    END

    else if (@log_reuse_wait = 5)
    BEGIN
        select 'Database Mirroring for database ''' +@dbname+ ''' is behind on synchronization. To check the state of DBM, run the commands below:' as Recommendation
        select 'select db_name(database_id), mirroring_state_desc, mirroring_role_desc, mirroring_safety_level_desc from sys.database_mirroring where mirroring_guid is not null and mirroring_state <> 4 and database_id = ' + convert(sysname, @database_id)  as CheckMirroringStatus
        
        select 'Database Mirroring for database ''' +@dbname+ ''' may be behind: check unsent_log, send_rate, unrestored_log, recovery_rate, average_delay in this output' as Recommendation
        select 'exec msdb.sys.sp_dbmmonitoraddmonitoring 1; exec msdb.sys.sp_dbmmonitorresults ''' + @dbname+ ''', 5, 0; waitfor delay ''00:01:01''; exec msdb.sys.sp_dbmmonitorresults ''' + @dbname+ '''; exec msdb.sys.sp_dbmmonitordropmonitoring'   as CheckMirroringStatusAnd
    END

    else if (@log_reuse_wait = 6)
    BEGIN
        select 'Replication transactions still undelivered from publisher database ''' +@dbname+ ''' to Distribution database. Check the oldest non-distributed replication transaction. Also check if the Log Reader Agent is running and if it has encoutered any errors' as Recommendation
        select 'DBCC OPENTRAN  (''' + @dbname + ''')' as CheckOldestNonDistributedTran
        select 'select top 5 * from distribution..MSlogreader_history where runstatus in (6, 5) or error_id <> 0 and agent_id = find_in_mslogreader_agents_table  order by time desc ' as LogReaderAgentState
    END
    
    else if (@log_reuse_wait = 9)
    BEGIN
        select 'Always On transactions still undelivered from primary database ''' +@dbname+ ''' to Secondary replicas. Check the Health of AG nodes and if there is latency is Log block movement to Secondaries' as Recommendation
        select 'select availability_group=cast(ag.name as varchar(30)), primary_replica=cast(ags.primary_replica as 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, ag.health_check_timeout, automated_backup_preference_desc=cast(ag.automated_backup_preference_desc as varchar(10))  from sys.availability_groups ag join sys.dm_hadr_availability_group_states ags on ag.group_id=ags.group_id' as CheckAGHealth
        select 'SELECT  group_name=cast(arc.group_name as varchar(30)), replica_server_name=cast(arc.replica_server_name as varchar(30)), node_name=cast(arc.node_name as varchar(30)),role_desc=cast(ars.role_desc as varchar(30)), ar.availability_mode_Desc, operational_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 as varchar(30)), synchronization_health_desc=cast(ars.synchronization_health_desc as varchar(30)), ars.last_connect_error_number, last_connect_error_description=cast(ars.last_connect_error_description as varchar(30)), ars.last_connect_error_timestamp, primary_role_allow_connections_desc=cast(ar.primary_role_allow_connections_desc as varchar(30)) from sys.dm_hadr_availability_replica_cluster_nodes arc join sys.dm_hadr_availability_replica_cluster_states arcs on arc.replica_server_name=arcs.replica_server_name join sys.dm_hadr_availability_replica_states ars on arcs.replica_id=ars.replica_id join sys.availability_replicas ar on ars.replica_id=ar.replica_id join sys.availability_groups ag on ag.group_id = arcs.group_id and ag.name = arc.group_name ORDER BY cast(arc.group_name as varchar(30)), cast(ars.role_desc as varchar(30))' as CheckReplicaHealth
        select '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, drs.is_suspended, drs.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.database_state_desc as varchar(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.log_send_queue_size, drs.log_send_rate, drs.redo_queue_size, 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, pr.error_type, pr.page_id, pr.page_status, pr.modification_time from sys.dm_hadr_database_replica_cluster_states drcs join sys.dm_hadr_database_replica_states drs on drcs.replica_id=drs.replica_id and drcs.group_database_id=drs.group_database_id left outer join sys.dm_hadr_auto_page_repair pr on drs.database_id=pr.database_id  order by drs.database_id' as LogMovementHealth
        select 'For more information see https://learn.microsoft.com/troubleshoot/sql/availability-groups/error-9002-transaction-log-large' as OnlineDOCResource
    END    
    else if (@log_reuse_wait in (10, 11, 12, 14))
    BEGIN
        select 'This state is not documented and is expected to be rare and short-lived' as Recommendation
    END    
    else if (@log_reuse_wait = 13)
    BEGIN
        select 'The oldest page on the database might be older than the checkpoint log sequence number (LSN). In this case, the oldest page can delay log truncation.' as Finding
        select 'This state should be short-lived, but if you find it is taking a long time, you can consider disabling Indirect Checkpoint temporarily' as Recommendation
        select 'ALTER DATABASE [' +@dbname+ '] SET TARGET_RECOVERY_TIME = 0 SECONDS' as DisableIndirectCheckpointTemporarily
    END    
    else if (@log_reuse_wait = 16)
    BEGIN
        select 'For memory-optimized tables, an automatic checkpoint is taken when transaction log file becomes bigger than 1.5 GB since the last checkpoint (includes both disk-based and memory-optimized tables)' as Finding
        select 'Review https://blogs.msdn.microsoft.com/sqlcat/2016/05/20/logging-and-checkpoint-process-for-memory-optimized-tables-2/' as ReviewBlog
        select 'use ' +@dbname+ ' CHECKPOINT' as RunCheckpoint
    END    

    FETCH NEXT FROM no_truncate_db into @log_reuse_wait, @log_reuse_wait_desc, @dbname, @database_id, @recovery_model_desc

END

CLOSE no_truncate_db
DEALLOCATE no_truncate_db

[!IMPORTANT]
If the database was in recovery when the 9002 error occurred, after resolving the problem, recover the database by using ALTER DATABASE database_name SET ONLINE.

LOG_BACKUP log_reuse_wait

The most common actions you can consider here is to review your database recovery model and backup the transaction log of your database.

Consider the database’s recovery model

The transaction log may be failing to truncate with LOG_BACKUP log_reuse_wait category, because you have never backed it up. In many of those cases, your database is using FULL or BULK_LOGGED recovery model, but you did not back up transaction logs. You should consider each database recovery model carefully: perform transaction log backups on all databases in FULL or BULK LOGGED recovery models to minimize occurrences of error 9002. For more information, see Recovery Models.

Back up the log

Under the FULL or BULK_LOGGED recovery model, if the transaction log has not been backed up recently, backup might be what is preventing log truncation. You must back up the transaction log to allow log records to be released and the log truncated. If the log has never been backed up, you must create two log backups to permit the [!INCLUDEssDE] to truncate the log to the point of the last backup. Truncating the log frees logical space for new log records. To keep the log from filling up again, take log backups regularly and more frequently. For more information, see Recovery Models.

A complete history of all SQL Server backup and restore operations on a server instance is stored in the msdb system database. To review the complete backup history of a database, use the following sample script:

SELECT bs.database_name
, backuptype = CASE 
	WHEN bs.type = 'D' and bs.is_copy_only = 0 THEN 'Full Database'
	WHEN bs.type = 'D' and bs.is_copy_only = 1 THEN 'Full Copy-Only Database'
	WHEN bs.type = 'I' THEN 'Differential database backup'
	WHEN bs.type = 'L' THEN 'Transaction Log'
	WHEN bs.type = 'F' THEN 'File or filegroup'
	WHEN bs.type = 'G' THEN 'Differential file'
	WHEN bs.type = 'P' THEN 'Partial'
	WHEN bs.type = 'Q' THEN 'Differential partial' END + ' Backup'
, bs.recovery_model
, BackupStartDate = bs.Backup_Start_Date
, BackupFinishDate = bs.Backup_Finish_Date
, LatestBackupLocation = bf.physical_device_name
, backup_size_mb = bs.backup_size/1024./1024.
, compressed_backup_size_mb = bs.compressed_backup_size/1024./1024.
, database_backup_lsn -- For tlog and differential backups, this is the checkpoint_lsn of the FULL backup it is based on. 
, checkpoint_lsn
, begins_log_chain
FROM msdb.dbo.backupset bs	
LEFT OUTER JOIN msdb.dbo.backupmediafamily bf ON bs.[media_set_id] = bf.[media_set_id]
WHERE recovery_model in ('FULL', 'BULK-LOGGED')
AND bs.backup_start_date > DATEADD(month, -2, sysdatetime()) --only look at last two months
ORDER BY bs.database_name asc, bs.Backup_Start_Date desc;

A complete history of all SQL Server backup and restore operations on a server instance is stored in the msdb system database. For more information on backup history, see Backup History and Header Information (SQL Server).

Create a transaction log backup

Example of how to back up the log:

BACKUP LOG [dbname] TO DISK = 'some_volume:some_folderdbname_LOG.trn'
  • Back Up a Transaction Log (SQL Server)

  • xref:Microsoft.SqlServer.Management.Smo.Backup.SqlBackup%2A (SMO)

[!IMPORTANT]
If the database is damaged, see Tail-Log Backups (SQL Server).

ACTIVE_TRANSACTION log_reuse_wait

The steps to troubleshoot ACTIVE_TRANSACTION reason include discovering the long running transaction and resolving it (in some case using the KILL command to do so).

Discover long-running transactions

A very long-running transaction can cause the transaction log to fill. To look for long-running transactions, use one of the following:

  • sys.dm_tran_database_transactions.

This dynamic management view returns information about transactions at the database level. For a long-running transaction, columns of particular interest include the time of the first log record (database_transaction_begin_time), the current state of the transaction (database_transaction_state), and the log sequence number (LSN) of the begin record in the transaction log (database_transaction_begin_lsn).

  • DBCC OPENTRAN.
    This statement lets you identify the user ID of the owner of the transaction, so you can potentially track down the source of the transaction for a more orderly termination (committing it rather than rolling it back).
Kill a transaction

Sometimes you just have to end the transaction; you may have to use the KILL statement. Please use this statement very carefully, especially when critical processes are running that you don’t want to kill. For more information, see KILL (Transact-SQL)

AVAILABILITY_REPLICA log_reuse_wait

When transaction changes at primary Availability replica are not yet hardened on the secondary replica, the transaction log on the primary replica cannot be truncated. This can cause the log to grow, and can occur whether the secondary replica is set for synchronous or asynchronous commit mode. For information on how to troubleshoot this type of issue see Error 9002. The transaction log for database is full due to AVAILABILITY_REPLICA error

CHECKPOINT log_reuse_wait

No checkpoint has occurred since the last log truncation, or the head of the log has not yet moved beyond a virtual log file (VLF). (All recovery models)

This is a routine reason for delaying log truncation. If delayed, consider executing the CHECKPOINT command on the database or examining the log VLFs.

USE dbname; CHECKPOINT
select * from sys.dm_db_log_info(db_id('dbname'))

For more information on log_reuse_wait factors

For more details see Factors that can delay log truncation

2. Resolve full disk volume

In some situations the disk volume that hosts the transaction log file may fill up. You can take one of the following actions to resolve the log-full scenario that results from a full disk:

Free disk space

You might be able to free disk space on the disk drive that contains the transaction log file for the database by deleting or moving other files. The freed disk space allows the recovery system to enlarge the log file automatically.

Move the log file to a different disk

If you cannot free enough disk space on the drive that currently contains the log file, consider moving the file to another drive with sufficient space.

[!IMPORTANT]
Log files should never be placed on compressed file systems.

See Move Database Files for information on how to change the location of a log file.

Add a log file on a different disk

Add a new log file to the database on a different disk that has sufficient space by using ALTER DATABASE <database_name> ADD LOG FILE. Multiple log files for a single database should be considered a temporary condition to resolve a space issue, not a long-term condition. Most databases should only have one transaction log file. Continue to investigate the reason why the transaction log is full and cannot be truncated. Consider adding temporary additional transaction log files as an advanced troubleshooting step.

For more information see Add Data or Log Files to a Database.

Utility script for recommended actions

These steps can be partly automated by running this T-SQL script which will identify logs files that using a large percentage of disk space and suggest actions:

DECLARE @log_reached_disk_size BIT = 0

SELECT 
    name LogName, 
    physical_name, 
    CONVERT(bigint, size)*8/1024 LogFile_Size_MB, 
    volume_mount_point, 
    available_bytes/1024/1024 Available_Disk_space_MB,
    (CONVERT(bigint, size)*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)
WHERE mf.[type_desc] = 'LOG'
    AND (CONVERT(bigint, size)*8.0/1024)/(available_bytes/1024/1024 )*100 > 90 --log is 90% of disk drive
ORDER BY size DESC

if @@ROWCOUNT > 0
BEGIN

    set @log_reached_disk_size = 1

    -- Discover if any logs have are close to or completely filled disk volume they reside on.
    -- Either Add A New File To A New Drive, Or Shrink Existing File
    -- If Cannot Shrink, Go To Cannot Truncate Section

    DECLARE @db_name_filled_disk sysname, @log_name_filled_disk sysname, @go_beyond_size bigint 
    
    DECLARE log_filled_disk CURSOR FOR
        SELECT 
            db_name(mf.database_id),
            name
        FROM sys.master_files mf CROSS APPLY sys.dm_os_volume_stats (mf.database_id, file_id)
        WHERE mf.[type_desc] = 'LOG'
            AND (convert(bigint, size)*8.0/1024)/(available_bytes/1024/1024 )*100 > 90 --log is 90% of disk drive
        ORDER BY size desc

    OPEN log_filled_disk

    FETCH NEXT FROM log_filled_disk into @db_name_filled_disk , @log_name_filled_disk

    WHILE @@FETCH_STATUS = 0
    BEGIN
        
        SELECT 'Transaction log for database "' + @db_name_filled_disk + '" has nearly or completely filled disk volume it resides on!' AS Finding
        SELECT 'Consider using one of the below commands to shrink the "' + @log_name_filled_disk +'" transaction log file size or add a new file to a NEW volume' AS Recommendation
        SELECT 'DBCC SHRINKFILE(''' + @log_name_filled_disk + ''')' AS Shrinkfile_Command
        SELECT '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 + '_NEW.LDF'', SIZE = 81920KB , FILEGROWTH = 65536KB )' AS AddNewFile
        SELECT 'If shrink does not reduce the file size, likely it is because it has not been truncated. Please review next section below. See https://learn.microsoft.com/sql/t-sql/database-console-commands/dbcc-shrinkfile-transact-sql' AS TruncateFirst
        SELECT 'Can you free some disk space on this volume? If so, do this to allow for the log to continue growing when needed.' AS FreeDiskSpace




         FETCH NEXT FROM log_filled_disk into @db_name_filled_disk , @log_name_filled_disk

    END

    CLOSE log_filled_disk
    DEALLOCATE log_filled_disk

END

3. Change log size limit or enable Autogrow

Error 9002 can be generated if the transaction log size has been set to an upper limit or Autogrow is not allowed. In this case, enabling autogrow or increasing the log size manually can help resolve the issue. Use this T-SQL command to find such log files and follow the recommendations provided:

SELECT DB_NAME(database_id) DbName,
       name LogName,
       physical_name,
       type_desc ,
       CONVERT(bigint, SIZE)*8/1024 LogFile_Size_MB ,
       CONVERT(bigint,max_size)*8/1024 LogFile_MaxSize_MB ,
       (SIZE*8.0/1024)/(max_size*8.0/1024)*100 percent_full_of_max_size,
       CASE WHEN growth = 0 THEN 'AUTOGROW_DISABLED' ELSE 'Autogrow_Enabled' END as AutoGrow
FROM sys.master_files
WHERE file_id = 2
    AND (SIZE*8.0/1024)/(max_size*8.0/1024)*100 > 90
    AND max_size not in (-1, 268435456)
    OR growth = 0

if @@ROWCOUNT > 0
BEGIN
    DECLARE @db_name_max_size sysname, @log_name_max_size sysname, @configured_max_log_boundary bigint, @auto_grow int
    
    DECLARE reached_max_size CURSOR FOR
        SELECT db_name(database_id),
               name,
               CONVERT(bigint, SIZE)*8/1024,
               growth
        FROM sys.master_files
        WHERE file_id = 2
            AND ( (SIZE*8.0/1024)/(max_size*8.0/1024)*100 > 90
            AND max_size not in (-1, 268435456)
            OR growth = 0 )


    OPEN reached_max_size

    FETCH NEXT FROM reached_max_size into @db_name_max_size , @log_name_max_size, @configured_max_log_boundary, @auto_grow 

    WHILE @@FETCH_STATUS = 0
    BEGIN
        IF @auto_grow = 0
          BEGIN
            SELECT 'The database "' + @db_name_max_size+'" contains a log file "' + @log_name_max_size + '" whose autogrow has been DISABLED' as Finding
            SELECT 'Consider enabling autogrow or increasing file size via these ALTER DATABASE commands' as Recommendation
            SELECT 'ALTER DATABASE ' + @db_name_max_size + ' MODIFY FILE ( NAME = N''' + @log_name_max_size + ''', FILEGROWTH = 65536KB)' as AutoGrowth
          END
        ELSE
          BEGIN
            SELECT 'The database "' + @db_name_max_size+'" contains a log file "' + @log_name_max_size + '" whose max limit is set to ' + convert(varchar(24), @configured_max_log_boundary) + ' MB and this limit has been reached!' as Finding
            SELECT 'Consider using one of the below ALTER DATABASE commands to either change the log file size or add a new file' as Recommendation
          END
        
        SELECT 'ALTER DATABASE ' + @db_name_max_size + ' MODIFY FILE ( NAME = N''' + @log_name_max_size + ''', MAXSIZE = UNLIMITED)' as UnlimitedSize
        SELECT 'ALTER DATABASE ' + @db_name_max_size + ' MODIFY FILE ( NAME = N''' + @log_name_max_size + ''', MAXSIZE = something_larger_than_' + CONVERT(varchar(24), @configured_max_log_boundary) +'MB )' as IncreasedSize
        SELECT '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 )' as AddNewFile

        FETCH NEXT FROM reached_max_size into @db_name_max_size , @log_name_max_size, @configured_max_log_boundary, @auto_grow

    END

    CLOSE reached_max_size
    DEALLOCATE reached_max_size
END
ELSE
    SELECT 'Found no files that have reached max log file size' as Findings

Increase log file size or enable Autogrow

If space is available on the log disk, you can increase the size of the log file. The maximum size for log files is two terabytes (TB) per log file.

If autogrow is disabled, the database is online, and sufficient space is available on the disk, do either of these:

  • Manually increase the file size to produce a single growth increment. These are general recommendations on log size growth and size.
  • Turn on autogrow by using the ALTER DATABASE statement to set a non-zero growth increment for the FILEGROWTH option. See Considerations for the autogrow and autoshrink settings in SQL Server

[!NOTE]
In either case, if the current size limit has been reached, increase the MAXSIZE value.

See also

ALTER DATABASE (Transact-SQL)
Manage the Size of the Transaction Log File
Transaction Log Backups (SQL Server)
sp_add_log_file_recover_suspect_db (Transact-SQL)
MSSQLSERVER_9002
How a log file structure can affect database recovery time — Microsoft Tech Community

При обновлении бухгалтерии, на этапе сохранения, получил следующую ошибку:

Каталог не обнаружен ‘v8srvr://sql/acc_main/configsave/e0666db2-45d6-49b4-a200-061c6ba7d569.6b9d6525-ee94-4e13-b73d-82d3e8e8441d’

по причине: Каталог не обнаружен ‘ConfigSavee0666db2-45d6-49b4-a200-061c6ba7d569.6b9d6525-ee94-4e13-b73d-82d3e8e8441d’

по причине: Ошибка СУБД: Microsoft SQL Server Native Client 11.0: Журнал транзакций для базы данных «acc_main» переполнен. Причина: «LOG_BACKUP». HRESULT=80040E14, SQLSrvr: SQLSTATE=42000, state=2, Severity=11, native=9002, line=1

Идем на сервер и первым делом проверяем место на дисках,

А оно закончилось ) нужно потом почистить хард или увеличивать объем, а пока порежем лог

Открываем SQL Server Management Studio

Это ошибка Microsoft SQL Server — переполняется лог транзакций и не очищается. Урезать его возможно различными способами, в том числе и с помощью стандартной оснастки, но не всегда данная операция получается, и размер файла лога остается прежним. Как вариант предлагаю следующее решение из двух строчек( где acc_main — название базы Бух)

Код SQL

 USE acc_main
ALTER DATABASE acc_main SET RECOVERY SIMPLE
DBCC SHRINKFILE (acc_main, 50);
ALTER DATABASE acc_main SET RECOVERY FULL

Результат выполнения:

Тоже самое можно сделать вручную:

Шаг 1. Установить модель восстановления Простая (Simple). Правой кнопкой на базе — Свойства(Properties) — Параметры(Options) — 4-й сверху пункт Модель восстановления(Recovery model) — Простая(Simple) — OK.

Шаг 2. Выполнить шринк (сжатие) лога транзакций. Правой кнопкой на базе — Задачи(Tasks) — Сжать(Shrink) — Файлы(Files) — установить Тип файла(File type) — Журнал(Log) — в Операция сжатия(Shrink action) — выбрать Реорганизовать страницы, перед тем осводить неиспользуемое место(Reorganize pages before releseasing unused space) — Сжать файл (Shrink file to) — указать приемлемый размер лога.

Шаг 3. Установить модель восстановления Полная(Full). Правой кнопкой на базе — Свойства(Properties) — Параметры(Options) — 4-й сверху пункт Модель восстановления(Recovery model) — Полная(Full) — OK.


В дополнении скажу, что можно сохранить лог в файл и выполнить шринк так(BaseDB — имя базы данных):

Код SQL

 BACKUP LOG BaseDB TO DISK = '<D:BackupBase_Log.trn'
DBCC SHRINKFILE (BaseDB_Log, 20) WITH NO_INFOMSGS

Все )

  • Ошибка журнал изменений тома не активен
  • Ошибка жукова под ржевом
  • Ошибка жесткого диска синий экран
  • Ошибка жесткого диска расположение недоступно
  • Ошибка жесткого диска пс4