|
su.dbms.sql
- SU.DBMS.SQL ------------------------------------------------------------------
From : Vadim Rumyantsev 2:5030/301 06 Feb 2001 23:53:42
To : Tolik Tentser
Subject : Увеличение скорости
--------------------------------------------------------------------------------
Во втоpник, 06 февpаля 2001 17:42:40, Tolik Tentser писал to All:
>> Hет никакой "выборки" и никакого отбора до фетча.
TT> :-) Уф, а я уже было испугался. Просто речь идет о разных
TT> терминологиях. Hа этапе построения плана запроса - MSSQL тоже ничего
TT> не блокирует. Однако же по факту его исполнения - он формирует поток
TT> выбранных данных, который клиенту надлежит забрать. Целиком. Либо
TT> забрать часть, а от остального отказаться. И вот от момента SELECT до
TT> момента, когда клиент забрал с сервера запрошенные данные (или
TT> отказался от дальнейшей выборки) - то, что отобрано, но еще не
TT> считано клиентом - имеет место быть заблокированым.
Так я, собственно, и пишу о том, что DB2 в общем случае ничего не отбирает до
тех пор, пока клиент с помощью функции Fetch не попросил получить данные. Hет
такой ситуации, когда "отобрано, но ещё не считано клиентом", поскольку отбор
как раз и является результатом запроса на считывание. Говоря ещё более другими
словами, DB2 реально исполняет запрос по мере выполнения вызовов Fetch, а не в
результате вызова Execute.
Соответственно, разница не только терминологическая, и DB2 успешно выполняет
предложенный тобой тест со вставкой записи в таблицу во время выборки в другой
задаче. И, как я понимаю, на обычном уровне изоляции CS вполне возможна такая
ситуация, когда последний фетч вернёт данные, которых ещё не было в базе во
время выполнения первого фетча (и тем более обработки Execute).
>> Другое дело, что открытый курсор вообще-то полезно для
>> производительности закрывать пораньше -- это к вопросу об SQLCancel.
TT> А результат SELECT в DB2 - это всегда курсор ?
Да. В результате Execute(select) на сервере создаётся курсор, т.е., грубо
говоря, план доступа к данным. По мере выполнения функций Fetch в этот курсор
выбираются данные и передаются на клиент.
TT> Тут похоже рассогласование на уровне терминологии. В MSSQL оператор
TT> SELECT - курсора не открывает. Он просто отбирает данные и отдает их
TT> все клиенту целиком. Этот процесс и назывался фетчем. Разумеется, если
TT> клиент не готов забрать их все зараз - то процесс приостанавливается и
TT> ждет готовности клиента.
TT> Курсор создается оператором DECLARE <name> CURSOR <options> FOR SELECT
TT> ...
В DB2 тоже есть такой оператор, но он просто делает курсор явным образом
доступным клиенту, т.е. позволяет на него ссылаться из клиентской программы.
TT> Такой курсор (при наличии поддержки клиентского софта, например ADO)
TT> "живет" на сервере, а клиент получает из него данные по одной записи
TT> (и может в нем позиционироваться)
В DB2 не в любом курсоре можно позиционироваться. Обычный курсор допускает IMHO
всего три основные операции: создать (выполнив соответствующий оператор
выборки); прочесть очередную запись с переходом к следующей; закрыть. Hо можно
создавать и более навороченные курсоры, например, с позиционированием или с
возможностью обновления данных по ходу считывания.
Sincerely,
Vadim.
--- GoldED/2 3.0.1-GP
* Origin: Electronic Kludge (2:5030/301)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
