Краткий ответ:
Возможно, у вас либо запущена долго выполняющаяся транзакция (Обслуживание индекса? Удаление или обновление большого пакета?), Либо вы находитесь в режиме восстановления «по умолчанию» (более подробно о том, что подразумевается по умолчанию) Full
и не сделали резервную копию журнала (или не принимаю их достаточно часто).
Если это проблема модели восстановления, простой ответ может быть «Переключиться в Simple
режим восстановления», если вам не требуется восстановление на определенный момент времени и регулярное резервное копирование журнала. Многие люди, тем не менее, делают свой ответ, не понимая моделей восстановления. Читайте дальше, чтобы понять, почему это важно, а затем решить, что вы делаете. Вы также можете просто начать делать резервные копии журналов и оставаться в процессе Full
восстановления.
Могут быть и другие причины, но это наиболее распространенные. Этот ответ начинает углубляться в две наиболее распространенные причины и дает вам некоторую справочную информацию о причинах и причинах, а также исследует некоторые другие причины.
Более длинный ответ:
Какие сценарии могут заставить журнал продолжать расти? Причин много, но обычно эти причины имеют следующие две закономерности: неверное понимание моделей восстановления или длительные транзакции. Продолжайте читать для деталей.
Основная причина 1/2: непонимание моделей восстановления
( Находясь в режиме полного восстановления и не делая резервных копий журналов - это самая распространенная причина - подавляющее большинство тех, кто сталкивается с этой проблемой. )
Хотя этот ответ не является глубоким описанием моделей восстановления SQL Server, тема моделей восстановления имеет решающее значение для этой проблемы.
В SQL Server существует три модели восстановления :
Full
,
Bulk-Logged
а также
Simple
,
Сейчас мы будем игнорировать, Bulk-Logged
скажем, что это гибридная модель, и большинство людей, которые работают в этой модели, не без причины и понимают модели восстановления.
Два мы заботимся о и их спутанность являются причиной большинства случаев , когда люди , имеющие эту проблему являются Simple
и Full
.
Антракт: Восстановление вообще
Прежде чем говорить о моделях восстановления: давайте поговорим о восстановлении в целом. Если вы хотите углубиться в эту тему, просто прочитайте блог Пола Рэндала и столько постов на него, сколько захотите. Для этого вопроса, однако:
Восстановление после сбоя / перезапуска
Одной из целей файла журнала транзакций является восстановление после сбоя / перезапуска . Для отката и отката работы, которая была выполнена (перемотка вперед / повтор) до сбоя или перезапуска, и работы, которая была начата, но не завершена после сбоя или перезапуска (откат / отмена). Задача журнала транзакций состоит в том, чтобы увидеть, что транзакция началась, но не завершилась (откат или сбой / перезапуск произошли до совершения транзакции). В этой ситуации работа журнала заключается в том, чтобы сказать: «Эй ... это никогда не было закончено, давайте откатимся» во время восстановления. Также работа журнала заключается в том, чтобы увидеть, что вы что-то закончили и что вашему клиентскому приложению сообщили, что оно завершено (даже если оно еще не укреплено в вашем файле данных), и скажите«Эй ... это действительно произошло, давайте свернем его, давайте сделаем так, как думают приложения» после перезагрузки. Сейчас есть и другое, но это главная цель.
Восстановление точки во времени
Другая цель файла журнала транзакций - предоставить нам возможность восстановления до определенного момента времени из-за «упс» в базе данных или гарантировать точку восстановления в случае аппаратного сбоя. с использованием данных и / или файлов журнала базы данных. Если этот журнал транзакций содержит записи о транзакциях, которые были начаты и завершены для восстановления, SQL Server может и использует эту информацию, чтобы получить базу данных там, где она была до возникновения проблемы. Но это не всегда доступный вариант для нас. Чтобы это работало, у нас должна быть база данных в правильной модели восстановления , и мы должны делать резервные копии журналов .
Модели восстановления
На модели восстановления:
Простая модель восстановления
Итак, с помощью приведенного выше введения, проще всего Simple Recovery
сначала поговорить о модели. В этой модели вы говорите SQL Server: «Я согласен, что вы используете файл журнала транзакций для восстановления после сбоя и перезапуска ...» (у вас действительно нет выбора. Найдите свойства ACID, и это должно быстро обрести смысл). «... но как только он вам больше не понадобится для восстановления после сбоя / перезапуска, продолжайте и снова используйте файл журнала».
SQL Server прослушивает этот запрос в Simple Recovery и сохраняет только ту информацию, которая ему необходима для восстановления после сбоя / перезапуска. Если SQL Server уверен, что он может восстановиться, потому что данные усилены в файл данных (более или менее), то данные, которые были усилены, больше не нужны в журнале и помечаются для усечения, что означает, что они используются повторно.
Модель полного восстановления
С помощью Full Recovery
SQL Server вы сообщаете, что хотите иметь возможность восстановления до определенного момента времени, если ваш файл журнала доступен или до определенного момента времени, который покрывается резервной копией журнала. В этом случае, когда SQL Server достигает точки, в которой было бы безопасно обрезать файл журнала в Simple Recovery Model, он этого не сделает. Вместо этого Он позволяет файлу журнала продолжать расти и будет продолжать расти, пока вы не создадите резервную копию журнала (или не исчерпаете место на диске с файлом журнала) при нормальных обстоятельствах.
Переход от простого к полному имеет Gotcha.
Здесь есть правила и исключения. Подробнее о долгосрочных транзакциях мы поговорим ниже.
Но следует помнить одно предостережение о полном режиме восстановления: если вы просто переключаетесь в Full Recovery
режим, но никогда не выполняете первоначальное полное резервное копирование, SQL Server не выполнит ваш запрос на включение в Full Recovery
модель. Ваш журнал транзакций будет продолжать работать так же, как и Simple
до тех пор, пока вы не переключитесь на модель полного восстановления и не примете первую Full Backup
.
Модель полного восстановления без резервных копий журналов плохая.
Итак, это самая распространенная причина неконтролируемого роста журналов? Ответ: Находясь в режиме полного восстановления без каких-либо резервных копий журнала.
Это происходит все время для людей.
Почему это такая распространенная ошибка?
Почему это происходит постоянно? Потому что каждая новая база данных получает свою первоначальную настройку модели восстановления, глядя на базу данных модели.
Начальная настройка модели восстановления модели всегда Full Recovery Model
- до тех пор, пока кто-то не изменит это. Таким образом, вы можете сказать, что «Модель восстановления по умолчанию» есть Full
. Многие люди не знают об этом, и их базы данных работают Full Recovery Model
без резервных копий журнала, и поэтому файл журнала транзакций намного больше, чем необходимо. Вот почему важно изменить значения по умолчанию, если они не работают для вашей организации и ее потребностей)
Модель полного восстановления со слишком небольшим количеством резервных копий журналов - это плохо.
Здесь вы также можете столкнуться с проблемами, если не будете делать резервные копии журналов достаточно часто.
Резервное копирование журнала в день может звучать нормально, поэтому для восстановления требуется меньше команд восстановления, но, учитывая вышеизложенное, этот файл журнала будет расти и расти до тех пор, пока вы не создадите резервные копии журнала.
Как узнать, какая частота резервного копирования журнала мне нужна?
Вы должны учитывать частоту резервного копирования журнала, имея в виду две вещи:
- Потребности в восстановлении - надеюсь, это будет первым. Какое количество данных может быть потеряно в случае, если диск с вашим журналом транзакций выйдет из строя или вы получите серьезное повреждение, которое влияет на резервную копию журнала? Если это число не превышает 10-15 минут, то вам нужно делать резервные копии журнала каждые 10-15 минут, конец обсуждения.
- Рост журналов. Если в вашей организации можно потерять больше данных из-за возможности легко воссоздать этот день, вам может потребоваться резервное копирование журналов гораздо реже, чем через 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 применяет записи журнала транзакций этой базы данных к соответствующей вторичной базе данных.
О четком описании пока нет ..