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

Размер базы: 4 гига.
Размер полного бекапа - 4 гига.
Размер разностного бекапа - 3.9 гига.
Почему разностный весит столько же, сколько и полный.
В таком случае хочу уйти от разностного и перейти к другой последовательности: каждый день полный, каждый час журнал транзакций. Что скажете?

Вызвать хирурга и заказать срочную пересадку рук из района таза.

а нельзя просто ответить, без выпендрежа?

(2)Что- ты намудрил в настройках.:-) Не может хвост лога равняться по объему базе.

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

Убрал нафиг диф бекап. Сейчас график такой:
Каждый день в 00.00 обновление статистик
Каждый день в 01.00 дефрагментация индексов
Каждый день в 02.00 реиндексация
Каждый день в 05.00 полный бекап
Каждый час с 08.00 по 23.00 - бекап журнала транзакций

Вопрос в следующем: Утром в 8.00 создается бекап журнала транзакций огромного размера. Потому что он берет для себя первый LSN не с последнего полного бекапа в 05.00, а с последнего журнала транзакций в 23.00. Поэтому включает в себя и все изменения, которые произошли в результате обновления статистик, дефрагментации и реиндексации.
Но почему так, как сделать, чтобы он брал для себя LSN с последнего бекапа, таким образом у меня утренний 8.00 бекап журнала транзакций будет очень маенький, так как за этот период (с 05.00 по 08.00) никаких действий с базой не производилось.

есть тут кто?

Гипотетически, фул не успевает закончиться до 8.........

у меня успевает. Он минут за 15 делается. База 4 гига.

вообще бекап главнее статистик деврогментаций реиндексаций, по этому он должен делатся первым...

в сабже похоже журнал лога не шринкуется

кстати у нас вообще лог не бекапится, у нас делается каждые 15 мин диф бекап

(9) Похоже.
(8) Настрой шринк где то на 7.30

(10) Диф лучше. Но уж очень он дисковое пространство любит. :)

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

(11) а что делает шринк. Очищает чтоли журнал? Можете команду подсказать

В планах обслуживания визард запусти. Там этот пункт есть.

(0) приведи скрипты бэкапа полностью

(16) я делал визардом
Щас покажу

http://s019.radikal.ru/i636/1204/eb/9f87801115cf.jpg

(18) консоль на русском. фу какая гадость. сжатием там шринк называется.

(18) Слева в нижнем углу в Задачи плана обслуживания есть пункт Очистка журнала. Это и есть шринк.

(20) да. сжатие это не то походу.

(5) в прошлой теме уже отвечали же тебе,
нужно после выполнения регламентных процедур делать отдельное задание на усечение лога с параметром TRUNCATE_ONLY. После этого задания уже у тебя будет запускаться фул бэкап, который начнет новую цепочку.
Будет выглядиь так
с пн-сб в 00.00 дефрагментация индексов
с пн-сбв 01.00 обновление статистик (статистику имеет смысл обновлять после дефргаментации)
с пн-сб в 03.00 отдельное задание на усечение лога и если нажо его сажите.
с пн-сб в 04.00 фул бэкап.
Каждое вскр в 00.00 полный ребил (реиндексация)

(22) я не зря указал 2008 сервер. На нем параметр truncate_only не работает

ТОЧНО НЕ ГОНИТЕ?

(23) ну и переводите свою базу в режим восстановления SIMPLE ПЕРЕД всеми ночными действиями. А перед полным бэкапом обратно в FULL.

(23) тогда как в (25) или же после ночных действий задание на перевод в симпл, потом сразу же в фулл, потом сразу шринк.

(22) можно вопрос? Шринк же вроде не удалит в логе ничего? только сожмет. А чтоб например удалить поллога так можно сделать?

(27) шринк сжимает файл, усечение это очищение неактивных виртуальных журналов.
(23)для 2008 еще можно извращенно сделать так
BACKUP LOG TO DISK=’NUL:

(27) шринк удаляет из лога все, кроме незавершенки, и разрывает последовательность бэкапов

(29) проснуться надо )

Тоже интересуюсь практикой диф-бекапов. Насколько они "прожорливы". Каждый диф ведь разница с последним полным, без учета других дифов?
Пока обхожусь без них (каждый день полный и бэкапы транзакций в течение дня), но надо готовиться :)

(31) >>Каждый диф ведь разница с последним полным, без учета других дифов?
именно так
>>Насколько они "прожорливы"
Сложно оценить. Точно можно сказать только то, что он не будет больше чем полный бэкап :). Сколько страниц данных изменится с момента последнего полного бэкапа * 8 - это и будет размер диф. бэкапа в килобайтах.

(31)После полного бэкапа журнал транзакций у тебя по "новой" начинается?

(33) Как это? По "новой" журнал транзакций начинается после бэкапа журнала транзакций. Большего и не надо.

нашел такой пример

alter database <mydb> set recovery simple
go

checkpoint
go

alter database <mydb> set recovery full
go

backup database pubs to disk = 'c:mydb.bak' with init
go

dbcc shrinkfile (N'mydb_log' , 1)
go

Может у меня в графике вместо 05.00 Полный бекап сделать эту команду?

кто тут есть. Ответьте, плиз

можешь сделать так, по сути это же самое что тебе и рекомендовали, перевод в симпл, потом перевод в фул, потом фул бэкап.