Result sets, SORTing, etc.... версионность в блокировочниках

zVlad · Post by **zVlad** » 25 Nov 2003 21:24

Разбирал бумаги вчера и наткнулся на статью под названием: "Once Upon a Time in DB2":

http://www.db2mag.com/db_area/archives/ ... mers.shtml

Статье больше года, но с интересом перечитал (читается очень легко), и как-то снова непроизвольно вспомнились наши недавние дебаты об уровнях. Вы угадали: изоляции.
Статья вообще то не об этом или почти не об этом, но подумалось - я не является ли SORTing (а также вероятно GROUPing. Иначе говоря предложения, вынуждающие DB2, и вероятно (почему я собственно и замучиваю тему вновь) MS SQL создавать result sets in some temporary areas, не являются ли эти эффекты своего рода эрзац-версионностью в блокировочнике? Есть в статье и такие слова: "...Use the new v.7 static scrollable cursor, which will store a true cursor result in a declared temporary table in the TEMP database. Updates for scrollable cursors use an optimistic integrity check."
Я по этому ничего особенного сказать не могу, так как я на версии 6. Может кто из DB2-шников на версии 7 поделится своими знаниями об этом в свете субжа.

Как самостоятельный вопрос интересует, что на эту тему в MS SQL деется. Я бы конечно мог почитать об этом, но тогда бы не получилось темы. Интересно послушать живых спецов.

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

Кстати если кому захочется покритиковать собственно статью и автора - имейте в виду, что автор весьма неординарная, очень известная фигура в DB2 world. Типа Тома в Оракл.

tengiz · Post by **tengiz** » 27 Nov 2003 19:05

В MS SQL бывают: firehose, static, keyset и dynamic курсоры. Конкретный тип курсора определяется тем, чего хотел пользователь и тем, может ли это на самом деле быть предоставлено.

1. firehose - это readonly forwardonly курсор, который может быть открыт для любого select. Это самый "экономный" и самый быстрый тип курсора. Для него требуется минимум возможных ресурсов. Аналога в DB2 и ORACLE не существует, насколько я знаю. А в Sybase, разумеется, имеется. В зависимости от конкретного запроса, для которого открыт курсор, для результатов может использовать промежуточное хранилище в tempdb. Так как курсор readonly, то никаких проблем это не вызывает.

2. static - readonly, scrollable курсор, может быть открыт для любого оператора select. Все результаты сначала копируются во временное хранилище, затем по копии можно делать навигацию. Так как static курсор тоже бывает только readonly, никаких проблем промежуточная копия данных не вызывает.

3. keyset - read/write, scrollable курсор. Может быть открыт только для оператора select, набор колонок которого обеспечивает уникальную идентификацию строки. Реализован следующим образом: в tempdb создаётся копия keyset - подмножества колонок, которая однозначно идентифицирует строки. После чего делается навигация по keyset, при переходе между строк keyset выбираются соответствующие строки из "живых" данных благодаря наличию однозначного соответствия.

4. dynamic - read/write, scrollable курсор - самый "приближённый" к исходным данным. Это фактически навигация по "живым" данным. Так как это невозможно для любого наперёд заданного оператора select, то для открытия такого курсора нужно соблюсти ряд формальностей. Например, dynamic курсор не может быть открыт для запроса, который для сортировки должен использовать промежуточное хранилище; запрос не должен содержать подзапросы; запрос не должен содержать order by для которого нет подходящего индекса и пр.

Приложение при определении курсора запрашивает конкретный тип курсора, сервер, в свою очередь, исходя из реальной ситуации откроет максимально близкий к запрошенному вариант. Наиболее часто используемый курсор - это, разумеется, firehose. Но "культурная особенность" SQL Server, которая отражена в конкретном наборе свойств T-SQL, заключается в том, что на серверной стороне стараются не использовать курсоры вообще, стараются всегда работать с наборами строк, а не с отдельными строками, что больше отвечает реляционному духу, чем антиреляционные курсосы. Что часто является причиной неудобств для тех, кто переходит на SQL Server с других продуктов. Им приходится ломать свои привычки и начинать думать иначе.

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

Спасибо, Tengiz, за обстоятельный рассказ. С позиций DB2 (да простится мне эта вольность) удивлюсь тому что при объявлении курсора можно указать какого он типа (хотя SQL сам будет затем решать какой на самом деле возможен): в DB2 явно этого сделать нельзя (может быть за исключением scrolable cursors) и это правильно - разработчики системы должны быть вольны изменять внутренюю кухню от версии к версии. В DB2 этим можно управлять извне приложения, неявно.
Как все таки насчет идеи псевдо-версионности, реализуемой через result set? Мне кажется (подвернется случай проверю) что та ситуция, недавно предложенная vc, когда блокировочник дает неверную сумму на фоне переноса, могла бы быть устранена путем изменения access path с чтения реальных данных в чтение result set-а.

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

zVlad wrote:Как все таки насчет идеи псевдо-версионности, реализуемой через result set? Мне кажется (подвернется случай проверю) что та ситуция, недавно предложенная vc, когда блокировочник дает неверную сумму на фоне переноса, могла бы быть устранена путем изменения access path с чтения реальных данных в чтение result set-а.

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