Большая разница в производительности между двумя экземплярами базы данных Oracle

Я работаю с двумя экземплярами базы данных Oracle, назову их one и two. two работает на лучшем аппаратном обеспечении (жесткий диск, память, ЦП), чем one, а two на одну младшую версию отстает от one с точки зрения версии Oracle (обе версии 11g). Оба имеют одну и ту же таблицу table_name с точно такими же определенными индексами. Я загружаю 500 000 одинаковых строк в table_name на обоих экземплярах. Затем я запускаю в обоих экземплярах:

delete from table_name;

Выполнение этой команды занимает 30 секунд one и 40 минут two. Выполнение операций INSERT и UPDATE для двух таблиц имеет аналогичные различия в производительности. Есть ли у кого-нибудь предложения о том, что может оказать такое резкое влияние на производительность между двумя базами данных?


database oracle oracle11g
person jrdioko    schedule 19.04.2010    source источник
comment
Будущим читателям кажется, что проблема связана с журналом аудита Oracle. Что-то в процессе регистрации и дисках, которые он использовал, были неправильно настроены в одном из экземпляров.   -  person jrdioko    schedule 28.04.2010

Ответы (4)


arrow_upward
2
arrow_downward

Если вы можете отслеживать столбцы wait_class и event в v$session для сеанса удаления, вы получите представление о причине задержки. Обычно я ожидаю, что полная таблица DELETE будет привязана к диску (ввод-вывод индикации класса ожидания или, возможно, конфигурация). Он должен читать данные из таблицы (чтобы он знал, что удалять), обновлять блоки данных и индексные блоки, чтобы удалить записи, которые генерируют много записей для табличного пространства UNDO и журнала повторов.

В производственной среде базовые файлы могут быть распределены по нескольким дискам (даже SSD). В средах разработки/тестирования все они могут застрять на одном устройстве, и на диске может происходить много движений головы, что замедляет работу. Я мог видеть, что скачок SQL может быть в десять раз. Ваш хуже этого.

Если есть одновременная активность в таблице [wait_class of 'Concurrency'] (например, вставка других сеансов), вы можете столкнуться с конкуренцией за блокировку или оба сеанса пытаются забить индекс.

person Gary Myers    schedule 20.04.2010

arrow_upward
3
arrow_downward

Я бы сначала сравнил конфигурации экземпляров — ВЫБЕРИТЕ ИМЯ, ЗНАЧЕНИЕ из V$PARAMETER ORDER BY NAME и поместил результаты в текстовые файлы для обоих экземпляров и использовал какой-нибудь инструмент сравнения файлов, чтобы выделить различия. Все, кроме различий, связанных с именем базы данных и расположением файлов, должно быть исследовано. Крайним случаем может быть отсутствие ведения журнала архива в одной базе данных и 5 назначений архива, определенных в другой.

Если у вас нет доступа к файловой системе на узле базы данных, найдите того, у кого он есть, и попросите его получить файлы трассировки и результаты tkprof при запуске сеанса, ALTER SESSION SET sql_trace=true, а затем выполните удаление. Это выявит любой рекурсивный SQL из-за триггеров в таблице (которые могут вам не принадлежать), аудита и т. д.

person dpbradley    schedule 19.04.2010

arrow_upward
1
arrow_downward

Что-то явно не так в экземпляре два. Я предлагаю вам взглянуть на эти вопросы SO и их ответы:

Особенно:

  • Есть ли у вас неиндексированные ссылки на внешние ключи (причина № 1 удаления занимает много времени — посмотрите на это скрипт от AskTom),
  • У вас есть какие-либо ON DELETE TRIGGER на столе?
  • Есть ли у вас какие-либо действия на экземпляре два (если эта таблица постоянно обновляется, вы можете быть заблокированы другими сеансами)
person Vincent Malgrat    schedule 20.04.2010

arrow_upward
1
arrow_downward

обратите внимание: я не dba...

У меня на окне в кабинете написано следующее:

В экстренных случаях попросите дежурного администратора базы данных:

  1. Проверить план
  2. Статистика бега
  3. Очистить общий буферный пул

Номера 2 и/или 3 обычно исправляют запросы, которые работают в одной базе данных, но не работают в другой, или которые работали вчера, но не сегодня....

person user320820    schedule 19.04.2010