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

Откуда:
Сообщений: 99
Добрый день.

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


з.ы.: как-то тут видел, приводили пример расчета, но не могу найти ту ветку. тематических статей тоже не нашел
11 июл 17, 18:33    [20634607]     Ответить | Цитировать Сообщить модератору
 Re: расчет прироста транзакционного лога  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30786
MacaronicTragedy
я пробовал создать тестовую таблицу, удалить пачку строк, посмотреть, насколько вырастает при этом лог.
Одной операцией?
11 июл 17, 19:04    [20634676]     Ответить | Цитировать Сообщить модератору
 Re: расчет прироста транзакционного лога  [new]
Владислав Колосов
Member

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

почему получилось на два - не совсем понятно. Индексы есть в таблице?
11 июл 17, 19:06    [20634686]     Ответить | Цитировать Сообщить модератору
 Re: расчет прироста транзакционного лога  [new]
MacaronicTragedy
Member

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

да, одной пачкой удалил 10000 строк.
про то, что при больших удалениях лучше использовать цикл знаю, хотелось именно замерить прирост при простом удалении.

Владислав,
в таблице есть первичный ключ, кластерный.
Т.е. вы ведёте к тому, что считаем сумму длинн полей я количество строк + сумму длинн полей всех индексов * количество строк?
11 июл 17, 19:13    [20634704]     Ответить | Цитировать Сообщить модератору
 Re: расчет прироста транзакционного лога  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30786
MacaronicTragedy
Т.е. вы ведёте к тому, что считаем сумму длинн полей я количество строк + сумму длинн полей всех индексов * количество строк?
Если есть другие индексы, то да.
Но кластерный уникальный индекс - это сама таблица, так что странно. ИМХО в логе должны просто записаться строки, т.е. удаляемый размер*1
А вы удаляли элементы из диапазона кластерного индекса, или разрозненные?
11 июл 17, 19:26    [20634735]     Ответить | Цитировать Сообщить модератору
 Re: расчет прироста транзакционного лога  [new]
MacaronicTragedy
Member

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

завтра обязательно перепроверю ddl таблицы, может проглядел.
кластерный индекс по полю id (int), удалял по полю даты - старше определенного возраста.
удалял запросом delete top(10000) from t1 where coldate < ......

а при перестроении индекса все ограничится размером самого индекса?
11 июл 17, 19:35    [20634758]     Ответить | Цитировать Сообщить модератору
 Re: расчет прироста транзакционного лога  [new]
msLex
Member

Откуда:
Сообщений: 7730
Владислав Колосов
MacaronicTragedy,

почему получилось на два - не совсем понятно. Индексы есть в таблице?

Потому что в логе резервируется место для записи undo операции (обидно будет, если rollback не сможет выполниться из-за нехватки место в логе).

для delete undo операция - это insert. Обе эти операции в логе занимают примерно размер самой записи.
11 июл 17, 19:38    [20634764]     Ответить | Цитировать Сообщить модератору
 Re: расчет прироста транзакционного лога  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30786
msLex
Владислав Колосов
MacaronicTragedy,

почему получилось на два - не совсем понятно. Индексы есть в таблице?

Потому что в логе резервируется место для записи undo операции (обидно будет, если rollback не сможет выполниться из-за нехватки место в логе).

для delete undo операция - это insert. Обе эти операции в логе занимают примерно размер самой записи.
undo разумеется требует размера записей.
Но сама то операция delete почему требует место??? Ну, кроме метаданных операции.
Разве что при маленьком размере записи, тогда понятно.
11 июл 17, 19:52    [20634795]     Ответить | Цитировать Сообщить модератору
 Re: расчет прироста транзакционного лога  [new]
msLex
Member

Откуда:
Сообщений: 7730
alexeyvg
Но сама то операция delete почему требует место???

а исходное значение?
к чему undo-шить то?
11 июл 17, 19:54    [20634798]     Ответить | Цитировать Сообщить модератору
 Re: расчет прироста транзакционного лога  [new]
msLex
Member

Откуда:
Сообщений: 7730
маленькое репро.

create table c(f char(1000) not null)




insert c 
select top 100 replicate('1', 1000)
from sys.objects

checkpoint


begin tran

delete c

rollback



select 
	Operation
	, DATALENGTH([RowLog Contents 0])
	, cast(substring([RowLog Contents 0], 8, 1000) as char(1000))
	, *
from fn_dblog(null, null)
where 
	Operation in (
	'LOP_DELETE_ROWS'
	, 'LOP_insert_ROWS'
	)

drop table c  
11 июл 17, 20:02    [20634813]     Ответить | Цитировать Сообщить модератору
 Re: расчет прироста транзакционного лога  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30786
msLex
alexeyvg
Но сама то операция delete почему требует место???

а исходное значение?
к чему undo-шить то?
Я же сказал - исходное значение будет записано, вот к нему и undo-шить.
А конечное значение какое, если запись удаляется? "пусто"?
11 июл 17, 21:15    [20634923]     Ответить | Цитировать Сообщить модератору
 Re: расчет прироста транзакционного лога  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30786
msLex
маленькое репро.
Некорректно, вы же смотрите записи в логе после роллбака.
А вопрос, почему удвоенный размер до роллбака.
Так что нужно передвинуть запрос из fn_dblog перед роллбаком, или сделать коммит вместо роллбака.
11 июл 17, 21:20    [20634932]     Ответить | Цитировать Сообщить модератору
 Re: расчет прироста транзакционного лога  [new]
msLex
Member

Откуда:
Сообщений: 7730
alexeyvg
Некорректно, вы же смотрите записи в логе после роллбака.
А вопрос, почему удвоенный размер до роллбака.

Я же написал, что при изменении данных в логе резервируется место под undo. Когда SQL Server пишет в лог, он заранее прогнозирует худший сценарий с откатом транзакции.
Представьте что будет, если в момент роллбека в логе не хватит места под обратные операции?

Мое репро показывает под что именно резервируется место при delete.
11 июл 17, 21:25    [20634952]     Ответить | Цитировать Сообщить модератору
 Re: расчет прироста транзакционного лога  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30786
msLex
Я же написал, что при изменении данных в логе резервируется место под undo.
Я пока не вижу, что бы резервировалось.
msLex
Мое репро показывает под что именно резервируется место при delete.

Я вижу, что появляются записи в лог при операции вставки, а потом появляются записи в лог при операции роллбака.

Т.е. из вашего репро это не видно, ну и "снаружи", если сделать операцию без коммита, будет запись в лог, а если откатить, то опять будет запись в лог такого же размера.
11 июл 17, 22:43    [20635127]     Ответить | Цитировать Сообщить модератору
 Re: расчет прироста транзакционного лога  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30786
alexeyvg
msLex
Я же написал, что при изменении данных в логе резервируется место под undo.
Я пока не вижу, что бы резервировалось.
msLex
Мое репро показывает под что именно резервируется место при delete.

Я вижу, что появляются записи в лог при операции вставки, а потом появляются записи в лог при операции роллбака.

Т.е. из вашего репро это не видно, ну и "снаружи", если сделать операцию без коммита, будет запись в лог, а если откатить, то опять будет запись в лог такого же размера.
Легко проверяется - после роллбака появляются записи LOP_INSERT_ROWS
А перед роллбаком, или после коммита, их нет.
11 июл 17, 22:48    [20635139]     Ответить | Цитировать Сообщить модератору
 Re: расчет прироста транзакционного лога  [new]
msLex
Member

Откуда:
Сообщений: 7730
alexeyvg
msLex
Я же написал, что при изменении данных в логе резервируется место под undo.
Я пока не вижу, что бы резервировалось.
msLex
Мое репро показывает под что именно резервируется место при delete.

Я вижу, что появляются записи в лог при операции вставки, а потом появляются записи в лог при операции роллбака.

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


вы разницу между резервируется и записывается понимаете?

еще раз

при записи в лог (в нашем случае удаление строки) в логе резервируется пустое место на случай ролбека.
11 июл 17, 22:54    [20635157]     Ответить | Цитировать Сообщить модератору
 Re: расчет прироста транзакционного лога  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30786
msLex
вы разницу между резервируется и записывается понимаете?
Да.
msLex
при записи в лог (в нашем случае удаление строки) в логе резервируется пустое место на случай ролбека.

Это предположение? "Почему бы им не резервировать?"
И зачем приводить репро, раз оно не показывает это резервирование?

Далее, место резервируется в каком виде?
Резервируется целый VLOG?
В противном случае что будет делать с этим местом сиквел, если он никогда не пишет в лог рандомной записью?

Вместо "больших букв" рассказали бы, что это всё означает, или дали бы ссылку.
11 июл 17, 23:01    [20635181]     Ответить | Цитировать Сообщить модератору
 Re: расчет прироста транзакционного лога  [new]
msLex
Member

Откуда:
Сообщений: 7730
alexeyvg
Это предположение?

это факт. зачем это делается я уже написал
msLex
на случай ролбека.


alexeyvg
И зачем приводить репро, раз оно не показывает это резервирование?

как я уже писал, репро показывает под что именно резервируется место в логе.

alexeyvg
Далее, место резервируется в каком виде?

в том же, в котором оно "захватывается" под запись обычных данных.

alexeyvg
что будет делать с этим местом сиквел

после окончания транзакции (коммит) высвободит его.

alexeyvg
что это всё означает

это значит именно то, что я написал

alexeyvg
дали бы ссылку.

к сожалению, ссылку привести не могу.
вам остается либо верить тому что написано, либо считать что вас пытаются обмануть.
11 июл 17, 23:14    [20635219]     Ответить | Цитировать Сообщить модератору
 Re: расчет прироста транзакционного лога  [new]
invm
Member

Откуда: Москва
Сообщений: 9123
alexeyvg
Далее, место резервируется в каком виде?
Резервируется целый VLOG?
В противном случае что будет делать с этим местом сиквел, если он никогда не пишет в лог рандомной записью?
Резервируется в виде свободного места в конце журнала, достаточного для записи компенсационных записей (которые возникают при роллбеке) для всех открытых транзакций. Т.е. в самих записях лога ничего не резервируется.
11 июл 17, 23:29    [20635239]     Ответить | Цитировать Сообщить модератору
 Re: расчет прироста транзакционного лога  [new]
MacaronicTragedy
Member

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

перепроверил ddl. один кластерный индекс всего, он же primary key. из допов - куча extended property и default constraint, но не думаю, что они могут влиять на генерацию записей лога.
значит, получается, все-таки резервируется место под rollback?
Если это имеет значение, размер замерял с помощью DBCC SQLPERF(logspace) на заранее нарощенном (с запасом) файле лога.
12 июл 17, 09:38    [20635680]     Ответить | Цитировать Сообщить модератору
 Re: расчет прироста транзакционного лога  [new]
alexeyvg
Member

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

перепроверил ddl. один кластерный индекс всего, он же primary key. из допов - куча extended property и default constraint, но не думаю, что они могут влиять на генерацию записей лога.
значит, получается, все-таки резервируется место под rollback?
Если это имеет значение, размер замерял с помощью DBCC SQLPERF(logspace) на заранее нарощенном (с запасом) файле лога.
А ширина таблицы какая?
Причина может быть в том, что место расходуется на разные дополнительные поля в записях в журнале.
Если размер записи - единицы-десятки байт, то процент служебной информации будет не такой уж маленький.
12 июл 17, 10:26    [20635871]     Ответить | Цитировать Сообщить модератору
 Re: расчет прироста транзакционного лога  [new]
MacaronicTragedy
Member

Откуда:
Сообщений: 99
alexeyvg,
сумма datalength всех полей - 299 байт.
12 июл 17, 10:33    [20635908]     Ответить | Цитировать Сообщить модератору
 Re: расчет прироста транзакционного лога  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30786
invm
alexeyvg
Далее, место резервируется в каком виде?
Резервируется целый VLOG?
В противном случае что будет делать с этим местом сиквел, если он никогда не пишет в лог рандомной записью?
Резервируется в виде свободного места в конце журнала, достаточного для записи компенсационных записей (которые возникают при роллбеке) для всех открытых транзакций. Т.е. в самих записях лога ничего не резервируется.
В конце? В конце VLOG, или в другом VLOG?
Писать в лог до коммита может долго, файл при этом будет расширяться, сервер будет заполнять один виртуальный журнал за другим...

Выглядит как фантастика.

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

Ещё раз, что показывает репро, где вы увидели "резервирование места", какие именно записи на него указывают?

Конечно, это нормально, что вы не можете дать пруф, все мы когда то что то узнали, и, конечно, не можем показать исходный материал, тем более, что интернет сейчас с короткой памятью, а поисковики давно ищут не в контенте, а среди рекламных материалов :-)

Тем не менее, у меня вызвало недоверие именно репро, именно из него я вижу, что резервирования нет, в ответ на вопрос о репро вы третий раз говорите, что "оно показывает".
12 июл 17, 10:44    [20635958]     Ответить | Цитировать Сообщить модератору
 Re: расчет прироста транзакционного лога  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 30786
msLex
alexeyvg
что будет делать с этим местом сиквел

после окончания транзакции (коммит) высвободит его.
Перед коммитом, и после коммита, fn_dblog возвращает одно и тоже, правильно?

Функцией fn_dblog можно увидеть это место, зарезервированное во время транзакции, перед коммитом или роллббэком?
12 июл 17, 10:49    [20635977]     Ответить | Цитировать Сообщить модератору
 Re: расчет прироста транзакционного лога  [new]
o-o
Guest
простите, лень все читать,
вы тут правда думаете, что под роллбэк не резервируется место (ровно то же, что и под саму операцию)
или претензии именно к репро?
самое правильное репро для того, чтобы увидеть, что там резервируется,
ето ограничить лог.
выставить ему запрет приращения и попытаться удалить столько,
сколько в имеющийся лог влезет.
операция просто обломается по причине недостатка места в логе.
у меня на работе больше нет тестового сервера,
но если кому-то особо надо и сам не может воспроизвести, из дома запостю
12 июл 17, 11:18    [20636101]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить