Уровни изоляции в Юконе

Merle · Post by **Merle** » 27 Nov 2003 22:17

Попробую воспользоваться позволением Tengiza выяснить что-нибудь о Юконе.
Пока назрело несколько простых вопросов по уровням изоляции, естественно по Snapshot.
1. Допустим есть простая табличка без индексов. Если запустить два update'а из разных транзакций затрагивающих разные записи, то опоздавший update все равно будет ждать на блокировке, не смотря на то, что записи нужны разные.
Происходит это потому, что в данном случае единственный способ доступа - это table scan, которому надо в любом случае перебрать все записи, из-за чего опоздавшая транзакция рано или поздно все равно нарвется на блокировку. У чистого блокировочника альтернативы нет. Однако если есть версионность, то можно поступать в этом случае так, как делает Oracle: он производит версионный прескан, выясняет какие записи нужны, а затем обращается с изменениями уже непосредственно к нужным записям. Я думал, что при уровне изоляции Snapshot точно так же будет поступать и Юкон, однако как выяснилось он все делает по старинке, то есть для update'а идет обычный tablescan с u-блокировкой, поэтому опоздавшая транзакция все равно блокируется.
Так будет и в релизе или все-таки что-то изменится?
2. При SI уровне, если после начала изменений данных snapshot транзакцией, другая транзакция успела поменять данные, которые нужны snapshot транзакции, но до которых она не успела добраться, то snapshot транзакция откатывается без разговоров (в отличии от Oracle'а, который до последнего занимается миниоткатами, пытаясь сдвинуть время старта snapshot транзакции "на попозже"). Вообще это снижает полезность данного уровня для R/W транзакций.
Появится ли (или уже появилась) возможность для автоматического рестарта snapshot транзакции, чтобы не заморачиваться обработкой подобной ситуации на клиенте? (Понятно конечно, что особенно с появлением CLR в сервере это не есть большая проблема, но все-таки это лишние телодвижения)
3. Если базу переключить в режим поддержки snapshot, то уровень read committed автоматически начинает поддерживать версионность на уровне оператора. Гарантируется ли в этом случае, как в Oracle, statement level read consistency, и за счет чего?
Как раз в свете недавних обсуждений того, что Oracle-то здесь немного лукавит и ведет себя не "по честному".
Эта проблема решается так же как и согласованность при snapshot, тоесть откатом оператора при подозрении на несогласованность? И производится ли в этом случае откат все транзакции целиком, или проблемный оператор стартует заново?
4. Я все время ссылаюсь на Оракл, поскольку, как я понимаю, модель версионности взята оттуда практически один в один. Только вариантом сегмента отката в Юконе служит tempdb.
Это действительно так? И если да, то на сколько велики накладные расходы от использования tempdb в качестве сегмента отката?
И каковы основные отличия версионности Юкона от модели Oracle? буквально в двух словах...
Заранее спасибо огромное...

tengiz · Post by **tengiz** » 28 Nov 2003 02:04

Реализация версионности в Yukon мало похожа на то, что сделано в Oracle. Главные отличия:

- В Oracle физическая поддержка версионности делается на уровне страницы данных. Это означает, что когда транзакция сканирует таблицу/индекс и натыкается на страницу, которая была изменена с момента начала транзакции, то Oracle сначала клонирует в памяти текущую версию страницы, а затем по информации в сегменте отката, соответственно, делает мини-откат страницы- клона. Если повезло, и одного отката хватило, то тогда всё хорошо, если же нет, то таких мини-откатов нужно делать больше. Клоны всегда read-only. Предыдущие клоны страницы остаются в buffer manager и могут повторно использоваться другими транзакциями. Инженеры из Oracle представили доклад с более подробным описанием этого процесса, в 1997 году на одной из специализированных конференций по VLDB.

- В Yukon при модификации строки предыдущая версия уходит в version store heaps, которые хранятся в tempdb, а в каждой строке таблиц в базах данных, где включена версионность, хранится указатель на предыдущую версию строки, поэтому для того, чтобы пройти по цепочке версий, чтобы найти нужную, никаких мини-откатов делать не нужно. Т.е. делается не реконструкция предыдущих версий строк, как в Oracle, а просто их прямое чтение из цепочки. При оптимальном размере памяти, а также с учётом особенностей tempdb и отсутствия журналирования для version store, на поддержание и чтение версий требования на дополнительный IO минимальны и нет нехорошей нагрузки на журнал транзакций или сегмент отката, которые очень любят строго последовательный доступ.

- Так как в Yukon, в отличие от Oracle метку с версией имеет каждая строка, а не страница с данными, поэтому Yukon всегда точно знает, есть ли нужная версия строки на текущей странице и поэтому на уровне изоляции snapshot конфликт записи обнаруживается сразу и безошибочно. В Oracle же это не так, строки не имеют метки последней транзакции, метку транзакции имеет сама страница, также есть внутристраничный кеш с некоторой информацией о последних транзакциях (глубина этой мини-истории - настраиваемый параметр) - дальнейшие подробности я опущу, так как это уже совсем не в ту степь. В результате Oracle не всегда может точно определить есть ли нужная версия строки на текущей странице. Поэтому конфликты записи Oracle показывает в несколько более широком классе случаев, чем это реально необходимо, чтобы гарантированно их избежать – здесь Oracle предпочитает «перебдеть», чем «недобдеть», в отличие от политики рестартов на read committed, где всё наоборот - Oracle позволяет себе «недобдеть», откуда и вылезают несогласованные данные в разбираемых в той дискуссии примерах.

- В Yukon отслеживается какая версия строки может понадобиться самой старой snapshot транзакции, поэтому при условии наличия достаточного места в tempdb ошибок из-за невозможности слишком «глубокого» отката не возникает благодаря тому, что автоматическая чистка версионного мусора точно знает, что можно чистить, а что ещё может понадобиться.

- В отличие от Oracle, на уровне изоляции snapshot или read committed в базах, где версионность разрешена, insert/update/delete запросы всегда работают в нормальном блокировочном режиме, поэтому Вы и видели то, что видели. Дело в том, что обеспечение максимально неблокирующего и гарантированно согласованного выполнения не-readonly запросов при сохранении высокой производительности - вещь нетривиальная. Именно поэтому, я полагаю, Oracle так и не довёл это до конца. Решения этой проблемы, как хорошо известные, так и никому пока кроме чрезвычайно узкого круга лиц, надеюсь, не пришедшие в голову (во всяком случае, я в литературе пока нигде не видел ничего близкого к тем идеям, которые я имею в виду), в действительности существуют, но они алгоритмически значительно сложнее, чем это может показаться. Просто мини-рестарты могут оказаться, во-первых, слишком накладными, во-вторых, при неблагоприятных обстоятельствах один и тот же оператор, возможно, придётся перезапускать многократно.

Кстати, Oracle никогда автоматически не перестартует запросы на уровне изоляции serializable (это практически то, что в Yukon называется snapshot, хотя в Yukon, в действительности, это несколько более сильный уровень изоляции, чем у Oracle, например, некоторые специальные виды фантомов, которые допускает Oracle, Yukon никогда не пропустит). Т.е. при конфликте записи всегда выдаётся ошибка сериализации. Автоматический рестарт запроса Oracle делает на read committed. В Yukon на уровне read committed, позволю себе повториться, где не-select запросы работают в обычном блокировочном режиме, для insert/update/delete отличий от нормального блокировочного read committed нет, поэтому нет и рестартов.

Функциональность в основном до релиза уже меняться не будет. Поэтому никаких новостей в части изоляции транзакций уже можно не ждать. За исключением того, что версионность на read committed для баз, где она разрешена, будет включена по умолчанию, а не под специальным traceflag, как это сделано в первой бете.

<added>
Перечитал и нашёл небольшую, но важную недосказанность - блокировочный режим insert/update/delete относится только к обновляемой таблице, всё остальное читается версионным сканом.
</added>

Merle · Post by **Merle** » 28 Nov 2003 13:23

Спасибо огромное, очень все интересно...

tengiz wrote:В Oracle физическая поддержка версионности делается на уровне страницы данных.

Да, этот момент я упустил, мне почему-то казалось, что в Oracle так же физически версионность поддерживается на уровне строк, примерно по такому же принципу, что и в yukon'е.

tengiz wrote:В Yukon при модификации строки предыдущая версия уходит в version store heaps, которые хранится в tempdb, а в каждой строке таблиц в базах данных, где включена версионность, хранится указатель на предыдущую версию строки, поэтому для того, чтобы пройти по цепочке версий, чтобы найти нужную, никаких мини-откатов делать не нужно. Т.е. делается не реконструкция предыдущих версий строк, как в Oracle, а просто их прямое чтение из цепочки.

То есть механизм Юкона получается выгоднее чем Оракла? Но на сколько я понимаю чтения из tempdb все равно происходят по странично и если нужно спуститься на несколько версий "вниз" по цепочке, для одной записи, то понадобится прочитать несколько страниц? Или Юкон заранее знает какая врсия ему нужна и читает только ее?

tengiz wrote:Кстати, Oracle никогда автоматически не перестартует запросы на уровне
изоляции serializable...

Ой.. Это мне просто пятерка за внимательность. Читал я вот этот топик на Ask Tom http://asktom.oracle.com/pls/ask/f?p=49 ... 4247549852 И слово snapshot меня обмануло, а то что речь там про statement, я не очеь разглядел....

tengiz wrote:это практически то, что в Yukon называется snapshot, хотя в Yukon, в действительности, это несколько более сильный уровень изоляции, чем у Oracle, например, некоторые специальные виды фантомов, которые допускает Oracle, Yukon никогда не пропустит

А можно вот здесь вот по подробнее... Как я понимаю Write Skew пропустит и Oracle и Yukon. Оракл старается перебдеть, и если не уверен, то откатывает. Yukon же уверен всегда, поэтому откатывает только тогда, когда надо.
За счет чего в Юконе snapshot сильнее и какие феномены возможны в Oracle при serializable(я имею ввиду Оракловский Ser. который на самом деле скорее snapshot), но невозможны в Юконе при sanpshot?

Dmitry67 · Post by **Dmitry67** » 28 Nov 2003 13:49

Да
Версинность была очень важным преимуществом Oracle
Посмотрим какой будет его ответ

zVlad · Post by **zVlad** » 28 Nov 2003 15:29

Dmitry67 wrote:Да
Версинность была очень важным преимуществом Oracle
Посмотрим какой будет его ответ

Это спорное как Вы, Дима, знаете утверждение. Не из-за версионности Оракл брали и берут, и едва ли Оракл будет отвечать как-либо: на объем продаж это не повлияет.
Мне наоборот интересно - а зачем MS это понадобилось? Какие маркетинговые показания имеются чтобы это имплементировать? Что программисты для SQL стонут и ничего не могут делать? Или это позволит уменьшить цену SQL? Не из-за проблем ли внедрения snapshot MS задерживает выпуск Yukon и теряет деньги?

Dmitry67 · Post by **Dmitry67** » 28 Nov 2003 15:30

Проблема OLAP и OLTP на одной и той эе базе стоит в MS SQL очень остро

zVlad · Post by **zVlad** » 28 Nov 2003 16:14

Эта проблема решается элементарно репликацией (warehouse, data mart and so on). А также адекватным пониманием того что есть OLAP и что есть OLTP. Я имею в виду когда говорят что мол нужен отчет по всей базе и именно на любой текущий момент времени - то это есть не понимание сути OLAP. Проблема устраняется путем непродолжительной душевной беседы с тем кто этого просит.

Dmitry67 · Post by **Dmitry67** » 28 Nov 2003 16:16

zVlad wrote:Эта проблема решается элементарно репликацией (warehouse, data mart and so on). А также адекватным пониманием того что есть OLAP и что есть OLTP. Я имею в виду когда говорят что мол нужен отчет по всей базе и именно на любой текущий момент времени - то это есть не понимание сути OLAP. Проблема устраняется путем непродолжительной душевной беседы с тем кто этого просит.

Так просто ? И элементарно ?
zVlad, Вы можете зашибать огромные деньги путем "непродолжительной душевной беседы". Мы тут просто ничего не понимаем.

tengiz · Post by **tengiz** » 28 Nov 2003 18:14

Merle wrote:То есть механизм Юкона получается выгоднее чем Оракла? Но на сколько я понимаю чтения из tempdb все равно происходят по странично и если нужно спуститься на несколько версий "вниз" по цепочке, для одной записи, то понадобится прочитать несколько страниц? Или Юкон заранее знает какая врсия ему нужна и читает только ее?

Главный выйгрыш в Yukon - остутствие необходимости реконструировать предыдущие версии строк. В Oracle для перехода к каждой нетекущей версии строки в нужно создавать клон и делать мини-откат. Это довольно дорого и с точки зрения памяти, и с точки зрения CPU. Разумеется, цепочка версий в Yukon может оказаться на разных страницах, но благодаря оптимизациям в tempdb, нагрузка на ввод/вывод минимизируется и только в худшем случае стоит примерно столько же как и чтение из сегмента отката в Oracle.

А можно вот здесь вот по подробнее... Как я понимаю Write Skew пропустит и Oracle и Yukon. Оракл старается перебдеть, и если не уверен, то откатывает. Yukon же уверен всегда, поэтому откатывает только тогда, когда надо. За счет чего в Юконе snapshot сильнее и какие феномены возможны в Oracle при serializable(я имею ввиду Оракловский Ser. который на самом деле скорее snapshot), но невозможны в Юконе при sanpshot?

Write skew разумеется можно наблюдать и в Yukon, но благодаря блокировочному скану для insert/update/delete, некоторые казуистические случаи фантомов не проходят, как это было бы в Oracle, а вызывают update conflict. Опять же - речь идёт только об очень узком подможестве проблем, где блокировочность скана для update позволяет частично их ловить. Но это не означает, что есть какие-то недостатки с реализацией оракловского snapshot. Это Yukon слегка более строг, чем классический snapshot.

tengiz · Post by **tengiz** » 28 Nov 2003 18:26

zVlad wrote:Не из-за проблем ли внедрения snapshot MS задерживает выпуск Yukon и теряет деньги?

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

Деньги если и начнут теряться, то только после второй публичной беты, когда основная масса пользователей, соблазнившись набором новых возможностей следующей версии сервера, перестанет покупать SQL Server 2000 в ожидании выхода Yukon.

Merle · Post by **Merle** » 28 Nov 2003 19:27

tengiz wrote:Write skew разумеется можно наблюдать и в Yukon, но благодаря блокировочному скану для insert/update/delete, некоторые казуистические случаи фантомов не проходят, как это было бы в Oracle, а вызывают update conflict.

А можно небольшой пример, хотя бы схематический?....

Но это не означает, что есть какие-то недостатки с реализацией оракловского snapshot. Это Yukon слегка более строг, чем классический snapshot.

Да, я понимаю, что Оракловский снапшот работает по всем правилам. Просто мне немного непонятна разница между классическим снапшотом, и тем, что реализовано в Юконе.
Понятно, что разборки происходят не при фиксации, а раньше, при попытке изменить версию зафиксированную после старта снапшот транзакции, но в данном случае это не имеет никакого значения, если я правильно понял...

tengiz · Post by **tengiz** » 28 Nov 2003 21:58

Merle wrote:А можно небольшой пример, хотя бы схематический?....Просто мне немного непонятна разница между классическим снапшотом, и тем, что реализовано в Юконе. Понятно, что разборки происходят не при фиксации, а раньше, при попытке изменить версию зафиксированную после старта снапшот транзакции, но в данном случае это не имеет никакого значения, если я правильно понял...

create table a (b int). Исходно таблица пуста.

транзакция 1:

delete a where b in (1,2)
insert into a (b) values (1);

транзакция 2:

delete a where b in (1,2)
insert into a (b) values (2);
commit;

транзакция 1:
commit.

В Oracle на его уровне "serializаble" после такого перемежающегося выполнения этих транзакций в таблице окажется две строки, где b in (1,2), хотя каждая транзакция сначала удалила все такие строки, а затем вставила ровно одну такую строку. Очевидно, что последовательное выполнение этих транзакций никогда не привело бы к такому результату. Так как в Oracle не существует предикатных блокировок, то он не в состоянии предложить никакого способа предотвратить такую аномалию, кроме блокировки таблицы целиком.

В Yukon на уровне snapshot ни перемежающееся, ни последовательное выполнение таких транзакций никогда не оставит в таблице больше одной строки с b in (1,2) - будет либо правильный результат, либо update conflict. Причина - так как здесь не ни одного select, то всё, что делают транзакции, делается в блокировочном режиме, причём каждый оператор выполняется как если бы это был locking serializable с блокировкой предиката b in (1,2), плюс ещё и дополнительный контроль конфликтов. Поэтому и нет аномалии.

zVlad · Post by **zVlad** » 28 Nov 2003 22:12

Dmitry67 wrote:
zVlad wrote:Эта проблема решается элементарно репликацией (warehouse, data mart and so on). А также адекватным пониманием того что есть OLAP и что есть OLTP. Я имею в виду когда говорят что мол нужен отчет по всей базе и именно на любой текущий момент времени - то это есть не понимание сути OLAP. Проблема устраняется путем непродолжительной душевной беседы с тем кто этого просит.

Так просто ? И элементарно ?
zVlad, Вы можете зашибать огромные деньги путем "непродолжительной душевной беседы". Мы тут просто ничего не понимаем.

А зачем усложнять и гоняться за решениями, которые противоречат естественному ходу вещей в материальной природе и обществе, отражать которые призваны наши системы?
Представьте например ситуацию когда на складе идет приемка новых партии различных единиц хранения и выдача их же. Учет бумажный. Поступает запрос: "А столько у нас на данный момент изделий "Ю" имеется на складе?"
Ваши Варианты решения?

tengiz · Post by **tengiz** » 29 Nov 2003 02:34

zVlad wrote:А зачем усложнять и гоняться за решениями, которые противоречат естественному ходу вещей в материальной природе и обществе, отражать которые призваны наши системы?

zVlad, усложнение, о котором Вы говорите, является таковым только для фирм-производителей СУБД. Для пользователей это только упрощение. Представьте - вместо того, чтобы разворачивать тяжёлую бронетехнику в виде OLAP для получения согласованных отчётов и при этом не подсадить OLTP базу данных, пользватель всего лишь включает режим изоляции snapshot - и извольте, Ваши данные готовы! Цель - удобство и простота работы пользователей.

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

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

Представьте например ситуацию когда на складе идет приемка новых партии различных единиц хранения и выдача их же. Учет бумажный. Поступает запрос: "А столько у нас на данный момент изделий "Ю" имеется на складе?"

Это как раз OLPT проблема. И как Вам здесь поможет OLAP?

zVlad · Post by **zVlad** » 29 Nov 2003 04:12

С тех пор как появился этот интересный топик я, подобно другим, думаю: "А что ответит ИБМ?". И эти думы трансформировались в другой вопрос: "А так ли это надо?".
Да, известен факт, что так называемые прикладные програмисты редко знают об уровнях, блокировках, commit-ах - объяснения этих простых вещей составляет львиную долю моего участия в том что делает наш прикладной суппорт.
А теперь давайте представим чудо - они об этом хорошо знают, учитывают при написании приклада, используют ньюансы существующих механизмов изоляции, избегают проблем конкурентного доступа в корне. Что тогда будет?
Tengiz! Положа руку на сердце скажите: есть нынче, на уровне SQL 2000 неразрешимые проблемы конкурентного доступа? Не надуманные - настоящие, неразрешимые. Я имею в виду, которых нельзя было бы разрешить правильным прикладным решением - не на уровне СУБД?
Согласен, будет круче, не надо будет вкладываться в образование прикладных программеров, СУБД будет толлерантна ко многим глубостям. Наверное это может согреть сердце девелопера СУБД, но.... как-то противится этому душа DBA-я, работающего "в поле".

zVlad · Post by **zVlad** » 29 Nov 2003 04:50

tengiz wrote:
zVlad wrote:А зачем усложнять и гоняться за решениями, которые противоречат естественному ходу вещей в материальной природе и обществе, отражать которые призваны наши системы?

........
Представьте например ситуацию когда на складе идет приемка новых партии различных единиц хранения и выдача их же. Учет бумажный. Поступает запрос: "А столько у нас на данный момент изделий "Ю" имеется на складе?"

Это как раз OLPT проблема. И как Вам здесь поможет OLAP?

Много лет назад, в другой сфере, обсуждался вопрос: что есть диалоговый запрос, а что есть пакетное задание - до сих пор нет однозначного решения. Так же и с OLTP/OLAP. Когда я вижу "online" транзакцию перелопачивающую многомиллионную таблицу (соединение многомиллионнострочных таблиц!) в то время как Service Level Agreement (SLA) требует sub-second responce time, я вспоминаю ту диллему и думаю есть вещи которым нет однозначного определения. Так и с OLTP/OLAP дела обстоят. И, естественно, мне (и любому другому) OLAP никак помочь не может, ни здесь ни где-либо еще поскольку это лишь набор слов, отражающий возмущение против ресурсоемких запросов к базе данных. Правильной (на мой взгляд) реакцией девелоперов СУБД являются: триггеры и их более понятное для прикладных программеров воплощение - материализованные "примочки". Ну не понимаю я SnapShot Isolation Level!

tengiz · Post by **tengiz** » 29 Nov 2003 06:19

zVlad wrote:Tengiz! Положа руку на сердце скажите: есть нынче, на уровне SQL 2000 неразрешимые проблемы конкурентного доступа? Не надуманные - настоящие, неразрешимые. Я имею в виду, которых нельзя было бы разрешить правильным прикладным решением - не на уровне СУБД?...

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

Для опытного разработчика приложений неразрешимых проблем нет

.

Если серьёзно - а Вы разве забыли, что своей популярностью реляционные СУБД и SQL обязаны тем, что системы предыдущих поколений были значительно менее удобны для прикладных программистов? Почему Вы полагаете, что движение в сторону удобства и логичной простоты без ущерба для функциональности и производительности должно почему-то прекратиться?

Даже если проблема оптимальной изоляции транзакций снимется с повестки дня для самого широкого спректра приложений (давайте помечтаем - например, СУБД будут иметь только два надёжных и качественных режима работы каким-то ещё чудом обеспечивающих максимальную параллельность - serializable и readonly), не переживайте - без интересной и уважаемой работы не окажетесь: для DBA и опытных разработчиков приложений баз данных всё равно остаётся огромная область приложения ума и сил помимо шаманства вокруг изоляции транзакций - оптимально построенные модели данных, аккуратно спроектированные и написанные запросы, тонкая настройка производительности приложений, оптимальное индексирование и пр.

tengiz · Post by **tengiz** » 29 Nov 2003 06:32

zVlad wrote:
Поступает запрос: "А столько у нас на данный момент изделий "Ю" имеется на складе?"

Это как раз OLPT проблема. И как Вам здесь поможет OLAP?

Много лет назад, в другой сфере, обсуждался вопрос: что есть диалоговый запрос, а что есть пакетное задание - до сих пор нет однозначного решения. Так же и с OLTP/OLAP.

Ну для меня водораздел между оперативной обработкой транзакций и всем остальным проходит довольно чётко - если данные используются для принятия оперативного решения, причём под решением имеется в виду в том числе и изменение других оперативных данных, и если ошибка при принятии решения должна быть поймана немедленно - то это оперативная обработка. В вашем примере - если ответ на вопрос об изделии Ю нужен для организации немедленной погрузки в вагон, который стоит у ворот, причём если попросили 50 ящиков этого изделия, то в вагон гарантированно должны попасть 50 поэтому никто больше эти 50 ящиков тронуть не должен, то это OLTP. Объёмы обрабатываемой информации - признак вторичный, хотя, как правило, в виду требования "оперативности" объёмы изо всех сил стараются не раздувать.

Правильной (на мой взгляд) реакцией девелоперов СУБД являются: триггеры и их более понятное для прикладных программеров воплощение - материализованные "примочки". Ну не понимаю я SnapShot Isolation Level!

Вы удивитесь как много интересного позволяет сделать snapshot isolation для того, чтобы "триггеры и материализовнные примочки" работали ещё лучше и ещё более оперативно. Дайте срок - обязательно убедитесь.

Merle · Post by **Merle** » 29 Nov 2003 13:16

Хм.. У меня взгляд на версионность примерно таков, поправьте меня, если я ошибаюсь.
Реально именно выигрыш в производительности будет получаться для достаточно узкого круга задач, когда блокировочнику уже начинают при массовых чтениях мешаться пишущие запросы, но этих пишущих запросов еще не на столько много, чтобы начало сказываться замедление от необходимости сохранять устаревшие версии и поиска по этим версиям нужной.
К тому же OLAP/OLTP - это достаточно грубое деление. Обычно нет необходимости выносить OLAP в отдельный экземпляр или сервер, если есть такая необходимость, то никакая версионность не спасет. Как правило все начинается с промежуточных агрегатных табличек, индексированых въюшек, в крайнем случае отдельной базы. Более того, подобное разделение - это практически стандартный паттерн для проектировщика БД, который в конечном итоге дает гораздо больший эффект на выходе нежели версионность, так как тут две отдельных сущности заточенные имено под свои задачи.
Но все же версионность штука очень полезная. От какой же головной боли она может избавить!
Вообще идеальным мне видится вариант, при котором поддержка версий может выставляться не на уровне базы, а на уровне отдельной таблицы.

Dmitry67 · Post by **Dmitry67** » 29 Nov 2003 15:46

zVlad wrote:Эта проблема решается элементарно репликацией (warehouse, data mart and so on). А также адекватным пониманием того что есть OLAP и что есть OLTP. Я имею в виду когда говорят что мол нужен отчет по всей базе и именно на любой текущий момент времени - то это есть не понимание сути OLAP. Проблема устраняется путем непродолжительной душевной беседы с тем кто этого просит.

1. репликацией это не решается никак. Потому что в target database реплицация отливается на основании общих механизмов, так что там тоже возникают блокировки. Короче, та же ж... только вид сбоку. Ну и дополнительный геморрой с репликацией.

2. Дело не в том что хотят отчет в любой момент времени. Если хотят OLAP отчет на 11/11/2003 12:34:45, то это непонимание сути OLAP
Но как правило момент то говорится не потому что секунды важны
А важен просто CONSISTENT отчет. А вот без версионности это ох как сложно !

2 tengiz
Меня порадовали новые возможности Yukon. Я правда пока повозился пару часов а потом у меня упала VMWare

В понедельник переставлю
Пока вот какой минус. Конечно работал я мало... но... c интерфейсом надо чтото делать
То что раньше занимало один клик, теперь целаю проблема. Похоже программисты соревновались у кого больше на экране глюкалок и прогресс баром больше будет, а об эргономике не думали вообще
Это мое частное и предварительное мнение

tengiz · Post by **tengiz** » 29 Nov 2003 18:25

Dmitry67 wrote:Пока вот какой минус. Конечно работал я мало... но... c интерфейсом надо чтото делать То что раньше занимало один клик, теперь целаю проблема.

Спасибо за Ваше частное мнение

Об интерфейсе чего идёт речь? Единственный интерфейс, с которым я сталкиваюсь - это setup, SQL Workbench, и BOL - я больше ничего никогда не включал ввиду сцепифики ядра сервера. Что касается setup - то по-моему там всё достаточно просто. SQL Workbench сначала бесит почти всех (дайте взад наш QA!), но потом, после того, как немного освоишься (через неделю-другую), обратно на QA уже не перетащишь. Тоже почти всех.

tengiz · Post by **tengiz** » 29 Nov 2003 18:45

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

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

Вообще идеальным мне видится вариант, при котором поддержка версий может выставляться не на уровне базы, а на уровне отдельной таблицы.

Возможность включать и выключать поддержку версионности на уровне отдельной таблицы к сожалению не попала в Yukon - по причинам не связанным с ресурсами или временем на разработку/внедрение. Тенхически это элементарно. Но по сути добавляет проблем концептуального характера - например, как делать join таблицы с версиями с таблицами без поддержки весрионности? Очевидно, что о согласованных результатах в таком случае не может идти и речи. Поэтому эта фича ещё требует тщательного продумывания.

Merle · Post by **Merle** » 29 Nov 2003 20:30

tengiz wrote: Тенхически это элементарно. Но по сути добавляет проблем концептуального характера - например, как делать join таблицы с версиями с таблицами без поддержки весрионности? Очевидно, что о согласованных результатах в таком случае не может идти и речи. Поэтому эта фича ещё требует тщательного продумывания.

А как сейчас происходит в Юконе join таблиц из разных баз одна из которых с поддержкой версионности, а другая без?

Что касается WorkBench, то я наоборот, сначала был от него в диком восторге, и пытался даже с 2000 в нем работать =), но потом перешел обратно в QA, уж очень WB медленный... Иногда просто встревает и долго-долго над чем-то думает... Впрочем я склонен списывать все это на его раньюю беттовость, там похоже половина функций not yet implemented..

Да, в BOL есть некая неточность, в том месте, где описывается snapshot уровень изоляции, глава "Understanding Snapshot Isolation". В примере отсутствует команда commit для snapshot трананзакции, из-за этого не ясно когда она завершается, и сам пример похоже не для snapshot транзакции, а для версионного read committed.
Страничка кажется вот эта:ms-help://MS.SQLSVR9/accdb9/htm/acd_locks_4ule.htm

tengiz · Post by **tengiz** » 30 Nov 2003 00:09

Merle wrote:А как сейчас происходит в Юконе join таблиц из разных баз одна из которых с поддержкой версионности, а другая без?

Догадайтесь

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

Да, в BOL есть некая неточность...

Спасибо - я перешлю Вашу находку в группу документации.

Merle · Post by **Merle** » 30 Nov 2003 13:29

tengiz wrote:Догадайтесь .

Лучшая догадка - экспериментально подтвержденная...

Если я Вам еще не надоел

, то вот очередная порция вопросов..
1. Маркируется ли как нибудь последняя запись в цепочке версий в tempdb или в этом нет необходимости? И как вообще происходит очистка устаревших версий? Это какой-то процесс который запускается по расписанию? И учитывается ли при этом как-нибудь нагрузка?
2. Как именно происходит копирование старых версий из базы в tempdb? Может ли возникнуть ситуация при которой пишущая транзакция уже захватила запись на изменение, но зафиксированной копии в tempdb еще не появилось? Как я понял из документации обязанность класть копию записи в tempdb возлагается на изменяющую транзакцию?
3. Проводились ли какие-нибудь хитрые оптимизации над tempdb, возможно даже другая структура? И не вступают ли в конфликт методы оптимизации для версионности и методы оптимизации необходимые для работы с временными таблицами? Не станет ли работа с временными таблицами из-за этого более тяжелой?