Каково влияние / ограничение выбора оракула с большим количеством переменных связывания?

Question

Во время обработки оператора SELECT наш сервер оракула задохнулся с переменными связывания, близкими к 3500 (!!).

Этот выбор, очевидно, создается динамически с помощью кода, который мы не можем изменить. Во время выполнения этого выбора сервер БД перешел на 100% использование процессора, и наша система почти остановилась.

Мы знаем, как воспроизвести эту проблему. Таким образом, мы можем предотвратить это конкретное состояние. Но мне интересно, если есть способ защитить БД (по конфигурации) от этого типа проблем.

Обновление

Выбор выглядит так:

SELECT "FieldOfChar20"
FROM "TableOf111Krows"
WHERE (   "FieldOfChar20" BETWEEN :a0 AND :a1
    OR "FieldOfChar20" BETWEEN :a2 AND :a3
    OR "FieldOfChar20" BETWEEN :a4 AND :a5
    snip snip
    OR "FieldOfChar20" BETWEEN :a290 AND :a291
    OR "FieldOfChar20" BETWEEN :a292 AND :a293
   )
OR (   "FieldOfChar20" IN
          (:a294,
           :a295,
            snip snip
           :a1292,
           :a1293
          )
    OR "FieldOfChar20" IN
          (:a1294,
           :a1295,
           snip snip
           :a2292,
           :a2293
          )
    OR "FieldOfChar20" IN
          (:a2294,
           :a2295,
            snip snip
           :a3292,
           :a3293
          )
    OR "FieldOfChar20" IN
          (:a3294,
           :a3295,
           snip snip
           :a3476,
           :a3477
          )
   )

Версия Oracle 10.2.0.2

Answer 1

В Oracle 8 и более поздних версиях вы можете создавать профили использования , которые контролируют и ограничивают ресурсы, которые может использовать любой сеанс. Вы создаете профиль и связываете его с пользователем илироль и база данных обеспечат более справедливое распределение таких вещей, как логический / физический ввод-вывод, ЦП и другие ограниченные ресурсы.

Интересные биты профиля включают в себя:

[CPU_PER_SESSION           n|UNLIMITED|DEFAULT]     
[CPU_PER_CALL              n|UNLIMITED|DEFAULT]            
[CONNECT_TIME              n|UNLIMITED|DEFAULT]
[IDLE_TIME                 n|UNLIMITED|DEFAULT]
[LOGICAL_READS_PER_SESSION n|UNLIMITED|DEFAULT]  
[LOGICAL_READS_PER_CALL    n|UNLIMITED|DEFAULT]
[COMPOSITE_LIMIT           n|UNLIMITED|DEFAULT]
[PRIVATE_SGA               n [K|M]|UNLIMITED|DEFAULT]

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

Answer 2

Как выглядит запрос?

Я предполагаю, что это запрос "в списке переменных", например , где id in (: 1,: 2,: 3, .....) query?

Разработчики этого приложения должны были присоединиться к коллекции памяти:

      select  /*+ cardinality(tab 10) */ *  
      from employees, table(:1) tab 
      where employees.id = tab.column_value";

Подробнее здесь: http://forums.oracle.com/forums/thread.jspa?messageID=3855830&#3855830

Количество привязок всегда одинаково или всегда различно? Иногда 3500, иногда 3499, иногда 3520 ...?

План выполнения запроса не будет извлечен из кэша, если число привязок отличается.

Answer 3

Поскольку у вас есть 3500 переменных связывания, это звучит как массивный запрос. Я бы предположил, что сложность запроса (объединения таблиц / представлений, подзапросов и т. Д.) Была бы гораздо более сложной задачей, чем наличие этих переменных связывания. Индексы должны быть проверены для каждого соединения (если есть индексы). Когда запрос отправляется в первый раз, должен быть составлен план выполнения, и, похоже, Oracle его душит.

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