Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Борьба с раздуванием логов  [new]
wlbs
Member

Откуда:
Сообщений: 37
Добрый день. При полном бэкапе лог транзакций очищается или только при бэкапе логов идет очистка?
18 фев 15, 02:04    [17279280]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с раздуванием логов  [new]
wlbs
Member

Откуда:
Сообщений: 37
Если очистка не идет при полном бэкапе - то как бороться с раздуванием после реорганизации индексов?

Поясняю:
Раз в сутки, перед полным бэкапом происходит реорганизация индексов. И в цепочке логов, бэкап логов после реорганизации индексов раздувает на 70% от обьемов самой БД. И тут проблема. Этот последний бэкап в цепочке нафиг не нужен, при этом занимает дофига. Как бороться?
18 фев 15, 02:10    [17279286]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с раздуванием логов  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37069
Если вы так уверены, что вам этот бэкап не нужен, и что вы сможете восстановить базу на интересующий вас момент, если, скажем, она загнется во время реорганизации индексов или последующего за ней бэкапа, то переключайте модель восстановления в простую перед реорганизацией и в полную перед полным бэкапом.
18 фев 15, 02:35    [17279293]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с раздуванием логов  [new]
aleks2
Guest
Гавриленко Сергей Алексеевич
Если вы так уверены, что вам этот бэкап не нужен, и что вы сможете восстановить базу на интересующий вас момент, если, скажем, она загнется во время реорганизации индексов или последующего за ней бэкапа, то переключайте модель восстановления в простую перед реорганизацией и в полную перед полным бэкапом.


Что за бред?

wlbs
Поясняю:
Раз в сутки, перед полным бэкапом происходит реорганизация индексов. И в цепочке логов, бэкап логов после реорганизации индексов раздувает на 70% от обьемов самой БД. И тут проблема. Этот последний бэкап в цепочке нафиг не нужен, при этом занимает дофига. Как бороться?


Делать бэкап лога.
Делать полный бэкап.
Стирать бэкап лога.
18 фев 15, 06:20    [17279336]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с раздуванием логов  [new]
wlbs
Member

Откуда:
Сообщений: 37
Гавриленко Сергей Алексеевич,

за час перед индексацией происходит бэкап лога (конец рабочего дня). После идет реорганизация, потом бэкап лога, потом полный бэкап. Последний бэкап лога не содержит в себе ничего, кроме дефрагментированных индексов. А на случай кривой реиндексации есть всегда полный предыдущий бэкап и полная цепочка логов до конца рабочего дня.
aleks2
Делать бэкап лога.
Делать полный бэкап.
Стирать бэкап лога.

А через T-SQL это можно как то автоматизировать?
18 фев 15, 08:08    [17279432]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с раздуванием логов  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31443
aleks2
Что за бред?
А что, нормальный подход.
Если предусматривается окно для обслуживания, бизнес-транзакций нет, соответственно необходимости восстановить на любой момент времени в этом промежутке нет, то вполне нормально.
Перевели в симпл, выполнили обслуживание, перевели в фулл, сделали полный бакап - далее в течении дня бакапы логов.
Это уменьшит нагрузки на систему бакапов.
aleks2
Делать бэкап лога.
Делать полный бэкап.
Стирать бэкап лога.
И получается то же самое. Бакап лога стёрт, восстановить в этот период на момент времени нельзя. Зачем тогда тратить время и место на бакап лога?
18 фев 15, 08:34    [17279455]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с раздуванием логов  [new]
wlbs
Member

Откуда:
Сообщений: 37
alexeyvg,

в обоих случая слишком много телодвижений надо делать руками.
18 фев 15, 08:39    [17279466]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с раздуванием логов  [new]
При полном бэкапе
Guest
wlbs,

любое из перечисленного нет никакой необходимости постоянно делать руками
автор
Зачем тогда тратить время и место на бакап лога?

зачем тогда стоит full?
18 фев 15, 09:01    [17279513]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с раздуванием логов  [new]
wlbs
Member

Откуда:
Сообщений: 37
При полном бэкапе
wlbs,

любое из перечисленного нет никакой необходимости постоянно делать руками


Тогда можно пример такого T-SQL скрипта?
18 фев 15, 09:12    [17279543]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с раздуванием логов  [new]
Glory
Member

Откуда:
Сообщений: 104760
wlbs
Тогда можно пример такого T-SQL скрипта?

Изучайте хелп https://msdn.microsoft.com/en-us/library/bb522682.aspx
18 фев 15, 09:15    [17279550]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с раздуванием логов  [new]
wlbs
Member

Откуда:
Сообщений: 37
Glory,

Перед реорганизацией:
USE master ;
ALTER DATABASE testing_base SET RECOVERY SIMPLE ;

После реорганизации:
USE master ;
ALTER DATABASE testing_base SET RECOVERY FULL ;


Так?
18 фев 15, 09:24    [17279574]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с раздуванием логов  [new]
wlbs
Member

Откуда:
Сообщений: 37
Немного поковырял. Составил такую фигню.

USE [master]
GO
ALTER DATABASE [base_test1] SET RECOVERY SIMPLE WITH NO_WAIT
GO
ALTER DATABASE [base_test2] SET RECOVERY SIMPLE WITH NO_WAIT
GO
ALTER DATABASE [base_test3] SET RECOVERY SIMPLE WITH NO_WAIT
GO

И так же только с FULL во втором скрипте. В SSIS поставил simple перед реиндексацией, а full после.
18 фев 15, 10:25    [17279833]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с раздуванием логов  [new]
человек_ниоткуда
Guest
Гавриленко Сергей Алексеевич
Если вы так уверены, что вам этот бэкап не нужен, и что вы сможете восстановить базу на интересующий вас момент, если, скажем, она загнется во время реорганизации индексов или последующего за ней бэкапа, то переключайте модель восстановления в простую перед реорганизацией и в полную перед полным бэкапом.

Или бекап лога делать во врем дефрагментации... почаще... И Я ТРЕБУЮ СЧИТАТЬ МОИ СЛОВА СООТВЕТСТВУЮЩИМИ ДЕЙСТВИТЕЛЬНОСТИ! :)

Или вы уже троллите, поциента?
18 фев 15, 10:47    [17279979]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с раздуванием логов  [new]
aleks2
Guest
wlbs
Гавриленко Сергей Алексеевич,

за час перед индексацией происходит бэкап лога (конец рабочего дня). После идет реорганизация, потом бэкап лога, потом полный бэкап. Последний бэкап лога не содержит в себе ничего, кроме дефрагментированных индексов. А на случай кривой реиндексации есть всегда полный предыдущий бэкап и полная цепочка логов до конца рабочего дня.
aleks2
Делать бэкап лога.
Делать полный бэкап.
Стирать бэкап лога.

А через T-SQL это можно как то автоматизировать?


Какие проблемы?

Делаем бякап в файл с фиксированным именем с перезаписью файла.
Стираем файл. (Можно даже не стирать)

ЗЫ. Переключение FULL <-> SIMPLE чревато. Застрянет в SIMPLE и хана бякапам лога и надеждам на восстановление.
18 фев 15, 10:53    [17280026]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с раздуванием логов  [new]
wlbs
Member

Откуда:
Сообщений: 37
aleks2,

почему хана... Можно указать восстановление из файла, указать full и цепочку логов.
Это уже сто раз на кошках отработал.
18 фев 15, 10:59    [17280079]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с раздуванием логов  [new]
Glory
Member

Откуда:
Сообщений: 104760
wlbs
почему хана.

Как вы будете обрабатывать неудачный результат переключения модели в FULL ?
Что будет с последующими бэкапами лога, если модель будет все еще не будет переключена в FULL ?

Почему бы не делать бэкап лога после реорганизации каждой таблицы/индекса ?
18 фев 15, 11:17    [17280206]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с раздуванием логов  [new]
aleks2
Guest
wlbs
aleks2,

почему хана... Можно указать восстановление из файла, указать full и цепочку логов.
Это уже сто раз на кошках отработал.


Эх, кошкодав, потому что:
если база застрянет в SIMPLE никакой цепочки уже не будет.

А когда ты это обнаружишь - вилами на воде писано.
18 фев 15, 11:19    [17280223]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с раздуванием логов  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37069
aleks2
если база застрянет в SIMPLE никакой цепочки уже не будет.
Если перевод в FULL засунуть первым степом джоба на полный бэкап, то не застрянет.

Основная проблема такого подхода в том, что он требует окна, когда гарантированно никто не будет работать с базой, от момента перевода в simple, до момента окончания полного бэкапа. Если такой гарантии нет, то так делать однозначно не стоит. И если вы не понимаете, что делаете, то так тоже делать не стоит. В остальных случаях можно сэкономить немного ресурсов железа.
18 фев 15, 11:27    [17280291]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с раздуванием логов  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37069
Но доставить диск и не заморачиваться гораздо проще.

Сообщение было отредактировано: 18 фев 15, 11:33
18 фев 15, 11:29    [17280311]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с раздуванием логов  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31443
wlbs
alexeyvg,

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


wlbs
Тогда можно пример такого T-SQL скрипта?
Какие действия? Бакап - команда BACKUP, изменение режима логирования - команда ALTER DATABASE
18 фев 15, 12:37    [17280781]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с раздуванием логов  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31443
aleks2
Эх, кошкодав, потому что:
если база застрянет в SIMPLE никакой цепочки уже не будет.
Застрять может что угодно. Письма можно посылать при ошибках, например.

Ну да, согласен - просто делать бакапы - надёжнее. Если застрянет очередной FULL, логи то есть, если застрянет очередной лог, то просто следующй будет больше по размеру.

Но если проблема с местом или с временем для бакапа, то решение с переводом в симпл тоже нормальное, просто нужно больше внимания уделять лигированию и мониторингу.
18 фев 15, 12:43    [17280827]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с раздуванием логов  [new]
NickAlex66
Member

Откуда:
Сообщений: 319
wlbs,

Можно обслуживать базу не всю сразу, а "почастям". Уменьшится продолжительнлсть транзакций. А между транз-ми бэкапить лог. Для VLDB не плохо получается.
18 фев 15, 20:12    [17283996]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с раздуванием логов  [new]
eldarkt
Member

Откуда:
Сообщений: 17
Можно ещё делать
BACKUP LOG [db_name] to disk='nul' 


Это что-то вроде with truncate_only, который начиная с 2008-го запретили.
Но именно потому и запретили - это так себе костыль (но лучше чем бэкап лога сразу перезаписывать, чтобы диск не мучить), а правильно будет действительно диск добавить, как выше уже писали.
18 фев 15, 23:18    [17284691]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с раздуванием логов  [new]
wlbs
Member

Откуда:
Сообщений: 37
А вообще, у MSSQL есть не костыльные механизмы очистки логов транзакций без бэкапов? Ну не целесообразно каждый день генерировать замыкающий бэкап лога размером всех полных бэкапов вместе взятых. Тут даже не столько места под него жалко, сколько времени уходит на бэкап и сжатие, а потом еще копирование этого бэкапа на внешний NAS.
19 фев 15, 07:49    [17285225]     Ответить | Цитировать Сообщить модератору
 Re: Борьба с раздуванием логов  [new]
Ruuu
Member

Откуда: Иркутск
Сообщений: 4272
wlbs,
wlbs
А вообще, у MSSQL есть не костыльные механизмы очистки логов транзакций без бэкапов? Ну не целесообразно каждый день генерировать замыкающий бэкап лога размером всех полных бэкапов вместе взятых. Тут даже не столько места под него жалко, сколько времени уходит на бэкап и сжатие, а потом еще копирование этого бэкапа на внешний NAS.


Для начала разобраться, нужна ли вам реорганизация всех индексов каждую ночь.
19 фев 15, 08:05    [17285247]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить