|
su.dbms.sql
- SU.DBMS.SQL ------------------------------------------------------------------
From : Tolik Tentser 2:5020/400 06 Feb 2001 18:42:40
To : All
Subject : Re: Увеличение скорости
--------------------------------------------------------------------------------
Hi, Vadim Rumyantsev!
В чреве акулы, пойманной Mon, 05 Feb 2001 22:16:50 +0300,
дети капитана Гранта нашли письмо на тему 'Увеличение скорости':
>Hет никакой "выборки" и никакого отбора до фетча.
:-)
Уф, а я уже было испугался.
Просто речь идет о разных терминологиях. Hа этапе построения плана
запроса - MSSQL тоже ничего не блокирует. Однако же по факту его
исполнения - он формирует поток выбранных данных, который клиенту
надлежит забрать. Целиком. Либо забрать часть, а от остального
отказаться. И вот от момента SELECT до момента, когда клиент забрал с
сервера запрошенные данные (или отказался от дальнейшей выборки) - то,
что отобрано, но еще не считано клиентом - имеет место быть
заблокированым.
>Это всё, конечно, в предположении, что записи выбираются as is, как у тебя в
>примере, или близко к тому. Понятно, что в случае SELECT SUM(F) FROM T всё
>обстоит более хитро.
Hу, это само собой, такие вещи хранятся во временной таблице/памяти
>Другое дело, что открытый курсор вообще-то полезно для производительности
>закрывать пораньше -- это к вопросу об SQLCancel.
А результат SELECT в DB2 - это всегда курсор ?
>У меня появилось страшное подозрение: не хочешь ли ты сказать, что в MS SQL
>нельзя в одной транзакции работать одновременно с двумя запросами, фетча
>потихоньку то из одного, то из другого?
Тут похоже рассогласование на уровне терминологии. В MSSQL оператор
SELECT - курсора не открывает. Он просто отбирает данные и отдает их
все клиенту целиком. Этот процесс и назывался фетчем. Разумеется, если
клиент не готов забрать их все зараз - то процесс приостанавливается и
ждет готовности клиента.
Курсор создается оператором DECLARE <name> CURSOR <options> FOR SELECT
...
Такой курсор (при наличии поддержки клиентского софта, например ADO)
"живет" на сервере, а клиент получает из него данные по одной записи
(и может в нем позиционироваться)
>Или по мере фетча записей из одного
>запроса выдавать другие запросы и получать их результаты?
Если это SELECT - то именно так оно дело и обстоит (ADO объодит эту
ситуацию, автоматически создавая второй коннект при необходимости).
Если это "серверный" курсор - то нет, можно держать их открытыми
сколько угодно.
Bye ...
Тенцер А.Л.
tolik@katren.nsk.ru
ICQ 15925834
--- ifmail v.2.15dev5
* Origin: AO Katren (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
