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

Question

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

delete from table_name; 

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

Answer 1

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

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

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

Answer 2

Я бы сначала сравнил конфигурацию экземпляра - SELECT NAME, VALUE из V $ PARAMETER ORDER BY NAME и запустил результаты в текстовые файлы для обоих экземпляров и использовал инструмент сравнения файлов, чтобы выделить различия. Необходимо изучить все, кроме различий, связанных с именем базы данных и местоположениями файлов. Крайним случаем может быть отсутствие архивирования в одной базе данных и 5 целевых адресов архива, определенных на другом.

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

Answer 3

обратите внимание: я не являюсь дБА ...

Я написал следующее на моем окно офиса:

В случае возникновения чрезвычайной ситуации спросить по вызову АБД:

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

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

Answer 4

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

• Oracle: delete suddenly taking a long time
• oracle delete query taking too much time

В частности:

• У вас есть проиндексированных внешних ключей ссылки (причина # 1 из удалений, занимающих время в режиме ожидания - посмотрите на это script from AskTom),
• У вас есть ny ON УДАЛИТЬ ТРИГГЕР на столе?
• Есть ли у вас какая-либо деятельность по примеру два (если эта таблица постоянно обновляются, вы можете быть заблокированы другими сессиями)