2013-04-08 6 views
0

Я хотел бы знать компромисс в настройке параметра cursor_sharing в Oracle как «FORCE». Поскольку это будет пытаться мягко разобрать любой оператор SQL, и, конечно же, производительность должна быть улучшена. Но значение по умолчанию - «EXACT», поэтому я хотел бы знать, существует ли какая-либо опасность при настройке в качестве FORCE или SIMILAR.cursor_sharing параметр в Oracle

ответ

1

Если вы действительно не знаете, что делаете, я бы рекомендовал не изменять эту настройку.

Обычно, если у вас есть большое количество жестких разборки, это показатель плохой конструкции приложения.

Типичный пример для выбора всех продуктов данной категории (псевдокод):

stmt = 'select * from products where category = ' || my_category 
results = stmt.execute 

Это ущербное по целому ряду причин:

  • это создает другой оператор SQL для каждой категории , поэтому резко увеличилось число жестких разностей
  • он уязвим для инъекций SQL-инъекций
1

Хорошее приложение отлично работает с курсором_sharing = точное. Хорошее приложение может использовать литералы по определенным причинам, например, выбирать заказы с состоянием = новое. Это использование литералов в порядке. Если приложение использует литералы для идентификации порядка по ID, оно будет отличаться, так как будет много разных идентификаторов заказа.

Лучше всего очистить приложение, чтобы правильно использовать литералы или начать использовать подготовленные заявления для обеспечения максимальной производительности.

Если у вас есть приложение, которое использует только литералы, установите cursor_sharing в FORCE. В 11g есть механизмы, такие как обратная связь с кардинальностью, чтобы иметь возможность корректировать план выполнения на основе ожидаемых строк, полученных из запроса, чтобы убедиться, что планы, которые изначально планируются для запроса, корректируются на основе ввода и вывода, для следующего использования.

 Смежные вопросы

  • Нет связанных вопросов^_^