| Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
| Все форумы / Microsoft SQL Server |
  |
||
 Чем грозит усечение журнала транзакций?
|
|
|
StJack Member Откуда: Сообщений: 36 |
Камрады, вопрос животрепещущий! Есть база 1С под управлением СУБД MS SQL 2012. Размер файла данных 53 Гб. Файл журнала транзакций занимает 92 Гб, что уже начинает напрягать. Модель восстановления - полная. Бэкапы БД делаются каждую ночь. Бэкапы журнала транзакций: днём - каждый час, ночью - каждые три часа. Также ночью запускается план обслуживания (реорганизация индексов, обновление статистики, очистка процедурного кэша). Размер бэкапа данных составляет сейчас 7 Гб, размер бэкапа журнала транзакций сразу после отработки плана обслуживания - 11 Гб, что весьма неудобно. Понятно, что назрела необходимость обрезать журнал транзакций. Вопрос. Насколько его можно усечь? Какого размера его нужно сделать? Чем руководствоваться для определения этого размера? Какие, вообще, существуют риски после проведения операции усечения? Чем это всё грозит? |
| 25 окт 16, 16:26 [19820594] Ответить | Цитировать Сообщить модератору | |
| Re: Чем грозит усечение журнала транзакций?
|
|
|
o-o
Guest |
1. не надо реорганайзить все подряд 2. ребилд может писать в лог меньше реорга (если уж все супер фрагментировано), + его можно минимально логировать, переведя базу в bulk logged на время ребилда |
| 25 окт 16, 16:32 [19820635] Ответить | Цитировать Сообщить модератору | |
| Re: Чем грозит усечение журнала транзакций?
|
|||||
|
StJack Member Откуда: Сообщений: 36 |
В интерфейсе плана обслуживания можно выбрать только БД, для которой необходимо провести реорганизацию. Конечно, можно и скрипт написать, но это уже совсем другая история.
Ребилд также делается. Раз в неделю, в воскресенье. Размер бэкапа ЖТ сразу после отработки плана обслуживания составляет 6 Гб. Как бы то ни было, обрезать ЖТ, на мой взгляд, необходимо. Мне кажется ненормальной ситуация, когда ЖТ больше файла данных. Вопрос в том, как определить, насколько его можно обрезать и чем это грозит? |
||||
| 25 окт 16, 16:46 [19820713] Ответить | Цитировать Сообщить модератору | |||||
| Re: Чем грозит усечение журнала транзакций?
|
|||||||||||
|
o-o
Guest |
выбирайте: новая история с мЕньшим размером лога или старая история с логом в 90Гиг
вот и делайте ребилд вместо реорга
мне кажется ненормальным доводить его до такого состояния. ну обрежете вы, запустите снова свой реорг и получите ваши 90Гб обратно. игра "кто кого"?
dbcc sqlperf(logspace) сколько незанято, столько можно обрезать
тем, что все вернется на круги своя. если вы будете продолжать реорганайзить все подряд, лог будет вырастать обратно. причем небесплатно. все свои 90Гб, которые ему понадобятся для логирования вашего реорга, он будет методично заполнять нулями перед использованием |
||||||||||
| 25 окт 16, 16:56 [19820782] Ответить | Цитировать Сообщить модератору | |||||||||||
| Re: Чем грозит усечение журнала транзакций?
|
|||
|
StJack Member Откуда: Сообщений: 36 |
Сейчас вот такая картина: Log Size (MB) - 89018,87 Log Space Used (%) - 0,1632028 То бишь получается, что теоретически я могу обрезать ЖТ до размера 1 Гб. Но после отработки плана обслуживания он снова станет 90 Гб. Я правильно понимаю? |
||
| 25 окт 16, 17:05 [19820835] Ответить | Цитировать Сообщить модератору | |||
| Re: Чем грозит усечение журнала транзакций?
|
|||||
|
TaPaK Member Откуда: Kiev Сообщений: 6801 |
если вы лопатите все индексы, то странно что вы вообще удивляетесь |
||||
| 25 окт 16, 17:12 [19820875] Ответить | Цитировать Сообщить модератору | |||||
| Re: Чем грозит усечение журнала транзакций?
|
|||||
|
o-o
Guest |
обрежьте до 10Гиг, реорг замените на ребилд, после обслуживания проверьте размер лога |
||||
| 25 окт 16, 17:16 [19820900] Ответить | Цитировать Сообщить модератору | |||||
| Re: Чем грозит усечение журнала транзакций?
|
|||
|
StJack Member Откуда: Сообщений: 36 |
А эти операции приводят к одному и тому же результату? |
||
| 25 окт 16, 17:20 [19820934] Ответить | Цитировать Сообщить модератору | |||
| Re: Чем грозит усечение журнала транзакций?
|
|||||
|
TaPaK Member Откуда: Kiev Сообщений: 6801 |
как следует из названия одна "чинит" другая строит... где вам бы хотелось жить? и сколько потратить на это? |
||||
| 25 окт 16, 17:27 [19820977] Ответить | Цитировать Сообщить модератору | |||||
| Re: Чем грозит усечение журнала транзакций?
|
|||||
|
o-o
Guest |
ребилд лучше. реорг просто меняет местами страницы, чтобы шли по порядку. ребилд же переливает данные полностью. просто реорг можно всегда прервать, а ребилд весь в одной транзакции. соответственно, ребилдить 400Гб индекса накладно и рискованно: это 1 неделимая операция и если на 99% прервется, будет роллбэк надолго. а реорг переставляет себе потихоньку, если прервут, его можно продолжить, не теряя сделанного. --- при ваших размерах оно того не стоит, лучше ребилдить. хотя все подряд это жестоко |
||||
| 25 окт 16, 17:30 [19821008] Ответить | Цитировать Сообщить модератору | |||||
| Re: Чем грозит усечение журнала транзакций?
|
|||
|
StJack Member Откуда: Сообщений: 36 |
С этим разобрались. Спасибо! А как объяснить, что процент использования так мал - всего 0,1632028%. По идее там всё должно быть забито под завязку. А по цифрам получается, что из 89 Гигов данных там около 1 Гига. А остальное что? Нули? |
||
| 25 окт 16, 17:33 [19821029] Ответить | Цитировать Сообщить модератору | |||
| Re: Чем грозит усечение журнала транзакций?
|
|||||
|
TaPaK Member Откуда: Kiev Сообщений: 6801 |
в остальной части всё что угодно, точнее данные фулл бекапа. Скл "дорастил"(auto growth) или сразу выcтавили такой фал для лога, сам умеьшать не будет ибо не дурак таскать его туда сюда |
||||
| 25 окт 16, 17:41 [19821088] Ответить | Цитировать Сообщить модератору | |||||
| Re: Чем грозит усечение журнала транзакций?
|
|||||
|
o-o
Guest |
ну вы же делаете бэкапы лога каждый час. то, что забрал себе бэкап, можно перезаписывать (с оговорками, коечно, т.е. эти записи не должны относиться к открытой транзакции, их не должна забрать себе репликация и т.д.) поэтому то, что "не занято", это не нули, это записи лога, которые больше никому не нужны, заись новых пойдет поверх них |
||||
| 25 окт 16, 17:42 [19821093] Ответить | Цитировать Сообщить модератору | |||||
| Re: Чем грозит усечение журнала транзакций?
|
|||
|
StJack Member Откуда: Сообщений: 36 |
То есть если бы не запускался план обслуживания со всеми этими реоргами и ребилдами, можно было бы смело резать лог до 1 Гб и он бы усекался при полном бэкапе БД. Я правильно понимаю? |
||
| 25 окт 16, 17:50 [19821135] Ответить | Цитировать Сообщить модератору | |||
| Re: Чем грозит усечение журнала транзакций?
|
|||||
|
TaPaK Member Откуда: Kiev Сообщений: 6801 |
он у вас и так "усекается" 0,1632028% жеж... |
||||
| 25 окт 16, 17:52 [19821141] Ответить | Цитировать Сообщить модератору | |||||
| Re: Чем грозит усечение журнала транзакций?
|
|||||
|
TaPaK Member Откуда: Kiev Сообщений: 6801 |
в ведре ложка воды, ведро на стакан менять серверу не охота |
||||
| 25 окт 16, 17:55 [19821153] Ответить | Цитировать Сообщить модератору | |||||
| Re: Чем грозит усечение журнала транзакций?
|
|||
|
StJack Member Откуда: Сообщений: 36 |
Если бы :-) Как был 90 Гиг, так и остался. |
||
| 25 окт 16, 17:56 [19821159] Ответить | Цитировать Сообщить модератору | |||
| Re: Чем грозит усечение журнала транзакций?
|
|||||
|
TaPaK Member Откуда: Kiev Сообщений: 6801 |
про ведро не ясно? |
||||
| 25 окт 16, 17:59 [19821169] Ответить | Цитировать Сообщить модератору | |||||
| Re: Чем грозит усечение журнала транзакций?
|
|||||
|
o-o
Guest |
если остальные операции не пишут в лог более гига в час (вы бэкапите лог раз в час), то да, гига хватило бы. только, кажется, вы не то понимаете под усечением. "усекает" лог не полный бэкап, а бэкап *лога* --- "усечение лога" это возможность перезаписи, но не уменьшение файла лога в размерах. последним занимается шринк |
||||
| 25 окт 16, 18:03 [19821192] Ответить | Цитировать Сообщить модератору | |||||
| Re: Чем грозит усечение журнала транзакций?
|
|
|
Владислав Колосов Member Откуда: Сообщений: 8488 |
Сразу подумайте об установке начального размера журнала не меньше, чем требуется для выполнения пакета обслуживания. Таким образом снизите риск фрагментации файла. А еще лучше его сжать, а потом установить на этот размер, операционка попытается выделить непрерывный кусок под файл. Косвенно это отразится и на физическом носителе. Кроме того, не делайте автоприращение журнала слишком малым во избежание размножения виртуальных файлов журнала. |
| 25 окт 16, 18:20 [19821244] Ответить | Цитировать Сообщить модератору | |
| Re: Чем грозит усечение журнала транзакций?
|
|||||||
|
alexeyvg Member Откуда: Moscow Сообщений: 31822 |
На первый раз ориентироваться можно на размер лога журнала.
То есть в принципе ничего страшного, но на расписание шринк ставить не надо.
|
||||||
| 25 окт 16, 18:42 [19821312] Ответить | Цитировать Сообщить модератору | |||||||
| Re: Чем грозит усечение журнала транзакций?
|
|||||
|
alexeyvg Member Откуда: Moscow Сообщений: 31822 |
|
||||
| 25 окт 16, 18:43 [19821316] Ответить | Цитировать Сообщить модератору | |||||
| Re: Чем грозит усечение журнала транзакций?
|
|||||
|
o-o
Guest |
Нет, как раз надо смотреть, какой размер будет у файла лога. Ибо именно столько и надо для нормальной работы. Размер лога это не только то, что в нем записано, это еще и резервирование место для роллбэка. Не говоря о том, что бэкапить можно with compression, и размер бэкапа не будет никак отражать размер записанного в нем |
||||
| 25 окт 16, 19:14 [19821376] Ответить | Цитировать Сообщить модератору | |||||
| Re: Чем грозит усечение журнала транзакций?
|
|||
|
alexeyvg Member Откуда: Moscow Сообщений: 31822 |
Просто вначале же этот размер неизвестен? Вот можно либо посмотреть на занятую часть лога после обслуживания, но до бакапа, либо на размер бакапа (что проще). Если бакап сжатый, то умножить его на 3. Да, это неточный метод, но для определение начального размера, и чтоб обязательно с погрешностью в меньшую сторону, сойдёт... |
||
| 25 окт 16, 19:36 [19821428] Ответить | Цитировать Сообщить модератору | |||
| Re: Чем грозит усечение журнала транзакций?
|
|
|
o-o
Guest |
Еще раз: не бэкап лога, а размер самого лога укажет на то, сколько надо места логу. Если я ребилдю 400гиг в полной модели, лога под это дело надо более 800гиг, хотя по окончании ребилда, если все хорошо, в логе будут именно 400 гиг, а не 800 (но лог вырастет до 800Гиг, если не больше). И бэкапиться будут тоже не 800 гиг, пустое место никто не бэкапит. Зато если я промахнусь со своими оценками, то снова буду ждать зануление 400Гиг моей "ошибки" |
| 25 окт 16, 19:46 [19821457] Ответить | Цитировать Сообщить модератору | |
| Все форумы / Microsoft SQL Server | |
|
x