В процессе работы использую базы данных MS SQL 2000, 2008.
Пытаюсь ускорить работу курсоров. Для чего использую ключевое слово "fast_forward" при объявлении курсора.
Читал, что есть ещё серверные курсоры. Но что это такое и как их использовать — смутно понимаю.
Что ещё можно сделать для ускорения работы курсоров?

ppvrt пишет:

> Что ещё можно сделать для ускорения работы курсоров?

Самое главное, что можно сделать для ускорения работы курсоров --
это их не использовать.

Здравствуйте, ppvrt, Вы писали:

P>В процессе работы использую базы данных MS SQL 2000, 2008.
P>Пытаюсь ускорить работу курсоров. Для чего использую ключевое слово "fast_forward" при объявлении курсора.
P>Читал, что есть ещё серверные курсоры. Но что это такое и как их использовать — смутно понимаю.
P>Что ещё можно сделать для ускорения работы курсоров?

Лучше всего от курсоров избавляться ибо это зло. Очень часто, если подумать, можно заменить курсор одним запросом.
Если совсем никак — можно заменять их на WHILE.
Если и это никак (в очень специфических случаях), то объявлять их хотя-бы READONLY.
Ещё можно поиграться со словами FORWARD-ONLY и STATIC.

А серверные курсоры — это и есть курсоры, которые Вы используете

vmpire пишет:

> Лучше всего от курсоров избавляться ибо это зло. Очень часто, если

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

Во всех остальных случах от курсоров надо избавляться.

> Если совсем никак — можно заменять их на WHILE.

На while как раз нет смысла заменять.

> Если и это никак (в очень специфических случаях), то объявлять их
> хотя-бы READONLY.

+1

> Ещё можно поиграться со словами FORWARD-ONLY и STATIC.


+1

Здравствуйте, MasterZiv, Вы писали:

MZ>-- необходимость вызвать процедуру для каждой строки таблицы.

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

MZ>-- наличие алгоритма, обрабатывающего данные в определённом порядке,
MZ>строка за строкой.

Помнится как то обсуждали, что некоторые алгоритмы, требующие обработку в определённом порядке, всё-таки можно переписать без курсоров

MZ>-- необходимость вызвать процедуру для каждой строки таблицы.

Начиная с МССКЛ 2005 есть операторы outer apply/cross apply, которые данный класс задач могут решить без курсоров (хотя вероятно и не все)

Здравствуйте, avpavlov, Вы писали:

MZ>>-- необходимость вызвать процедуру для каждой строки таблицы.

A>Начиная с МССКЛ 2005 есть операторы outer apply/cross apply, которые данный класс задач могут решить без курсоров (хотя вероятно и не все)

апли конечно мощная вещь, но обычно не помогает. Если вызывается процедура — то для какой-то доп обработки с использованием update/insert/delete/raiserror — апли здесь не поможет.

Здравствуйте, ppvrt, Вы писали:
Еще можно попробовать асинхронные курсоры. Но это зависит от задачи...

>> Если совсем никак — можно заменять их на WHILE.
MZ>На while как раз нет смысла заменять.

А что на MS-SQL появилась новая возможность проходить по курсору, кроме как
WHILE @@FETCH_STATUS = 0 ?
Или что вы обсуждаете?

У меня на практике были ситуации когда из сложного запроса (десятки JOINов)
курсор сильно тормозил, переписываешь во временную таблицу, проходишь по ней — не тормозит.
Какие опции использовал уже не помню ...

Аноним 1 wrote:
> А что на MS-SQL появилась новая возможность проходить по курсору, кроме как
> WHILE @@FETCH_STATUS = 0 ?
> Или что вы обсуждаете?

Я полагал, что имелось в виду что-то типа

set rowcount 100

while 1=1
begin
update theTable set ... where ...
if @@rowcount = 0
break
end

других альтернатив курсору с while я не знаю.

> У меня на практике были ситуации когда из сложного запроса (десятки JOINов)
> курсор сильно тормозил, переписываешь во временную таблицу, проходишь по
> ней — не тормозит.

Фантастика.

Здравствуйте, MasterZiv, Вы писали:

>> У меня на практике были ситуации когда из сложного запроса (десятки JOINов)
>> курсор сильно тормозил, переписываешь во временную таблицу, проходишь по
>> ней — не тормозит.

MZ>Фантастика.

Ничего и не фантастика. Я конечно не знаю ситуацию у автора сообщения, но прокрутка
курсора, основанного на очень тяжелых запросах и объявленного без кляузы STATIC или
INSENSITIVE(ISO), очень даже может тормозить.

Здравствуйте, Аноним, Вы писали:

А>У меня на практике были ситуации когда из сложного запроса (десятки JOINов)
А>курсор сильно тормозил, переписываешь во временную таблицу, проходишь по ней — не тормозит.
А>Какие опции использовал уже не помню ...

А вот зря. А то бы как раз оказалось, что использовал ты динамческий обновляемый курсор. И оказалось бы, что оператор select в курсоре имел отвратительный план запроса. А так глядишь объявил курсор хотя-бы так и все получилось бы:

declare cur cursor local fast_forward
    for select ...

Goodkov пишет:

> MZ>Фантастика.
>
> Ничего и не фантастика. Я конечно не знаю ситуацию у автора сообщения,

Я восхищался, восхищался.