Индекс спящего режима медленный - PullRequest
3 голосов
/ 02 декабря 2010

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

Мы проверили отсутствие индексов внешних ключей и нашлинемного.Добавление отсутствующих индексов на самом деле имело противоположный эффект: оно еще больше замедляло запрос.Одна важная информация заключается в том, что у нашего клиента есть одна установка Oracle, в которой наша схема реплицирована на него 21 раз.В каждой схеме просто 1000 таблиц.Мы слишком много просим у Oracle с таким большим количеством таблиц (и, конечно, индексов)?Я не знаю, какое у них оборудование, но у меня вопрос, является ли это разумным подходом или было бы лучше разделить пользователей на разные идентификаторы безопасности?

Ниже приведен запрос, который выполняется Hibernate.,Клиент говорит нам, что этот запрос потребляет около 45% процессора, когда он выполняется (хотя я не знаю, как долго).

Любые предложения приветствуются, Стив

SELECT NULL AS table_cat,
       owner AS table_schem,
       table_name,
       0 AS non_unique,
       NULL AS index_qualifier,
       NULL AS index_name,
       0 AS TYPE,
       0 AS ordinal_position,
       NULL AS column_name,
       NULL AS asc_or_desc,
       num_rows AS CARDINALITY,
       blocks AS pages,
       NULL AS filter_condition
  FROM all_tables
 WHERE table_name = 'BOOKING'
       AND owner = 'FORWARD_TN'
UNION
SELECT NULL AS table_cat,
       i.owner AS table_schem,
       i.table_name,
       DECODE (i.uniqueness, 'UNIQUE', 0, 1),
       NULL AS index_qualifier,
       i.index_name,
       1 AS TYPE,
       c.column_position AS ordinal_position,
       c.column_name,
       NULL AS asc_or_desc,
       i.distinct_keys AS CARDINALITY,
       i.leaf_blocks AS pages,
       NULL AS filter_condition
  FROM all_indexes i,
       all_ind_columns c
 WHERE     i.table_name = 'BOOKING'
       AND i.owner = 'FORWARD_TN'
       AND i.index_name = c.index_name
       AND i.table_owner = c.table_owner
       AND i.table_name = c.table_name
       AND i.owner = c.index_owner
ORDER BY non_unique,
         TYPE,
         index_name,
         ordinal_position

Ответы [ 3 ]

3 голосов
/ 03 декабря 2010

Вы не столкнетесь с проблемой емкости 1000 таблиц.Это все еще относительно мало в мире Oracle.Просто сделайте быструю проверку нашего E-Business Suite, и в нем 23 000 таблиц.Запрос, использующий тонну ЦП, почти всегда является проблемой плана выполнения.Что посмотреть на

Вы собрали статистику оптимизатора?Без них оптимизатор может принять действительно плохое решение о том, как выполнить запрос.

Следующий шаг - посмотреть сам план выполнения.Если у вас запущен менеджер предприятия, он, вероятно, разместит этот запрос прямо на главной странице для потребления ресурсов.Вы можете просто нажать на него и посмотреть, что он делает.Без этого вам придется использовать sql_trace или объяснить план, чтобы увидеть, что происходит.

1 голос
/ 04 декабря 2010

Вы можете быть легко поражены чрезмерным временем разбора на сервере Oracle, если все ваши операторы используют слегка различающийся литеральный SQL (т.е. без переменных связывания) для каждой из 22 000 таблиц.Если это так, просто переключитесь на связывание переменных, и потребление ЦП должно существенно снизиться.

Может ли ваш клиент сказать, в какой функции Oracle тратится время ЦП?Oracle предлагает необходимую статистику.Поскольку, как сообщается, загрузка ЦП составляет значительную часть потребления всего экземпляра, ваш клиент может запустить отчет statspack (или ASH , если он лицензировал диагностический пакет).Это должно показать, где именно тратится время процессора.

0 голосов
/ 20 декабря 2010

Наш клиент проверил свою конфигурацию Oracle и изменил конфигурацию на следующие значения: optimizer_index_caching = 90 optimizer_index_cost_adj = 15 optimizer_mode = 'CHOOSE'

Они сообщают, что это, похоже, исправило проблему их скорости.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...