Этот вопрос, кажется, является распространенным вопросом на большинстве форумов и во всем Интернете, он задается здесь во многих форматах, которые обычно звучат так:

В SQL Server -

• По каким причинам журнал транзакций становится таким большим?
• Почему мой файл журнала такой большой?
• Как можно предотвратить возникновение этой проблемы?
• Что я делаю, когда я нахожусь на правильном пути к основной причине и хочу поместить мой файл журнала транзакций в здоровый размер?

Краткий ответ:

Возможно, у вас либо запущена долго выполняющаяся транзакция (Обслуживание индекса? Удаление или обновление большого пакета?), Либо вы находитесь в режиме восстановления «по умолчанию» (более подробно о том, что подразумевается по умолчанию) Fullи не сделали резервную копию журнала (или не принимаю их достаточно часто).

Если это проблема модели восстановления, простой ответ может быть «Переключиться в Simpleрежим восстановления», если вам не требуется восстановление на определенный момент времени и регулярное резервное копирование журнала. Многие люди, тем не менее, делают свой ответ, не понимая моделей восстановления. Читайте дальше, чтобы понять, почему это важно, а затем решить, что вы делаете. Вы также можете просто начать делать резервные копии журналов и оставаться в процессе Fullвосстановления.

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

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

Основная причина 1/2: непонимание моделей восстановления

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

Хотя этот ответ не является глубоким описанием моделей восстановления SQL Server, тема моделей восстановления имеет решающее значение для этой проблемы.

В SQL Server существует три модели восстановления :

• Full,
• Bulk-Logged а также
• Simple,

Сейчас мы будем игнорировать, Bulk-Loggedскажем, что это гибридная модель, и большинство людей, которые работают в этой модели, не без причины и понимают модели восстановления.

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

Антракт: Восстановление вообще

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

1. Восстановление после сбоя / перезапуска
   Одной из целей файла журнала транзакций является восстановление после сбоя / перезапуска . Для отката и отката работы, которая была выполнена (перемотка вперед / повтор) до сбоя или перезапуска, и работы, которая была начата, но не завершена после сбоя или перезапуска (откат / отмена). Задача журнала транзакций состоит в том, чтобы увидеть, что транзакция началась, но не завершилась (откат или сбой / перезапуск произошли до совершения транзакции). В этой ситуации работа журнала заключается в том, чтобы сказать: «Эй ... это никогда не было закончено, давайте откатимся» во время восстановления. Также работа журнала заключается в том, чтобы увидеть, что вы что-то закончили и что вашему клиентскому приложению сообщили, что оно завершено (даже если оно еще не укреплено в вашем файле данных), и скажите«Эй ... это действительно произошло, давайте свернем его, давайте сделаем так, как думают приложения» после перезагрузки. Сейчас есть и другое, но это главная цель.

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

Модели восстановления

На модели восстановления:

• Простая модель восстановления
  Итак, с помощью приведенного выше введения, проще всего Simple Recoveryсначала поговорить о модели. В этой модели вы говорите SQL Server: «Я согласен, что вы используете файл журнала транзакций для восстановления после сбоя и перезапуска ...» (у вас действительно нет выбора. Найдите свойства ACID, и это должно быстро обрести смысл). «... но как только он вам больше не понадобится для восстановления после сбоя / перезапуска, продолжайте и снова используйте файл журнала».

  SQL Server прослушивает этот запрос в Simple Recovery и сохраняет только ту информацию, которая ему необходима для восстановления после сбоя / перезапуска. Если SQL Server уверен, что он может восстановиться, потому что данные усилены в файл данных (более или менее), то данные, которые были усилены, больше не нужны в журнале и помечаются для усечения, что означает, что они используются повторно.

• Модель полного восстановления
  С помощью Full RecoverySQL Server вы сообщаете, что хотите иметь возможность восстановления до определенного момента времени, если ваш файл журнала доступен или до определенного момента времени, который покрывается резервной копией журнала. В этом случае, когда SQL Server достигает точки, в которой было бы безопасно обрезать файл журнала в Simple Recovery Model, он этого не сделает. Вместо этого Он позволяет файлу журнала продолжать расти и будет продолжать расти, пока вы не создадите резервную копию журнала (или не исчерпаете место на диске с файлом журнала) при нормальных обстоятельствах.

Переход от простого к полному имеет Gotcha.

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

Но следует помнить одно предостережение о полном режиме восстановления: если вы просто переключаетесь в Full Recoveryрежим, но никогда не выполняете первоначальное полное резервное копирование, SQL Server не выполнит ваш запрос на включение в Full Recoveryмодель. Ваш журнал транзакций будет продолжать работать так же, как и Simpleдо тех пор, пока вы не переключитесь на модель полного восстановления и не примете первую Full Backup.

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

Итак, это самая распространенная причина неконтролируемого роста журналов? Ответ: Находясь в режиме полного восстановления без каких-либо резервных копий журнала.

Это происходит все время для людей.

Почему это такая распространенная ошибка?

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

Начальная настройка модели восстановления модели всегда Full Recovery Model- до тех пор, пока кто-то не изменит это. Таким образом, вы можете сказать, что «Модель восстановления по умолчанию» есть Full. Многие люди не знают об этом, и их базы данных работают Full Recovery Modelбез резервных копий журнала, и поэтому файл журнала транзакций намного больше, чем необходимо. Вот почему важно изменить значения по умолчанию, если они не работают для вашей организации и ее потребностей)

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

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

Как узнать, какая частота резервного копирования журнала мне нужна?

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

1. Потребности в восстановлении - надеюсь, это будет первым. Какое количество данных может быть потеряно в случае, если диск с вашим журналом транзакций выйдет из строя или вы получите серьезное повреждение, которое влияет на резервную копию журнала? Если это число не превышает 10-15 минут, то вам нужно делать резервные копии журнала каждые 10-15 минут, конец обсуждения.
2. Рост журналов. Если в вашей организации можно потерять больше данных из-за возможности легко воссоздать этот день, вам может потребоваться резервное копирование журналов гораздо реже, чем через 15 минут. Может быть, с вашей организацией все в порядке каждые 4 часа. Но вы должны посмотреть, сколько транзакций вы генерируете за 4 часа. Позволит ли журналу расти в течение этих четырех часов слишком большой размер файла журнала? Означает ли это, что резервное копирование журналов занимает слишком много времени?

Основная причина 2/2: долгосрочные транзакции

( «Моя модель восстановления в порядке! Журнал продолжает расти! )

Это также может быть причиной неконтролируемого и неограниченного роста бревен. Независимо от модели восстановления, но часто она звучит так: «Но я нахожусь в простой модели восстановления - почему мой журнал продолжает расти ?!»

Причина здесь проста: если SQL использует этот журнал транзакций для целей восстановления, как я описал выше, то он должен вернуться к началу транзакции.

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

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

Что я могу сделать с этими длительными транзакциями?

Вы можете спасти себя здесь:

• Правильно подберите размер файла журнала, чтобы учесть наихудший сценарий - например, обслуживание или известные крупные операции. И когда вы увеличиваете свой лог-файл, вам следует обратиться к этому руководству (и двум ссылкам, которые она отправляет вам) от Кимберли Трипп. Правильный размер здесь очень важен.
• Наблюдая за использованием транзакций. Не запускайте транзакцию на сервере приложений и не начинайте долгие разговоры с SQL Server и рискуйте оставить одну открытую слишком долго.
• Наблюдение за предполагаемыми транзакциями в ваших отчетах DML. Например: UPDATE TableName Set Col1 = 'New Value'это транзакция. Я не помещал BEGIN TRANтуда и не должен, это все еще одна транзакция, которая автоматически фиксируется, когда сделано. Поэтому, если вы выполняете операции с большим количеством строк, рассмотрите возможность группировки этих операций в более управляемые блоки и предоставления времени восстановления журналу. Или выберите правильный размер, чтобы справиться с этим. Или, возможно, посмотрите на изменение моделей восстановления во время окна массовой загрузки.

Эти две причины также применимы к доставке журналов?

Краткий ответ: да. Более длинный ответ ниже.

Вопрос: «Я использую доставку журналов, поэтому мои резервные копии журналов автоматизированы ... Почему я все еще вижу рост журнала транзакций?»

Ответ: читайте дальше.

Что такое доставка журналов?

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

• Задание для резервного копирования журнала на одном сервере,
• работа, чтобы скопировать эту резервную копию журнала и
• задание восстановить его без восстановления ( NORECOVERYили STANDBY) на конечном сервере.

Есть также несколько заданий, которые нужно отслеживать и оповещать, если дела идут не так, как вы запланировали.

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

Общее устранение неполадок с помощью кодов состояния

Есть и другие причины, кроме этих двух, но они являются наиболее распространенными. Независимо от причины: есть способ, которым вы можете проанализировать причину этого необъяснимого роста / отсутствия усечения журнала и увидеть, что это такое.

Запрашивая представление sys.databasesкаталога, вы можете увидеть информацию, описывающую причину, по которой ваш файл журнала может ожидать усечения / повторного использования.

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

• 0 = Ничего
  Как это звучит .. Не стоит ждать

• 1 = контрольная точка
  Ожидание контрольной точки. Это должно произойти, и у вас должно быть все в порядке - но есть некоторые случаи, чтобы искать здесь для последующих ответов или правок.

• 2 = Резервное копирование журнала.
  Вы ожидаете резервного копирования журнала. Либо у вас есть запланированные, и это произойдет в ближайшее время, либо у вас есть первая проблема, описанная здесь, и теперь вы знаете, как ее исправить

• 3 = Активное резервное копирование или восстановление.
  В базе данных выполняется операция резервного копирования или восстановления.

• 4 = Активная транзакция
  Существует активная транзакция, которую необходимо завершить (в любом случае - ROLLBACKили COMMIT), прежде чем можно будет выполнить резервное копирование журнала. Это вторая причина, описанная в этом ответе.

• 5 = Зеркальное отображение базы данных
  Либо зеркало отстает, либо находится под некоторой задержкой в ​​ситуации высокопроизводительного зеркалирования, или по какой-то причине зеркальное приостановление

• 6 = Репликация.
  Могут возникнуть проблемы с репликацией, которые могут вызвать это - например, если агент чтения журнала не работает, база данных думает, что он помечен для репликации, которой больше нет, и по другим причинам. Вы также можете увидеть эту причину, и это совершенно нормально, потому что вы смотрите в нужное время, точно так же, как транзакции потребляются программой чтения журнала.

• 7 = Создание моментального снимка базы данных.
  Вы создаете моментальный снимок базы данных, вы увидите это, если посмотрите на момент, когда создается моментальный снимок.

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

• 9 = вторичная реплика групп доступности AlwaysOn применяет записи журнала транзакций этой базы данных к соответствующей вторичной базе данных. О четком описании пока нет ..

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

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

Сначала сделайте полную резервную копию

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

Если вы заботитесь о восстановлении на момент времени

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

Предположительно ваша база данных находится в FULLрежиме восстановления. Если нет, то убедитесь, что это:

ALTER DATABASE yourdb SET RECOVERY FULL;

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

DECLARE @path NVARCHAR(255) = N'\\backup_share\log\yourdb_' 
  + CONVERT(CHAR(8), GETDATE(), 112) + '_'
  + REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','')
  + '.trn';

BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION;

Обратите внимание, что это \\backup_share\должно быть на другом компьютере, который представляет другое устройство хранения данных. Резервное копирование на один и тот же компьютер (или на другой компьютер, использующий те же базовые диски, или другую виртуальную машину, расположенную на том же физическом хосте) на самом деле не поможет вам, так как, если компьютер взорвется, вы потеряете базу данных и его резервные копии. В зависимости от вашей сетевой инфраструктуры может иметь больше смысла делать резервные копии локально, а затем передавать их в другое место за кулисами; в любом случае вы хотите как можно быстрее убрать их с основного компьютера базы данных.

Теперь, когда у вас запущены регулярные резервные копии журналов, разумно будет сжать файл журнала до чего-то более разумного, чем то, что было создано до сих пор. Это не означает SHRINKFILEповторный запуск до тех пор, пока файл журнала не станет размером 1 МБ - даже если вы часто выполняете резервное копирование журнала, ему все равно необходимо учитывать сумму любых одновременных транзакций, которые могут произойти. События автоматического увеличения файла журнала являются дорогостоящими, поскольку SQL Server должен обнулять файлы (в отличие от файлов данных, когда включена мгновенная инициализация файла), и пользовательские транзакции должны ждать, пока это произойдет. Вы хотите выполнять эту процедуру как можно меньше, и, конечно же, не хотите, чтобы ваши пользователи платили за нее.

Обратите внимание, что вам может потребоваться выполнить резервное копирование журнала дважды, прежде чем станет возможным сокращение (спасибо Роберту).

Итак, вам нужно найти практичный размер для вашего файла журнала. Никто здесь не может сказать вам, что это такое, не зная намного больше о вашей системе, но если вы часто сокращали файл журнала, и он снова рос, хороший водяной знак, вероятно, на 10-50% выше, чем самый большой, на котором он был , Допустим, это составляет 200 МБ, и вы хотите, чтобы все последующие события автоматического увеличения составляли 50 МБ, тогда вы можете настроить размер файла журнала следующим образом:

USE [master];
GO
ALTER DATABASE Test1 
  MODIFY FILE
  (NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB);
GO

Обратите внимание, что если размер файла журнала> 200 МБ, вам может понадобиться сначала выполнить это:

USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO

Если вы не заботитесь о восстановлении на момент времени

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

ALTER DATABASE yourdb SET RECOVERY SIMPLE;

Перевод базы данных в SIMPLEрежим восстановления гарантирует, что SQL Server повторно использует части файла журнала (по существу, постепенно исключая неактивные транзакции), вместо того, чтобы расти, чтобы вести учет всех транзакций (как FULLвосстановление делает до тех пор, пока вы не создадите резервную копию журнала). CHECKPOINTсобытия помогут контролировать журнал и убедиться, что он не должен расти, если вы не генерируете большую активность t-log между CHECKPOINTs.

Затем вы должны быть абсолютно уверены в том, что этот рост журнала действительно произошел из-за ненормального события (скажем, ежегодной весенней уборки или восстановления ваших самых больших показателей), а не из-за обычного ежедневного использования. Если вы сократите файл журнала до смехотворно небольшого размера, а SQL Server просто придется снова увеличить его, чтобы он соответствовал вашей обычной деятельности, что вы получили? Удалось ли вам использовать то дисковое пространство, которое вы освободили, только временно? Если вам нужно немедленное исправление, вы можете выполнить следующее:

USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
-- 200 MB
DBCC SHRINKFILE(yourdb_log, 200);
GO

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

Некоторые вещи, которые вы не хотите делать

• Сделайте резервную копию журнала с помощью TRUNCATE_ONLYопции и затемSHRINKFILE . С одной стороны, эта TRUNCATE_ONLYопция устарела и больше не доступна в текущих версиях SQL Server. Во-вторых, если вы используете FULLмодель восстановления, это разрушит цепочку журналов и потребует новой полной резервной копии.

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

• Используйте опцию «сжать базу данных» . DBCC SHRINKDATABASEи вариант плана обслуживания делать то же самое - плохие идеи, особенно если вам действительно нужно только решить проблему журнала. Выберите файл, который хотите настроить, и отрегулируйте его независимо, используя DBCC SHRINKFILEили ALTER DATABASE ... MODIFY FILE(примеры выше).

• Сократите файл журнала до 1 МБ . Это выглядит заманчиво, потому что, эй, SQL Server позволит мне делать это в определенных сценариях и смотреть на все свободное место! Если ваша база данных не предназначена только для чтения (и вы должны пометить ее как таковую, используя ее ALTER DATABASE), это просто приведет к множеству ненужных событий роста, поскольку журнал должен учитывать текущие транзакции независимо от модели восстановления. Какой смысл временно освобождать это пространство, просто чтобы SQL Server мог вернуть его медленно и мучительно?

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

Быть инициативным

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

Наихудшие возможные настройки - 1 МБ или 10%. Как ни странно, это настройки по умолчанию для SQL Server (на которые я жаловался и просил внести изменения безрезультатно ) - 1 МБ для файлов данных и 10% для файлов журналов. Первое слишком мало в наше время, а второе каждый раз приводит к более длинным и продолжительным событиям (скажем, размер файла журнала составляет 500 МБ, первый рост - 50 МБ, следующий - 55 МБ, следующий - 60,5 МБ и т. д. и т. д. - и при медленном вводе / выводе, поверьте мне, вы действительно заметите эту кривую).

дальнейшее чтение

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

• Пост в блоге, который я написал в 2009 году, когда я увидел несколько постов «Вот как сжать файл журнала» .

• Сообщение в блоге Брент Озар написал четыре года назад, ссылаясь на несколько ресурсов, в ответ на статью журнала SQL Server, которая не должна была быть опубликована .

• Сообщение в блоге Пола Рэндала, объясняющее, почему обслуживание t-log важно и почему вы не должны сокращать свои файлы данных .

• Конечно, у Майка Уолша есть отличный ответ, охватывающий некоторые из этих аспектов, в том числе причины, по которым вы не сможете сразу же сжать файл журнала .

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

Она не показывает индекс реорганизации, но он показывает все DML и DDL различные события: ALTER, CREATE, DROP, триггер включения / выключения, даруй / отменить разрешения, объект переименования.

Отказ от ответственности: я работаю на ApexSQL в качестве инженера службы поддержки

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

• По каким причинам журнал транзакций становится таким большим?

1. Длинная активная транзакция
2. Транзакции с высокой регистрацией, такие как перестройка индекса, реорганизация, массовая вставка, удаление и т. Д.
3. Любой HA, такой как Replication, настроил зеркалирование, которое хранит журнал и не позволяет освободить пространство журнала

• Почему мой файл журнала такой большой?

Проверьте log_reuse_wait_desстолбец c в sys.databasesтаблице, чтобы узнать, что удерживает журналы от усечения:

select name, log_reuse_wait_desc 
from sys.databases

• Как можно предотвратить возникновение этой проблемы?

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

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

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

https://www.brentozar.com/archive/2016/03/my-favorite-system-column-log_reuse_wait_desc/

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