у нас есть база данных размером 16 ГБ. Мы ежедневно выполняем резервное копирование с использованием EXPDP, но несколько дней назад этот EXPDP занимал слишком много времени (более 6 часов). мой вопрос
1) влияют ли БЛОКИРОВКИ ТАБЛИЦ на производительность EXPDP (я проверил блокировку таблиц и обнаружил, что несколько таблиц были заблокированы (мы обновляем таблицы, используя некоторые процедуры, которые настроены на запуск несколько раз в день)..
2) не приведет ли проблема, связанная с жестким диском, к снижению производительности EXPDP??
По вашему предложению я включил запрос (пока работает expdp)
select elapsed_time/1000000 seconds,sql_text,SHARABLE_MEM,PERSISTENT_MEM,RUNTIME_MEM,USERS_EXECUTING,DISK_READS,BUFFER_GETS,USER_IO_WAIT_TIME from gv$sql where users_executing > 0 order by elapsed_time desc;
Для этого запроса я получаю более 20 записей, и я поделюсь некоторыми записями. введите описание изображения здесь
@JonHeller: Спасибо за комментарии. В соответствии с вашим предложением я обновил вопрос. Проверьте файл изображения и, пожалуйста, дайте мне знать, если обнаружите какую-либо проблему.
Я не вижу ни одного запроса к словарю данных в первой семерке. (Хотя, кстати говоря, кажется, что на создание последовательности LOG_SEQ
уходит очень много времени. Я думаю, что последовательность была установлена на NOCACHE
. Выполнить select cache_size from all_sequences where sequence_name = 'LOG_SEQ';
Если размер кеша установлен равным 0, то вы можете значительно повысить производительность, запустив alter sequence log_seq cache 20;
Кроме того, если он используется в PL/SQL, вы можете напрямую назначать последовательность вместо выбора из двойного.)
Сам экспорт находится под номером 7, поэтому вам может потребоваться расширить список, чтобы найти дочерние запросы. Вы можете исключить запросы, связанные с приложением.
@JonHeller: Вы правы, кеш установлен на 0 для этой последовательности. Но как можно увеличить производительность, установив cache_size. Я новичок в администрировании производительности Oracle. Не могли бы вы объяснить это подробно, это было бы очень заметно. пришлось поднять базу данных на новой машине (у нас была резервная копия дампа expdp), для обновления базы данных использовали impdp. Первые несколько дней все шло нормально, но внезапно вся система стала работать слишком медленно, так как при расследовании мы обнаружили, что жесткий диск находится в состоянии RAID REBUILD, но после завершения RAID REBUILD производительность не изменилась
Oracle может обрабатывать индексы намного эффективнее, если он может заранее генерировать значения и кэшировать их. Вот почему значение по умолчанию равно 20, а не 0. Изменение этого значения может привести к тому, что этот оператор почти исчезнет из Top SQL. Но это утверждение может и не иметь прямого отношения к проблеме. Вам все еще нужно найти медленные запросы, связанные с экспортом. Возможно, вы захотите изучить такие инструменты, как AWR, чтобы попытаться найти медленные операторы и медленные события ожидания. Если есть проблемы с жестким диском, это может отображаться в этих отчетах. Что-то не так, 16Гб должны экспортироваться за 6 минут, а не за 6 часов.
@JonHeller: Спасибо за ваши ценные ответы. Как вы и предложили, я получу отчет AWR.
Я предполагаю, что это проблема с запросом словаря данных - одним из запросов, который генерирует метаданные, а не данные. Даже смехотворно медленный жесткий диск может справиться с записью 16 ГБ в час. Ищите медленные операторы SQL, которые выполняются одновременно с экспортом. Есть много способов сделать это, я бы начал с повторного запуска экспорта и время от времени запуская такой запрос, чтобы найти медленные операторы:
select elapsed_time/1000000 seconds, gv$sql.* from gv$sql where users_executing > 0 order by elapsed_time desc;
. Если вы найдете что-то, измените вопрос, чтобы включить запрос.