Введение

Понятие систем баз данных

В информатике, курсор базы данных — это механизм, позволяющий последовательно просматривать записи в базе данных. Курсоры обеспечивают последующую обработку в сочетании с этим просмотром, такую как извлечение, добавление и удаление записей базы данных. Способность курсора к последовательному просмотру делает его аналогичным концепции итератора в программировании. Программисты баз данных используют курсоры для обработки отдельных строк, возвращаемых запросами к системе баз данных. Курсоры позволяют манипулировать целыми результирующими наборами данных. В этом случае курсор обеспечивает последовательную обработку строк в результирующем наборе. В процедурах SQL курсор позволяет определить результирующий набор (набор строк данных) и выполнять сложную логику построчно. Используя ту же механику, процедура SQL также может определить результирующий набор и вернуть его непосредственно вызывающей процедуре SQL или клиентскому приложению. Курсор можно рассматривать как указатель на одну строку в наборе строк. Курсор может ссылаться только на одну строку в каждый момент времени, но может перемещаться к другим строкам результирующего набора по мере необходимости.

"С ПРИДРЕЖДЕНИЕМ"

Курсоры обычно закрываются автоматически в конце транзакции, то есть при выполнении COMMIT или ROLLBACK (или при неявном завершении транзакции). Это поведение можно изменить, если курсор объявлен с использованием предложения WITH HOLD (по умолчанию – WITHOUT HOLD). Курсор с опцией HOLD остается открытым после COMMIT и закрывается при ROLLBACK. (Некоторые СУБД отклоняются от этого стандартного поведения и также оставляют курсоры с опцией HOLD открытыми после ROLLBACK.) DECLARE имя_курсора CURSOR WITH HOLD FOR SELECT FROM

При выполнении COMMIT курсор с опцией HOLD позиционируется перед следующей строкой. Таким образом, позиционное обновление (UPDATE) или позиционное удаление (DELETE) будут успешны только после выполнения операции FETCH в рамках транзакции. Следует отметить, что JDBC по умолчанию определяет курсоры как поддерживающие опцию HOLD. Это связано с тем, что JDBC также по умолчанию активирует режим автокоммита.

Курсоры в распределенных транзакциях

Использование курсоров в распределенных транзакциях (X/Open XA Environments), управляемых с помощью монитора транзакций, ничем не отличается от использования курсоров в нераспределенных транзакциях. Однако при использовании удерживаемых курсоров следует проявлять осторожность. Соединения могут использоваться разными приложениями. Следовательно, после завершения и фиксации транзакции, последующая транзакция (выполняемая в другом приложении) может унаследовать существующие удерживаемые курсоры. Поэтому разработчику приложения необходимо учитывать такую возможность.

Недостатки курсоров

Следующая информация может варьироваться в зависимости от конкретной системы управления базами данных. Получение строки из курсора может потребовать отдельного сетевого обмена данными при каждом запросе. Это потребляет значительно больше пропускной способности сети, чем обычно требуется для выполнения единого SQL-запроса, например, DELETE. Многократные сетевые обмены могут существенно замедлить операцию с использованием курсора. Некоторые СУБД пытаются уменьшить этот эффект, используя блочную выборку. Блочная выборка подразумевает, что несколько строк отправляются вместе с сервера клиенту. Клиент сохраняет целый блок строк во временном локальном буфере и извлекает строки оттуда, пока буфер не будет исчерпан. Курсоры выделяют ресурсы на сервере, такие как блокировки, пакеты, процессы и временное хранилище. Например, Microsoft SQL Server реализует курсоры путем создания временной таблицы и заполнения ее результирующим набором запроса. Если курсор не закрыт должным образом (не освобожден), ресурсы не будут высвобождены до закрытия самой SQL-сессии (соединения). Такая неэффективная трата ресурсов на сервере может привести к снижению производительности и ошибкам.