Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Чем грозит усечение журнала транзакций?  [new]
StJack
Member

Откуда:
Сообщений: 36
Камрады, вопрос животрепещущий!

Есть база 1С под управлением СУБД MS SQL 2012. Размер файла данных 53 Гб. Файл журнала транзакций занимает 92 Гб, что уже начинает напрягать. Модель восстановления - полная. Бэкапы БД делаются каждую ночь. Бэкапы журнала транзакций: днём - каждый час, ночью - каждые три часа. Также ночью запускается план обслуживания (реорганизация индексов, обновление статистики, очистка процедурного кэша). Размер бэкапа данных составляет сейчас 7 Гб, размер бэкапа журнала транзакций сразу после отработки плана обслуживания - 11 Гб, что весьма неудобно.

Понятно, что назрела необходимость обрезать журнал транзакций.

Вопрос. Насколько его можно усечь? Какого размера его нужно сделать? Чем руководствоваться для определения этого размера? Какие, вообще, существуют риски после проведения операции усечения? Чем это всё грозит?
25 окт 16, 16:26    [19820594]     Ответить | Цитировать Сообщить модератору
 Re: Чем грозит усечение журнала транзакций?  [new]
o-o
Guest
1. не надо реорганайзить все подряд
2. ребилд может писать в лог меньше реорга (если уж все супер фрагментировано),
+ его можно минимально логировать, переведя базу в bulk logged на время ребилда
25 окт 16, 16:32    [19820635]     Ответить | Цитировать Сообщить модератору
 Re: Чем грозит усечение журнала транзакций?  [new]
StJack
Member

Откуда:
Сообщений: 36
o-o
1. не надо реорганайзить все подряд

В интерфейсе плана обслуживания можно выбрать только БД, для которой необходимо провести реорганизацию. Конечно, можно и скрипт написать, но это уже совсем другая история.
2. ребилд может писать в лог меньше реорга (если уж все супер фрагментировано)

Ребилд также делается. Раз в неделю, в воскресенье. Размер бэкапа ЖТ сразу после отработки плана обслуживания составляет 6 Гб.

Как бы то ни было, обрезать ЖТ, на мой взгляд, необходимо. Мне кажется ненормальной ситуация, когда ЖТ больше файла данных. Вопрос в том, как определить, насколько его можно обрезать и чем это грозит?
25 окт 16, 16:46    [19820713]     Ответить | Цитировать Сообщить модератору
 Re: Чем грозит усечение журнала транзакций?  [new]
o-o
Guest
StJack
можно и скрипт написать, но это уже совсем другая история

выбирайте: новая история с мЕньшим размером лога или старая история с логом в 90Гиг
StJack
Ребилд также делается. Раз в неделю, в воскресенье. Размер бэкапа ЖТ сразу после отработки плана обслуживания составляет 6 Гб.

вот и делайте ребилд вместо реорга
StJack
Мне кажется ненормальной ситуация, когда ЖТ больше файла данных.

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

dbcc sqlperf(logspace)
сколько незанято, столько можно обрезать
StJack
и чем это грозит?

тем, что все вернется на круги своя.
если вы будете продолжать реорганайзить все подряд,
лог будет вырастать обратно.
причем небесплатно.
все свои 90Гб, которые ему понадобятся для логирования вашего реорга,
он будет методично заполнять нулями перед использованием
25 окт 16, 16:56    [19820782]     Ответить | Цитировать Сообщить модератору
 Re: Чем грозит усечение журнала транзакций?  [new]
StJack
Member

Откуда:
Сообщений: 36
o-o
dbcc sqlperf(logspace)
сколько незанято, столько можно обрезать

Сейчас вот такая картина:

Log Size (MB) - 89018,87
Log Space Used (%) - 0,1632028

То бишь получается, что теоретически я могу обрезать ЖТ до размера 1 Гб. Но после отработки плана обслуживания он снова станет 90 Гб. Я правильно понимаю?
25 окт 16, 17:05    [19820835]     Ответить | Цитировать Сообщить модератору
 Re: Чем грозит усечение журнала транзакций?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
StJack
o-o
dbcc sqlperf(logspace)
сколько незанято, столько можно обрезать

Сейчас вот такая картина:

Log Size (MB) - 89018,87
Log Space Used (%) - 0,1632028

То бишь получается, что теоретически я могу обрезать ЖТ до размера 1 Гб. Но после отработки плана обслуживания он снова станет 90 Гб. Я правильно понимаю?

если вы лопатите все индексы, то странно что вы вообще удивляетесь
25 окт 16, 17:12    [19820875]     Ответить | Цитировать Сообщить модератору
 Re: Чем грозит усечение журнала транзакций?  [new]
o-o
Guest
StJack
o-o
dbcc sqlperf(logspace)
сколько незанято, столько можно обрезать

Сейчас вот такая картина:

Log Size (MB) - 89018,87
Log Space Used (%) - 0,1632028

То бишь получается, что теоретически я могу обрезать ЖТ до размера 1 Гб. Но после отработки плана обслуживания он снова станет 90 Гб. Я правильно понимаю?

обрежьте до 10Гиг,
реорг замените на ребилд,
после обслуживания проверьте размер лога
25 окт 16, 17:16    [19820900]     Ответить | Цитировать Сообщить модератору
 Re: Чем грозит усечение журнала транзакций?  [new]
StJack
Member

Откуда:
Сообщений: 36
o-o
реорг замените на ребилд,

А эти операции приводят к одному и тому же результату?
25 окт 16, 17:20    [19820934]     Ответить | Цитировать Сообщить модератору
 Re: Чем грозит усечение журнала транзакций?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
StJack
o-o
реорг замените на ребилд,

А эти операции приводят к одному и тому же результату?

как следует из названия одна "чинит" другая строит... где вам бы хотелось жить? и сколько потратить на это?
25 окт 16, 17:27    [19820977]     Ответить | Цитировать Сообщить модератору
 Re: Чем грозит усечение журнала транзакций?  [new]
o-o
Guest
StJack
o-o
реорг замените на ребилд,

А эти операции приводят к одному и тому же результату?

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

просто реорг можно всегда прервать,
а ребилд весь в одной транзакции.
соответственно, ребилдить 400Гб индекса накладно и рискованно:
это 1 неделимая операция и если на 99% прервется,
будет роллбэк надолго.
а реорг переставляет себе потихоньку,
если прервут, его можно продолжить, не теряя сделанного.
---
при ваших размерах оно того не стоит,
лучше ребилдить.
хотя все подряд это жестоко
25 окт 16, 17:30    [19821008]     Ответить | Цитировать Сообщить модератору
 Re: Чем грозит усечение журнала транзакций?  [new]
StJack
Member

Откуда:
Сообщений: 36
TaPaK
как следует из названия одна "чинит" другая строит... где вам бы хотелось жить? и сколько потратить на это?

С этим разобрались. Спасибо!
А как объяснить, что процент использования так мал - всего 0,1632028%. По идее там всё должно быть забито под завязку. А по цифрам получается, что из 89 Гигов данных там около 1 Гига. А остальное что? Нули?
25 окт 16, 17:33    [19821029]     Ответить | Цитировать Сообщить модератору
 Re: Чем грозит усечение журнала транзакций?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
StJack
TaPaK
как следует из названия одна "чинит" другая строит... где вам бы хотелось жить? и сколько потратить на это?

С этим разобрались. Спасибо!
А как объяснить, что процент использования так мал - всего 0,1632028%. По идее там всё должно быть забито под завязку. А по цифрам получается, что из 89 Гигов данных там около 1 Гига. А остальное что? Нули?

в остальной части всё что угодно, точнее данные фулл бекапа. Скл "дорастил"(auto growth) или сразу выcтавили такой фал для лога, сам умеьшать не будет ибо не дурак таскать его туда сюда
25 окт 16, 17:41    [19821088]     Ответить | Цитировать Сообщить модератору
 Re: Чем грозит усечение журнала транзакций?  [new]
o-o
Guest
StJack
TaPaK
как следует из названия одна "чинит" другая строит... где вам бы хотелось жить? и сколько потратить на это?

С этим разобрались. Спасибо!
А как объяснить, что процент использования так мал - всего 0,1632028%. По идее там всё должно быть забито под завязку. А по цифрам получается, что из 89 Гигов данных там около 1 Гига. А остальное что? Нули?

ну вы же делаете бэкапы лога каждый час.
то, что забрал себе бэкап, можно перезаписывать
(с оговорками, коечно, т.е. эти записи не должны относиться к открытой транзакции,
их не должна забрать себе репликация и т.д.)
поэтому то, что "не занято", это не нули, это записи лога, которые больше никому не нужны,
заись новых пойдет поверх них
25 окт 16, 17:42    [19821093]     Ответить | Цитировать Сообщить модератору
 Re: Чем грозит усечение журнала транзакций?  [new]
StJack
Member

Откуда:
Сообщений: 36
o-o
поэтому то, что "не занято", это не нули, это записи лога, которые больше никому не нужны,
заись новых пойдет поверх них

То есть если бы не запускался план обслуживания со всеми этими реоргами и ребилдами, можно было бы смело резать лог до 1 Гб и он бы усекался при полном бэкапе БД. Я правильно понимаю?
25 окт 16, 17:50    [19821135]     Ответить | Цитировать Сообщить модератору
 Re: Чем грозит усечение журнала транзакций?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
StJack
o-o
поэтому то, что "не занято", это не нули, это записи лога, которые больше никому не нужны,
заись новых пойдет поверх них

То есть если бы не запускался план обслуживания со всеми этими реоргами и ребилдами, можно было бы смело резать лог до 1 Гб и он бы усекался при полном бэкапе БД. Я правильно понимаю?

он у вас и так "усекается" 0,1632028% жеж...
25 окт 16, 17:52    [19821141]     Ответить | Цитировать Сообщить модератору
 Re: Чем грозит усечение журнала транзакций?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
TaPaK
StJack
пропущено...

То есть если бы не запускался план обслуживания со всеми этими реоргами и ребилдами, можно было бы смело резать лог до 1 Гб и он бы усекался при полном бэкапе БД. Я правильно понимаю?

он у вас и так "усекается" 0,1632028% жеж...

в ведре ложка воды, ведро на стакан менять серверу не охота
25 окт 16, 17:55    [19821153]     Ответить | Цитировать Сообщить модератору
 Re: Чем грозит усечение журнала транзакций?  [new]
StJack
Member

Откуда:
Сообщений: 36
TaPaK
он у вас и так "усекается" 0,1632028% жеж...

Если бы :-) Как был 90 Гиг, так и остался.
25 окт 16, 17:56    [19821159]     Ответить | Цитировать Сообщить модератору
 Re: Чем грозит усечение журнала транзакций?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
StJack
TaPaK
он у вас и так "усекается" 0,1632028% жеж...

Если бы :-) Как был 90 Гиг, так и остался.

про ведро не ясно?
25 окт 16, 17:59    [19821169]     Ответить | Цитировать Сообщить модератору
 Re: Чем грозит усечение журнала транзакций?  [new]
o-o
Guest
StJack
o-o
поэтому то, что "не занято", это не нули, это записи лога, которые больше никому не нужны,
заись новых пойдет поверх них

То есть если бы не запускался план обслуживания со всеми этими реоргами и ребилдами, можно было бы смело резать лог до 1 Гб и он бы усекался при полном бэкапе БД. Я правильно понимаю?

если остальные операции не пишут в лог более гига в час (вы бэкапите лог раз в час),
то да, гига хватило бы.
только, кажется, вы не то понимаете под усечением.
"усекает" лог не полный бэкап, а бэкап *лога*
---
"усечение лога" это возможность перезаписи,
но не уменьшение файла лога в размерах.
последним занимается шринк
25 окт 16, 18:03    [19821192]     Ответить | Цитировать Сообщить модератору
 Re: Чем грозит усечение журнала транзакций?  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8488
Сразу подумайте об установке начального размера журнала не меньше, чем требуется для выполнения пакета обслуживания. Таким образом снизите риск фрагментации файла. А еще лучше его сжать, а потом установить на этот размер, операционка попытается выделить непрерывный кусок под файл. Косвенно это отразится и на физическом носителе.
Кроме того, не делайте автоприращение журнала слишком малым во избежание размножения виртуальных файлов журнала.
25 окт 16, 18:20    [19821244]     Ответить | Цитировать Сообщить модератору
 Re: Чем грозит усечение журнала транзакций?  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31822
StJack
Вопрос. Насколько его можно усечь? Какого размера его нужно сделать? Чем руководствоваться для определения этого размера?
До максимального размера лога, который получается после обслуживания.
На первый раз ориентироваться можно на размер лога журнала.
StJack
Какие, вообще, существуют риски после проведения операции усечения? Чем это всё грозит?
Риск разового падения производительности из за необходимости увеличить журнал.
То есть в принципе ничего страшного, но на расписание шринк ставить не надо.

StJack
Размер бэкапа данных составляет сейчас 7 Гб
Что тоже говорит о черезмерно большом размере файла данных. Но его шринкать не надо.
25 окт 16, 18:42    [19821312]     Ответить | Цитировать Сообщить модератору
 Re: Чем грозит усечение журнала транзакций?  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31822
alexeyvg
StJack
Вопрос. Насколько его можно усечь? Какого размера его нужно сделать? Чем руководствоваться для определения этого размера?
До максимального размера лога, который получается после обслуживания.
На первый раз ориентироваться можно на размер лога журнала.
на размер бакапа журнала.
25 окт 16, 18:43    [19821316]     Ответить | Цитировать Сообщить модератору
 Re: Чем грозит усечение журнала транзакций?  [new]
o-o
Guest
alexeyvg
alexeyvg
пропущено...
До максимального размера лога, который получается после обслуживания.
На первый раз ориентироваться можно на размер лога журнала.
на размер бакапа журнала.

Нет, как раз надо смотреть, какой размер будет у файла лога.
Ибо именно столько и надо для нормальной работы.
Размер лога это не только то, что в нем записано, это еще и резервирование место для роллбэка.
Не говоря о том, что бэкапить можно with compression, и размер бэкапа не будет никак отражать размер записанного в нем
25 окт 16, 19:14    [19821376]     Ответить | Цитировать Сообщить модератору
 Re: Чем грозит усечение журнала транзакций?  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31822
o-o
Нет, как раз надо смотреть, какой размер будет у файла лога.
Ибо именно столько и надо для нормальной работы.
Размер лога это не только то, что в нем записано, это еще и резервирование место для роллбэка.
Не говоря о том, что бэкапить можно with compression, и размер бэкапа не будет никак отражать размер записанного в нем
Да. ну я и написал - "До максимального размера лога, который получается после обслуживания."

Просто вначале же этот размер неизвестен?

Вот можно либо посмотреть на занятую часть лога после обслуживания, но до бакапа, либо на размер бакапа (что проще). Если бакап сжатый, то умножить его на 3.

Да, это неточный метод, но для определение начального размера, и чтоб обязательно с погрешностью в меньшую сторону, сойдёт...
25 окт 16, 19:36    [19821428]     Ответить | Цитировать Сообщить модератору
 Re: Чем грозит усечение журнала транзакций?  [new]
o-o
Guest
Еще раз: не бэкап лога, а размер самого лога укажет на то, сколько надо места логу.
Если я ребилдю 400гиг в полной модели, лога под это дело надо более 800гиг, хотя по окончании ребилда, если все хорошо, в логе будут именно 400 гиг, а не 800 (но лог вырастет до 800Гиг, если не больше).
И бэкапиться будут тоже не 800 гиг, пустое место никто не бэкапит.
Зато если я промахнусь со своими оценками, то снова буду ждать зануление 400Гиг моей "ошибки"
25 окт 16, 19:46    [19821457]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить