Oracle: разница в планах выполнения между базами данных - PullRequest
Новая
       13

Oracle: разница в планах выполнения между базами данных

2 голосов
/ 21 апреля 2010

Я сравниваю запросы моей базы данных разработки и производства.

Они оба являются Oracle 9i, но почти каждый запрос имеет совершенно другой план выполнения в зависимости от базы данных.

Все таблицы / индексы одинаковы, но в базе данных dev примерно 1/10 строк для каждой таблицы.

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

Я недавно запустил схему dbms_utility.analyze для обеих баз данных в надежде, что CBO что-нибудь выяснит.

Существует ли какая-либо другая базовая конфигурация оракула, которая может быть причиной этого?

Я в основном разработчик, поэтому такой анализ DBA поначалу сбивает с толку ..

1 Ответ

5 голосов
/ 21 апреля 2010

1) Первое, что я хотел бы проверить, это если параметры базы данных эквивалентны для Prod и Dev. Если один из параметров, влияющих на решения оптимизатора затрат, отличается, то все ставки отключены. Вы можете видеть параметр в представлении v $ parameter;

2) Наличие современной статистики объектов - это здорово, но имейте в виду ту большую разницу, на которую вы указали - у Dev 10% строк Prod. Этот счетчик строк учитывает, как CBO решает лучший способ выполнить запрос. Учитывая большую разницу в количестве строк, я не ожидал, что планы будут такими же.

В зависимости от обстоятельств оптимизатор может выбрать полное сканирование таблицы с 20000 строк (Dev), где он может решить, что индекс является более низкой стоимостью для таблицы с 200 000 строк (Prod). (Числа только для демонстрации, CBO использует алгоритмы калькуляции для определения того, что FTS и что для сканирования индекса, а не абсолютные значения).

3) Системная статистика также учитывает планы объяснения. Это набор статистики, который представляет характеристики процессора и дискового ввода-вывода. Если ваше оборудование в обеих системах отличается, я бы ожидал, что ваша статистика системы будет отличаться, и это может повлиять на планы. Хорошая дискуссия от Джонатана Льюиса здесь Вы можете просматривать статистику системы через представление sys.aux_stats $.

Теперь я не уверен, почему разные планы - это плохо для вас ... если статистика актуальна и параметры установлены правильно, вы должны получать приличную производительность от любой системы, независимо от разницы в размерах ...

но есть возможность экспортировать статистику из вашей системы Prod и загрузить ее в вашу систему разработки. Это сделает вашу статистику Prod доступной для вашей базы данных Dev.

Проверьте документацию Oracle для пакета DBMS_STATS, в частности, процедуры EXPORT_SCHEMA_STATS, EXPORT_SYSTEM_STATS, IMPORT_SCHEMA_STATS, IMPORT_SYSTEM_STATS. Имейте в виду, что вам может потребоваться отключить ночные задания статистики 10 вечера на 10g / 11g ... или вы можете исследовать статистику блокировки после импорта, чтобы они не обновлялись ночными заданиями.

...