Как уменьшить размер архива журнала транзакций, который сильно увеличивается при переиндексации?
Нубский вопрос, помогите пожалуйста.
Есть база 1С (не бейте, дослушайте :)) на 50 Гб, recovery model Full, каждый час архивирование журнала транзакций, каждый вечер реиндексация и обновление статистики.
Архивы логов сразу после индексации получаются размером по 15-20 Гб, дневные архивы логов по 1-2 мегабайта.
Как избавиться от этих огромных архивов (не хранить или не создавать или уменьшить размер) и не "разорвать связь" между архивами журнала транзакций?
1. "каждый час архивирование" - ты каждый час делаешь полный бакап?
2. "сжатие журнала транзакций" - ты бакапишь лог транзакций или реально его транкируешь?
если перестроение индексов реально нужно, то целесообразнее прекращать делать бакапы ночью в некоторый момент, и этот же момент запускать Maintenance Plan в котором прописать перестроение индексов, обновление статистики и создание полного бакапа.
Olgeir: правильно ли я понимаю, полный бэкап после перестроения индексов должен еще начинать новую цепочку логов, иначе в следующий бэкап логов всё равно попадет лог перестроения индексов?
бакап лога транзакций всегда привязан к последнему полному бакапу. у тебя получится что ты перестраиваешь индексы, и обновляешь статистику, эти изменения входят в полный бакап, а бакапы лога транзакций у тебя захватывают только операции пользователей.
грубо говоря, с 9 до 18 рабочий день. делаешь бакапы лога транзанкций с 9 до 18 каждый час. а начиная часов с 19 выполняешь все технические регламентные работы индексации, сбор статистики и тд. после чего делаешь полный бакап.
Olgeir: Я в скуле совсем новичок, прочитал у майкрософта, что есть такой LOG CHAIN, на основании которого вычисляется порция данных, которая должна быть записана в бэкап.
Обычно эту цепочку логов начинает первый полный бэкап, дальнейшие полные бэкапы на неё не влияют, если специально не указать начало новой цепочки логов при полном бэкапе.
В следующий бэкап лога попадет порция транзакций с последнего момента бэкапа лога по последнюю завершенную транзакцию.
Не правильно?
Olgeir: На практике не получилось так, как ты описываешь. В одном плане обслуживания выполнились операции индексации и т.п., затем полный бэкап базы, затем бэкап лога. И размер бэкапа лога составил 20 Гб.
Olgeir: есть еще один параноидальный момент, если делать фул бэкап после выполнения обслуживания, можно получить в итоге убитую основную базу и копию убитой базы в виде бэкапа.
Средний
