Медленное удаление из таблицы с полями CLOB в Oracle 10g

Question

Я сталкиваюсь с проблемой, когда Oracle работает очень медленно, когда я пытаюсь удалить строки из таблицы, содержащей два поля CLOB. Таблица содержит миллионы строк, без ограничений, и удаления основаны на первичном ключе. Я перестроил индексы и пересчитал статистику, но безрезультатно.

Что я могу сделать, чтобы улучшить производительность удалений из этой таблицы?

Answer 1

Трассировка, с включенным ожиданием

http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_monitor.htm#i1003679

Найдите файл трассировки в каталоге UDUMP. TKPROF это. Посмотрите на конец, и он расскажет вам, на что база данных потратила свое время во время этого SQL. Следующая ссылка - хороший обзор того, как анализировать проблему производительности.

http://www.method-r.com/downloads/doc_download/10-for-developers-making-friends-with-the-oracle-database-cary-millsap

Answer 2

Ваше UNDO табличное пространство в этом случае кажется узким местом.

Проверьте, сколько времени потребуется, чтобы сделать ROLLBACK после удаления данных. Если это занимает время, сопоставимое со временем самого запроса (в пределах 50%), то это, безусловно, так.

Когда вы выполняете запрос DML, ваши данные (как исходные, так и измененные) записываются в журналы повторов, а затем применяются к файлам данных и к табличному пространству UNDO.

Удаление миллионов строк CLOB требует копирования нескольких сотен мегабайт, если не гигабайт, в табличное пространство UNDO, которое занимает десятки секунд.

Что вы можете сделать с этим?

1. Создание более быстрого UNDO: поместите его на отдельный диск, сделайте его менее разреженным (создайте файл данных большего размера).
2. Используйте ROLLBACK SEGMENTS вместо управляемого UNDO, присвойте ROLLBACK SEGMENT для этого самого запроса и введите SET TRANSACTION USE ROLLBACK SEGMENT перед выполнением запроса.

Если это не так, то я. е. ROLLBACK выполняет намного быстрее, чем сам запрос, затем попытайтесь поиграть с вашими REDO параметрами:

1. Увеличьте размер буфера REDO с помощью параметра LOG_BUFFER.
2. Увеличьте размер ваших лог-файлов.
3. Создайте свои файлы журналов на отдельных дисках, чтобы чтение из первого файла данных не мешало записи во второй и т. Д.

Обратите внимание, что UNDO операции также генерируют REDO, поэтому все равно полезно делать все это.

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

Answer 3

Есть ли дочерние таблицы, которые ссылаются на эту таблицу, из которой удаляются? (Вы можете сделать выбор из user_constraints, где r_constraint_name = имя первичного ключа в таблице, из которой вы удаляете).

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

Следуйте советам Гэри, проведите трассировку и опубликуйте результаты TKPROF, здесь кто-то сможет помочь в дальнейшем.

Answer 4

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

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

Если таблица является производной таблицей, то есть ее можно восстановить из других таблиц, вы можете посмотреть опцию NOLOGGING в таблице. Вы можете перестроить таблицу из исходной таблицы с минимальным ведением журнала.

Я надеюсь, что эта запись поможет некоторым, однако некоторые подробности могут помочь диагностировать проблему.

Answer 5

Удаленные объекты CLOB не попадают в UNDOTBS, поскольку они имеют версии и сохраняются в сегменте LOB. Я думаю, что это приведет к некоторым изменениям LOBINDEX в отмене.

Если вы ранее обнуляли или очищали большие объекты, измеряли ли вы это время коммитом, отдельным от DELETE? Если вы выполняете тысячи удалений, используете ли вы пакетные коммиты? Экземпляр простаивает? Затем в отчете AWR должно быть указано, что происходит.