Стратегия управления журналом ночных заданий SQL Server - PullRequest
0 голосов
/ 31 июля 2009

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

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

Является ли проблемой (помимо дискового пространства) наличие большого (в основном пустого) журнала транзакций?

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

Предложения

Ответы [ 2 ]

2 голосов
/ 31 июля 2009

Я бы ничего не делал. Или просто ПРОСТО.

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

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

Таким образом, объединяя это, вы будете использовать больше места на диске для полной резервной копии, чем для файла LDF.

0 голосов
/ 31 июля 2009

Я бы оставил его ПОЛНЫМ, и, если нажать толчок, принудительно создавал резервные копии журналов во время ночной работы, чтобы размер журнала был небольшим. Кроме того, это нормально, чтобы сжать журнал, если вам действительно нужно, т.е. он вырос один раз из-за одноразовой операции и не будет расти снова. Проблемы фрагментации более актуальны для файлов данных, файлы журналов имеют совершенно другую структуру и структуру размещения. Только не принимайте привычку постоянно сокращаться.

Я говорю это, потому что, если у вас есть уже есть стратегия восстановления резервной копии, мне кажется глупым увеличивать окно потери данных с «последней резервной копии журнала» до «последней дифференциальной резервной копии» , Мы говорим об изменении с 10-30 минут (типичная частота резервного копирования журнала) на 3-24 часа (типичная дифференциальная частота). Вы не сможете делать дифференциалы так же часто, как резервные копии журналов, потому что дифференциалы увеличиваются в размере (начиная со второго дифференциала после полного, каждый дифференциал по крайней мере больше предыдущего дифференциала). Резервные копии журналов только создают резервную копию журнала с момента последнего резервного копирования, поэтому они остаются относительно постоянными по размеру. Также в режиме SIMPLE вы не сможете выполнить попытку резервного копирования журнала и восстановить все данные в случае сбоя.

Похоже, вы торгуете * на 1011 * лотом * на 1012 * больше, что вы получаете при уменьшении размера файла журнала.

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