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

В этой главе, если явно не оговорено обратное, параметр CUR-SOR_SHARING во всех примерах установлен в значение EXACT. Срав­нение точного и неточного соответствий см. ниже в разделе «Ал­горитмы сопоставления».

В следующих разделах мы объясним, как Oracle принимает решение о повторном использовании курсора. Эти знания будут исключительно полезны при планировании повторного использования курсора. К со­жалению, многие пишущие на PL/SQL разработчики находятся в бла­женном неведении даже о существовании такой концепции, поэтому администраторам вдвойне необходимо понимание принципов повтор­ного использования курсоров и последствий этого использования. Сначала мы рассмотрим некоторые детали алгоритма хеширования Oracle, а затем перейдем к нюансам повторного использования курсо­ров. Рекомендуем вам прочитать весь раздел, прежде чем встраивать в свое приложение механизмы (реальные или предполагаемые) по­вторного использования.