Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Причина разрастания инкрементальных бэкапов.  [new]
guest_sql2012
Guest
1С УПП в связке с MSSQL 2012, пару дней наблюдается такая картина.
Вчера очищал журнал транзакций и инкрементальные бэкапы стали адекватного размера.
Сегодня журнал транзакций маленький, а инкрементальные бэкапы по 30 ГБ каждый.
Как выяснить причину такого поведения MSSQL, куда копать ?
В логах MSSQL ни варнингов ни ошибок, но это не нормальная ситуация.

К сообщению приложен файл. Размер - 120Kb
16 окт 16, 07:05    [19786394]     Ответить | Цитировать Сообщить модератору
 Re: Причина разрастания инкрементальных бэкапов.  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37254
Искать в джобах, которые запускаются по воскресеньям с 4:00 до 4:30.
16 окт 16, 10:08    [19786495]     Ответить | Цитировать Сообщить модератору
 Re: Причина разрастания инкрементальных бэкапов.  [new]
guest_sql2012
Guest
Гавриленко Сергей Алексеевич,

Благодарю.
Действительно был джоб "перестроение индексов".
Он нормально отрабатывал на протяжении 2 лет.
И тут на тебе, чтото недоперестроил
16 окт 16, 16:38    [19787008]     Ответить | Цитировать Сообщить модератору
 Re: Причина разрастания инкрементальных бэкапов.  [new]
SERG1257
Member

Откуда:
Сообщений: 2864
Если у вас есть доступ к скрипту для выполнения инкрементного бакапа, то можно добавить логику типа
если предыдущий инкрементный бакап был большим, то вместо инкрементного бакапа (который по определению будет еще больше) выполнять полный

BEGIN
-- find previous backup size and if it's diff find previous full backup size
select  @previous_diff_backup_size=b.backup_size,
	@previous_full_backup_size=f.backup_size 
from msdb.dbo.backupset b
join msdb.dbo.backupset f on b.differential_base_guid=f.backup_set_uuid 
WHERE b.database_name = @DBName
 and b.backup_start_date=(SELECT max(backup_start_date) FROM msdb.dbo.backupset b1 WHERE b1.database_name = @DBName)

if isnull(@previous_diff_backup_size,0)>isnull(@previous_full_backup_size*0.8,0) SET @DBBackupType = 'FULL'
else SET @DBBackupType = 'DIFF'
END
18 окт 16, 23:48    [19797243]     Ответить | Цитировать Сообщить модератору
 Re: Причина разрастания инкрементальных бэкапов.  [new]
tunknown
Member

Откуда:
Сообщений: 775
guest_sql2012
Действительно был джоб "перестроение индексов".
Что именно в этом джобе?
Например, DBCC INDEXDEFRAG может приводить к нежелательному увеличению размера.
Если есть что-то похожее на DBCC INDEXDEFRAG->full backup->insert->backup log №1->insert №1->backup log №2, то backup log №1 в зависимости от того, что было в insert №1 может привести к тому, что .trn неожиданно станет больше .bak. Хотя размер backup log №2 уже будет ожидаемым.

guest_sql2012
Он нормально отрабатывал на протяжении 2 лет.
Скорее это удивительно.
19 окт 16, 10:18    [19798216]     Ответить | Цитировать Сообщить модератору
 Re: Причина разрастания инкрементальных бэкапов.  [new]
tunknown
Member

Откуда:
Сообщений: 775
Уточняю:
DBCC INDEXDEFRAG->full backup->insert №1->backup log №1->insert №2->backup log №2

insert №1 может привести к такому влиянию на (кластерные) индексы, что воздействие на лог при модели full приведёт к большому размеру .trn после backup log №1, хотя после backup log №2 .trn будет небольшим
19 окт 16, 10:28    [19798288]     Ответить | Цитировать Сообщить модератору
 Re: Причина разрастания инкрементальных бэкапов.  [new]
o-o
Guest
что тут вообще зовется "инкрементальными бэкапами"?
один про дифференциальные отвечает, другой про бэкапы лога...
почему нельзя использовать общепринятую терминологию?
по одинаково названным файлам бэкапа тоже не поймешь, где какой.
хоть бы типы подписали, бардак какой-то
19 окт 16, 13:49    [19799766]     Ответить | Цитировать Сообщить модератору
 Re: Причина разрастания инкрементальных бэкапов.  [new]
tunknown
Member

Откуда:
Сообщений: 775
o-o
один про дифференциальные отвечает, другой про бэкапы лога...

Мой пример несколько не в тему. Однако, и diff и log отражают изменения, порождённые insert(и остальными) и причина увеличения размера может быть сходной.
19 окт 16, 17:05    [19800967]     Ответить | Цитировать Сообщить модератору
 Re: Причина разрастания инкрементальных бэкапов.  [new]
o-o
Guest
мои претензии не к ответившим, а к вопрошающему.
ибо в MS SQL нет инкрементальных бэкапов.
и понять его каждый может по-своему.
названия бэкапов у него все одинаковые, сам-то он не фигеет различать их по типам,
если тип бэкапа в названии не отражен вообще?
и потом он сам несет околесицу:
автор
Вчера очищал журнал транзакций и инкрементальные бэкапы стали адекватного размера.

как "очищал", руками залез?
бэкап лога наконец сделал?
и еще раз, что у нас после этого "инкрементальные бэкапы"?
из его картинки это вроде диффы, или почему не меняется размер, если это бэкапы лога.
но если это диффы, то при чем тут "очистка лога" и зачем диффы делать каждые 20 минут?
19 окт 16, 18:02    [19801344]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить