MS SQL - row size limit

tengiz · Post by **tengiz** » 27 Mar 2004 17:42

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

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

Merle · Post by **Merle** » 27 Mar 2004 20:22

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

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

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

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

tengiz · Post by **tengiz** » 27 Mar 2004 22:19

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

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

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

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

.

Merle · Post by **Merle** » 27 Mar 2004 23:29

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

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

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

Просим... =)

zVlad · Post by **zVlad** » 28 Mar 2004 17:39

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

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

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

YellowMan · Post by **YellowMan** » 29 Mar 2004 10:37

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

zVlad · Post by **zVlad** » 29 Mar 2004 13:05

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

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

tengiz · Post by **tengiz** » 30 Mar 2004 01:53

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

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

zVlad · Post by **zVlad** » 30 Mar 2004 12:01

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

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

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

tengiz · Post by **tengiz** » 30 Mar 2004 21:17

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

Могут.

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

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

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

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

zVlad · Post by **zVlad** » 30 Mar 2004 22:58

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

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

Maybe. But this is not a case for DB2.

tengiz · Post by **tengiz** » 31 Mar 2004 01:50

zVlad wrote: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 · Post by **zVlad** » 31 Mar 2004 02:16

tengiz wrote:
zVlad wrote: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 · Post by **tengiz** » 31 Mar 2004 03:55

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

zVlad,

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

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

Merle · Post by **Merle** » 31 Mar 2004 08:32

tengiz wrote: 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

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

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

tengiz wrote:В общем - читайте статью Мохана про 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>