Требует ли скомпилированный подготовленный оператор в драйвере базы данных компиляции в базе данных?

Когда вы используете кеш неявных операторов (или расширение Oracle для явного кэша операторов), драйвер Oracle будет кэшировать подготовленный или вызываемый оператор после (!) close() для повторного использования с физическим подключением.

Итак, что происходит: если используется подготовленный оператор, а физическое соединение никогда его не видело, он отправляет SQL в БД. В зависимости от того, видел ли БД оператор раньше или нет, он выполнит жесткий или мягкий анализ. Так что, как правило, если у вас есть 10 пулов соединений, вы увидите 10 синтаксических анализов, один из которых будет жестким синтаксическим анализом.

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

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

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

Вы можете найти подробности здесь:

http://docs.oracle.com/cd/E11882_01/java.112/e16548/stmtcach.htm#g1079466

Также проверьте Oracle Unified Connection Pool (UCP), который поддерживает это и взаимодействует с FAN.

Я думаю, что это отвечает на ваш вопрос: (извините, это PowerPoint, но он определяет, как подготовленный оператор отправляется в Oracle, как Oracle сохраняет его в пуле Shared SQL, обрабатывает его и т. д.). Основной прирост производительности, который вы получаете от подготовленных операторов, заключается в том, что при 1+n-м запуске вы избегаете жесткого синтаксического анализа оператора sql.

http://www.google.com/url?sa=t&source=web&cd=2&ved=0CBoQFjAB&url=http%3A%2F%2Fchrisgatesconsulting.com%2FpreparedStatements.ppt&rct=j&q=java%20oracle%20sql%20prepared%20statements&ei=z0iaTJ3tJs2InQeClPwf&usg=AFQjCNG9Icy6hmlFUWHj2ruUsux7mM4Nag&cad=rja

Oracle (или db по выбору) сохранит подготовленный оператор, java просто отправит ему тот же оператор, из которого выберет db (однако, это ограниченные ресурсы, после x времени отсутствия запроса общий sql будет очищен, особенно от не- общие запросы), а затем потребуется повторный анализ - независимо от того, кэшируется ли он в вашем приложении Java.