1Сак уже было сказано, курсор FAST FORWARD неявно преобразуется в курсор другого типа при многих обстоятельствах. В табл. 15.1 кратко описаны причины, по которым может быть выполнено такое преобразование.

Таблица 15.1. Условия выполнения преобразования курсора fastforward

Условие Тип, в который

преобразуется курсор

Основополагающий запрос требует, чтобы была создана Статический

временная таблица

Основополагающий запрос по своему характеру является Ключевой

распределенным

Курсор объявлен как курсор for update Динамический

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

Автору приходилось слышать о том, что курсор может быть преобразован и в дру-ГР1Х обстоятельствах, но он не обнаружил никаких сведений об этом в документации и не столкнлся с такой ситуацией непосредственно.

Если вы когда-либо обнаружите наиболее неприятное явление, которое может возникнуть в процессе эксплуатации программного обеспечения (непредсказуемые результаты), то следует воспользоваться системной хранимой процедурой sp describe cursor для изучения всех опций применяемого курсора, активизированных в настоящее время.

Следует также отметить, что все курсоры FAST FORWARD предназначены только для чтения. В объявлении курсора FAST FORWARD допускается явно задавать опцию FOR UPDATE, но, как указано в табл. 15.1 с описанием условий преобразования, такой курсор будет неявно преобразован в динамический.

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

Во-первых, курсоры FAST FORWARD обеспечивают предварительную выборку данных. Под этим подразумевается то, что одновременно с открытием курсора автоматически производится выборка первой строки, что позволяет сократить количество циклов обмена данными с сервером на единицу, если курсор эксплуатируется в среде клиент/сервер с использованием интерфейса ODBC. Но, к сожалению, такая возможность доступна только при условии применения ODBC.

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

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

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

Варианты организации параллельной работы

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

Это обусловлено несколькими причинами, описанными ниже.

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

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

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

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

В СУБД SQL Server предусмотрены три опции, указанные ниже, которые позволяют смягчить остроту этих проблем.

READ ONLY.

SCROLL LOCKS (в большинстве случаев применение этой опции равносильно применению пессимистических блокировок).

OPTIMISTIC.

1Саждая из этих опций имеет свои особенности, поэтому ниже приведено их последовательное описание.

Опция READ ONLY

Опция READ ONLY предусматривает применение курсоров только для чтения, поэтому не приходится беспокоиться по поводу того, что в каком-то курсоре будет предпринята попытка получения какой-либо блокировки обновления или исключительной блокировки. Не приходится также задумываться над тем, что в каком-то другом приложении считанные с помощью курсора данные будут модифицированы в то время, как осуществляется подготовка данных для обновления с помощью курсора. Благодаря устранению этих двух предпосьшок к возникновению нарушений в работе организация приложения намного упрощается.

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

Опция SCROLL LOCKS

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

Применяются ли транзакции.

Чему равен установленный уровень изоляции транзакции.

Следует отметить, что блокировки, устанавливаемые с помощью опции SCROLL LOCKS, отличаются от блокировок обновления, которые рассматривались в главе данной книги, посвященной описанию блокировок и транзакций.

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

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

Рассмотрим пример того, как применяется опция SCROLL LOCKS, на базе значительно сокращенной версии сценария, который использовался в большей части настоящей главы: USE AdventureWorks

/* Создается таблица, с которой будут проводиться эксперименты в этот раз */ SELECT SalesOrderlD, CustomerlD