Коллеги, такая проблема - SQL Server 2008, база 50 Gb, модель восстановления - полная.

Есть план обслуживания SQL:

- Проверка целостности;
- Архивация полная;
- Перестроение индексов;
- Обновление статистики;
- Очистка процедурного кэша;

После выполнения этого плана следующий архив журнала транзакций - 70 Gb. Мне кажется многовато.

Что посоветуете?

Шринк?

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

(2) Ну как бы да. Нахрена мне 70 гб мусора.

(3) ну так сделай наоорот...
Сначала переиндексация, потом бекап, потом шринк лога...

(4) Шринк файла лога или truncate самого лога? Если файла, то тут как раз не напрягает. А вот если truncate, то не порвётся ли у меня цепочка архивов в этом случае?

+(5) и truncate_only в 2008 уже не поддерживается

(5) Я сказал шринк. А трункате - ты сам выдумал.

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

А архив никаким образом не зависит от лога, я тебе скажу...
В нём есть только актуальная информация.

(9) Да ладно?! Архив журнала транзакций не зависит от содержимого журнала транзакций при модели восстановления full? Ай да новость.

(10) Так... А матчасть читать - Лукашенку с Януковичем отправим?

если база 7-ка то фулл вообще смысла не имеет ...

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

(13) Информации из BOL тебе будет достаточно?

(14) Конечно, давай.

Вот моя ссылка http://technet.microsoft.com/ru-ru/library/ms191429(v=sql.100).aspx

(12) Врядли у него 50 гб в семерке но не суть , возможность восстановится на любой момент времени имеется только в модели full.

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

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

(12) Это еще почему? Фулл теряет смысл только при изменении конфигурации с реструктуризацией..

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

(19) Ок, я в принципе уже настроил такой план. Посмотрим в выходные, чем это закончится.