MS SQL - row size limit

[YellowMan]

Как только начнёт всерьёз тревожить - вот тогда посмотрим.

За 10 лет в бизнесе я только 2 раза видел таблицу ширина которой была больше 8К - и оба раза это было неграмотное проектирование. К своему стыду один из разов был мой - но зато очень давно

Правильно ли я понимаю что если бы была возможность менять размер страницы - в идеале для каждой таблицы - проблема бы ушла с сытыми волками и целыми овцами ? К примеру сделать страницу кратной размеру strip в RAID array. Или слишком много переделывать ? Или я не все понимаю ?

И раз уж пошла беседа - еще один злосный оффтопик : с каким уровнем блокировки выполняется rollback ? Иными словами могут ли 2 конкурентных rollback попасть в deadlock и если могут, то что сделает сервер ?

[zVlad]

DB2 предлагает на выбор страницы размером 4, 8, 16, 32К на выбор. Соответственно длина строки ограничивается по разному. Страница выбирается на уровне табличного пространства, т.е. в принципе каждая отдельная таблица может иметь свой размер (из доступных) страницы.
Кроме того архитектура дисков мэйнфрэйм позволяет осуществлять чтение/запись множества страниц за одну операцию ввода/вывода.
При этом DB2 осуществляет (подобно другим базам) чтение с опережением в порядке кластерирующего индекса, или по списку (list prefetch) если таковой индекс не используется.

[tengiz]

Правильно ли я понимаю что если бы была возможность менять размер страницы - в идеале для каждой таблицы - проблема бы ушла с сытыми волками и целыми овцами ? К примеру сделать страницу кратной размеру strip в RAID array. Или слишком много переделывать ? Или я не все понимаю ?

По теперешним временам если что-то всерьёз переделывать, то сразу на страницы переменного размера, а не просто дать возможность выбирать из нескольких фиксированных. И это заметно усложнит код, которые занимается выделением места на дисках, а также и buffer manager. Но оно того будет стоить, с моей точки зрения. Да и потом, в Yukon исходной проблемы уже нет. Размер переменной части строки там уже не ограничен (однако суммарный размер фиксированных данных по-прежнему ограничен размером страницы.) Но, как нетрудно догадаться, за это придётся платить меньшей эффективностью индексных сканов при наличии "широких" строк.

И раз уж пошла беседа - еще один злосный оффтопик : с каким уровнем блокировки выполняется rollback ? Иными словами могут ли 2 конкурентных rollback попасть в deadlock и если могут, то что сделает сервер ?

Не могут. Единственное икслючение - если это баг. Но никаких известных ошибках в этом коде приводящих к deadlock я не знаю.

[alex_127]

И раз уж пошла беседа - еще один злосный оффтопик : с каким уровнем блокировки выполняется rollback ? Иными словами могут ли 2 конкурентных rollback попасть в deadlock и если могут, то что сделает сервер ?

Не могут. Единственное икслючение - если это баг. Но никаких известных ошибках в этом коде приводящих к deadlock я не знаю.

Process in rollback can't be killed by deadlock detection. If all processes involved in deadlock are unkillable you have an unresolved deadlock.
I'm aware of only one bug which was fixed as QFE for SQL2000 when we got into this state. Please PM if you need additional info/have a repro.

[Dmitry67]

А при каких случаях для rollback вообще надо кого то ждать кроме диска ?

[tengiz]

А при каких случаях для rollback вообще надо кого то ждать кроме диска ?

Когда, например, при rollback приходится делать page split.

[Merle]

По теперешним временам если что-то всерьёз переделывать, то сразу на страницы переменного размера, а не просто дать возможность выбирать из нескольких фиксированных. И это заметно усложнит код, которые занимается выделением места на дисках, а также и buffer manager. Но оно того будет стоить, с моей точки зрения.

Хм... А что имеется ввиду под переменым размером? Разный размер страницы на разных таблицах? Но тогда это еще и заморочки для оптимизатора, поскольку будет разная стоимость дисковых операций для разных таблиц, если я правильно понимаю...
Опять-таки, если насколько я представляю, размер станицы делается кратным размеру дискового сегмента, что повышает эффективность чтения и гарантирует, что в случае записи страницы в сбойный сегмент диска не повредятся данные другой страницы (и другой транзакции), оказавшееся в этом же сегменте (то есть две страницы в один сегмент не попадают). Таким образом совсем произвольный размер страницы (кратный размеру записи?) сделать вряд ли получится...

Когда, например, при rollback приходится делать page split.

Но в этом случае уже работают всяческие низкоуровневые latch'и и прочие spin lock'и, которые deadlock-монитором не отслеживаются, и если бы в этом месте был баг, то он вылезал бы не только при rollback'ах, но и в других местах...?

[tengiz]

Хм... А что имеется ввиду под переменым размером?

Переменный - значит меняющийся в течение времени жизни страницы. Разумеется, при этом размер должен быть "хорошим", т.е. кратным размеру дискового кластера. Смысл в том, что для современных дисков записать целую дорожку и записать несколько секторов - в среднем примерно одно и то же по затратам. Поэтому страница БД умещающаяся на целую дисковую дорожку для специальных случаев, когда делается много последовательных сканов или последовательных записей - вполне реальная идея.

Но в этом случае уже работают всяческие низкоуровневые latch'и и прочие spin lock'и, которые deadlock-монитором не отслеживаются, и если бы в этом месте был баг, то он вылезал бы не только при rollback'ах, но и в других местах...?

Нет это не так. deadlock-монитор на самом деле ослеживает не только собственно блокировки - alex_127 может много про это интересного рассказать .

[Merle]

Поэтому страница БД умещающаяся на целую дисковую дорожку для специальных случаев, когда делается много последовательных сканов или последовательных записей - вполне реальная идея.

Ясно, спасибо..

Нет это не так. deadlock-монитор на самом деле ослеживает не только собственно блокировки - alex_127 может много про это интересного рассказать .

Просим... =)

[zVlad]

Хм... А что имеется ввиду под переменым размером?

Переменный - значит меняющийся в течение времени жизни страницы. Разумеется, при этом размер должен быть "хорошим", т.е. кратным размеру дискового кластера. Смысл в том, что для современных дисков записать целую дорожку и записать несколько секторов - в среднем примерно одно и то же по затратам. Поэтому страница БД умещающаяся на целую дисковую дорожку для специальных случаев, когда делается много последовательных сканов или последовательных записей - вполне реальная идея.
.............

В архитектуре дисков для мэйнфрэйм используется метод, позволяющий записывать на дорожку блоки данных любой длины. От одного байта до того размера который позволяет длина дорожки. Архитектура этих дисков называется CKD - счетчик-ключ-данные, вторая используемая архитектура дисков, которую Вы только и имеете в виду - FBA.
Несмотря на способность дисков мэйнфрэйм хранить блоки данных любой длины, большинство современных продуктов (DB2 в том числе) на мэйнфрэйм используют фиксированный размер блока. DB2 как я уже упоминал предлагает набор таких блоков (страниц) размерами 4К, 8К, 16К и 32К. При этом под каждый размер требуется создается соответствующий буферный пул(ы).

[YellowMan]

Просим, просим ! Deadlocks for dummies, please !
Ведь для того чтобы что-то изменить, надо что-то залочить. И не факт что сервер еще держит необходимые локи на объекте. Значит ему надо будет изменить тип блокировки. Значит теоретически возможен deadlock ?

[zVlad]

Просим, просим ! Deadlocks for dummies, please !
Ведь для того чтобы что-то изменить, надо что-то залочить. И не факт что сервер еще держит необходимые локи на объекте. Значит ему надо будет изменить тип блокировки. Значит теоретически возможен deadlock ?

Что значит: "... И не факт что сервер еще держит необходимые локи на объекте.".
Если транзакция еще не завершилась, то безусловно держит, и раз смог получить значит ситуация дедлока не возникла, и следовательно не возникнет при откате - все нужные для этого ресурсы залочены нужным образом.

[tengiz]

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

Почитайте про системные транзакции и про ARIES - метод журналирования транзакций, придуманный Моханом из IBM в начале 90-х и который используется в DB2 и SQL Server. Там всё написано, в том числе когда и зачем может понадобиться залочить доволнительные ресурсы при откате.

[zVlad]

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

Почитайте про системные транзакции и про ARIES - метод журналирования транзакций, придуманный Моханом из IBM в начале 90-х и который используется в DB2 и SQL Server. Там всё написано, в том числе когда и зачем может понадобиться залочить доволнительные ресурсы при откате.

Спасибо за совет, Tengiz, но в данном случае я не вижу нужды так глубоко копать. Я лишь поправил соучастника дискуссии в его неверном предположении, что в пределах транзакции модифицированные данные могут быть освобождены и что для отката их понадобится снова лочит а это может вызвать дэдлок.
Да и вообще, мы кажется ждем признаного специалиста для получения авторитетного объяснения. Он не появляется - вот я и внес свои 5 копеек.

[tengiz]

Спасибо за совет, Tengiz, но в данном случае я не вижу нужды так глубоко копать. Я лишь поправил соучастника дискуссии в его неверном предположении, что в пределах транзакции модифицированные данные могут быть освобождены...

Могут.

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

Может понадобиться, и, соответственно, если есть баги, может случиться дедлок.

Да и вообще, мы кажется ждем признаного специалиста для получения авторитетного объяснения. Он не появляется - вот я и внес свои 5 копеек.

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

[zVlad]

Спасибо за совет, Tengiz, но в данном случае я не вижу нужды так глубоко копать. Я лишь поправил соучастника дискуссии в его неверном предположении, что в пределах транзакции модифицированные данные могут быть освобождены...

Могут.
......

Maybe. But this is not a case for DB2.

[tengiz]

Maybe. But this is not a case for DB2.

I doubt it because C.Mohan is one of the top database authorities that happen to work for IBM and he is the one who invented ARIES (among other very clever things that DB/2 has been using for ages.) I would be really surprized if DB/2 doesn't use ARIES algorithm in logging/recovery.

[zVlad]

Maybe. But this is not a case for DB2.

I doubt it because C.Mohan is one of the top database authorities that happen to work for IBM and he is the one who invented ARIES (among other very clever things that DB/2 has been using for ages.) I would be really surprized if DB/2 doesn't use ARIES algorithm in logging/recovery.

Tengiz, кончайте темнить и ссылаться на авторитеты. Если у Вас есть конкретный сценарий - вынимайте и обыграем его, если это возможно.
Я исхожу из того что знаю о транзакции, как это определено в DB2. Я был бы шокирован узнав, что на самом деле DB2 "отпускает" модифицированные данные до окончания транзакции, до оператора COMMIT. Я запускал UPDATE с уровнем изоляции CS для модификации 200-т строк и наблюдал 200 эксклюзивных замков.

[tengiz]

Tengiz, кончайте темнить и ссылаться на авторитеты. Если у Вас есть конкретный сценарий - вынимайте и обыграем его, если это возможно.
Я исхожу из того что знаю о транзакции, как это определено в DB2. Я был бы шокирован узнав, что на самом деле DB2 "отпускает" модифицированные данные до окончания транзакции, до оператора COMMIT. Я запускал UPDATE с уровнем изоляции CS для модификации 200-т строк и наблюдал 200 эксклюзивных замков.

zVlad,

Читайте внимательнее, что было написано выше - никто не говорит, что какие-то ползьовательские ресурсы будут отпущены до конца транзакции, дело в другом: протокол ARIES выполняет пользовательскую транзакцию как серию коротких системых транзакций, каждая из которых фиксируется отдельно от большой пользовательской и независимо от её исхода. При фиксации каждой системной транзакции все ресурсы (которые обычно невозможно наблюдать при помощи мониторинговых иснтрументов доступных пользователю), заблокированные для конкретной системной транзакции разумеется отпускаются. При выполнении отката пользовательской транзакции выполнятется серия "компенсирующих" системных транзакции, которые опять же фиксируются отдельно и захватывают и освобюждают нужные им ресурсы ровно тогда когда это нужно. Заметьте, что данные видимые пользователю захватываются и освобождаются действительно пользовательской транзакцией. Но для дедлока абсолютно всё равно на чём он случится - на ожиданиях на пользовательских логических данных (индексные ключи или строки) или на низкоуровневых физических системых данных. Если две конкурирующие системные транзакции, выполняемые во время отката пользовательской транзакции нарушат подядок доступа к своим ресурсам, то произойдёт дедлок. Так как все системные транзакции заранее известны и намертво вшиты в код сервера БД, то любые дедлоки из-за неправильного порядка доступа к ресурсам в системной транзкции являются багами.

В общем - читайте статью Мохана про ARIES.

[Merle]

I would be really surprized if DB/2 doesn't use ARIES algorithm in logging/recovery.

Использует конечно, в полный рост.
http://www.almaden.ibm.com/u/mohan/ARIE ... ml#systems

Но для дедлока абсолютно всё равно на чём он случится - на ожиданиях на пользовательских логических данных (индексные ключи или строки) или на низкоуровневых физических системых данных.

А дедлок-монитор бдит за этими низкоуровневыми транзакциями или предполагается, что они "deadlock-free"?

В общем - читайте статью Мохана про ARIES.

Эх, почитаешь ее... Денег за нее хотят, буржуи проклятые, но вроде бы нашел где-то в свободном доступе...

<Add>
Кстсти, одно из свойств ARIES -
No Locking or deadlock during transaction rollback
Since no locking is required during transaction rollback, no deadlocks will involve transactions that are rolling back.

Если я правильно понял, то дополнительных блокировок во время отката все-таки не требуется... Я правда только мельком посмотрел в краткое описание и те совсем уверен. Tengiz, не поясните?
</Add>

[zVlad]

............ Так как все системные транзакции заранее известны и намертво вшиты в код сервера БД, то любые дедлоки из-за неправильного порядка доступа к ресурсам в системной транзкции являются багами.

В общем - читайте статью Мохана про ARIES.

Я замечал что Вы скорее всего именно к этому и клоните. Баг - он и есть баг, в данному случае результатом такого бага будет data corruption и надо будет так или иначе восстанавливать данные.
Вы знаете Tengiz чем отличается девелопмент баз данных от их саппорта (это не наезд, чисто обмен мнением)? За год я в среднем трачу месяц на конкуренси проблем, месяц на производительность, месяц на физическую организацию и реорганизацию, месяц на рефреш тестовых копий, месяц на апгрейды и т.д. и т.п.. Мы конечно Мохана уважаем (хотя для нас достаточно лишь знать что ARIES есть и при этом считаться достаточно образованными сапортчиками), но читать всерьез это не можем, ибо если мы будет читать обо всем с чем приходится сталкиваться, то нам будет некогда саппортить.
Разъяснения Ваши были очень познавательными. Большое спасибо, Tengiz.

[YellowMan]

Соучастником обозвали...я понимаю что не специально, но осадок остался
Я тоже хочу сказать спасибо Тенгизу за разъяснения как оно там все внутри устроено - очень познавательно получается.

[tengiz]

А дедлок-монитор бдит за этими низкоуровневыми транзакциями или предполагается, что они "deadlock-free"?

Дедлок-монитор по факту "доверяет" системным транзакциям намного больше, чем пользовательским транзакциям, да и следить в системной транзакции можно не за всем. Тем не менее, если на ослеживаемых монитором ресурсах случается дедлок, то он будет отловлен - результатом будет скорее всего искажение данных.

Если я правильно понял, то дополнительных блокировок во время отката все-таки не требуется... Я правда только мельком посмотрел в краткое описание и те совсем уверен. Tengiz, не поясните?

Системная транзакция для выполнения отката действительно избегает захвата нормальных блокировок, однако она может нарваться на ожидание на латче/спинлоке, доступности памяти, доступности потока. Если код системных транзакций не содержит багов, то пользователь принципиально не в состоянии написать последовательность действий, которые могли бы вызвать дедлок (неважно, детектирумый или нет) при откате. Это вольный перевод того, что говорит Мохан.