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

Question

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

Мой вопрос: означает ли это, что базе данных никогда не приходится компилировать эти подготовленные операторы?Посылает ли драйвер JDBC какое-то предварительно скомпилированное представление, или все же в самой базе данных происходит какой-то синтаксический анализ / компиляция?

Answer 1

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

Итак, что происходит: если используется подготовленный оператор, а физическое соединение его никогда не видело, он отправляет 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.

Answer 2

Я думаю, что это отвечает на ваш вопрос: (извините, это 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 (или дБ по выбору)будет хранить подготовленный оператор, Java просто отправит ему тот же оператор, из которого выберет БД (однако это ограниченные ресурсы, но после x времени отсутствия запроса общий sql будет очищен, особенно от нечастых запросов), а затем повторно-parse потребуется - будет ли он кэширован в вашем Java-приложении.