У меня была эта проблема раньше.
- У вас большая база данных и небольшой лог-диск. Вы хотите реорганизоваться (по разным причинам).
- При попытке выполнить это для большой фрагментированной таблицы журнал заполняется до тех пор, пока диск журнала не заполнится, а затем команда прерывается.
- Если он находится в простом режиме, другие транзакции могут завершиться неудачей, пока журнал не будет очищен в следующей контрольной точке, а если он находится в полном режиме, другие транзакции могут завершиться неудачей до следующего резервного копирования журнала. Перелива!
- Если вы работаете в полном режиме, вы увеличиваете частоту резервного копирования журнала, но это не помогает избежать проблемы, поскольку реорганизация выполняется в неявной транзакции, журнал не очищается до тех пор, пока эта транзакция не завершится, не прекратится или не будет остановлена.
- И вы ДЕЙСТВИТЕЛЬНО хотите, чтобы реорганизация прошла до конца.
Это немного нелогично, потому что вы знаете, что если вы прервете реорганизацию, она может продолжаться с того места, где она остановилась, просто прерывание фиксирует транзакцию, а не откатывается назад.
Вот что ты делаешь. Это немного долго, но просто.
- Предварительно увеличьте размер файла журнала до сравнительно большого размера, но не до максимального. По сути, вы хотите оставить достаточно места для полезной работы, а также для небольшого роста, если он произойдет, чтобы обычные операции не прекращались.
- Создайте задание для запуска реорганизации индекса («Реорганизация»).
Создайте предупреждение WMI агента («Reorganize Relief Valve») о состоянии производительности.
- Объект: SQLServer: Базы данных
- Счетчик: Процент журнала используется
- Экземпляр: (имя вашей большой базы данных)
- Предупреждение, если счетчик поднимается выше: 80
- Ответ: Выполнить задание («Проверка реорганизации»)
Создать работу («Реорганизовать проверку»)
- В задании проверьте msdb.dbo.sysjobactivity, чтобы увидеть, выполняется ли задание «Реорганизация». И если это ...
- Остановите работу и опросите, пока она не остановится. Это может занять несколько секунд.
- (Если вы находитесь в полном режиме) Запустите задание резервного копирования журнала и подтвердите его завершение.
- Дважды проверьте sys.dm_os_performance_counters, что ваш счетчик свободного места в журнале уменьшился ниже вашего порога.
- Начните задание «Реорганизовать».
Протестируйте все это где-нибудь, даже в изолированной программной среде разработки, чтобы убедиться, что она работает правильно, прежде чем прикреплять ее на свой рабочий сервер.
Вы увидите, что задание «Реорганизация» запускается и начинает заполнять журнал. Когда журнал достигает процента заполнения, он запускает предупреждение WMI (в течение примерно 30 с), которое запускает другое задание, которое видит, что задание «Реорганизация» выполняется и, вероятно, ошибочно. Затем он останавливает «Реорганизацию», выполняет резервное копирование, подтверждает, что свободное место в журнале вернулось к разумному значению, а затем снова запускает задание «Реорганизация», которое выполнит его с того места, где оно остановилось.
Поэтому, как вы можете сделать, причина, по которой вы предварительно изменили размер своего журнала до разумного значения в этом сценарии, состоит в том, чтобы уменьшить число операций увеличения / запуска / задания / остановки / перезапусков, чтобы сделать их более эффективными, а также сохранить достаточно места для случайные наросты, которые не успевают вовремя.
Это своего рода странный сценарий. Я почти уверен, что бы ошибся в этом несколько лет назад, и, очевидно, здесь есть фундаментальные проблемы. Но если вы имеете дело с сотнями серверов, возникнет несколько таких крайних случаев, которые никак не могут быть решены по какой-либо бизнес-причине, кроме как с помощью MacGyvering временного решения, которое выполняет свою работу.
Пока это безопасно, логично, проверено и хорошо документировано, проблем не должно быть.