Медленно происходит удаление

ssv1977
Дата: 08.03.2007 15:02:44
Создана пользовательская таблица.
На данный момент содержится не очень много записей - около 400 000.
Удаление оператором
delete from tabl1 where fld1=val1 and fld2=val2
(это около 200 000) занимает 640 секунд!!!!!
были созданы индексы на поля fld1 и fld2 - но скорость удаления не изменилась.
Если сделать truncate таблицы или ее пересоздать, то скорость удаления становится нормальной..
но после двух-трех таких удалений, скорость опять катастрофически ухудшается.

Может кто может подсказать в чем может быть причина?
dmidek
Дата: 08.03.2007 15:16:51
Половина данных ? Это большой процент.
Подумайте над обходным маневром

1. CREATE TABLE tmp NOLOGGING AS SELECT * FROM tab1
    WHERE fld1 != val1 OR fld2 != val2 (возможно уточнить с учетом NULL- значений)

2. DROP TABLE tab1

3. RENAME tmp to tab1 (возможно понадобятся гранты)
Гхость
Дата: 08.03.2007 15:34:14
dmidek
Половина данных ? Это большой процент.
Подумайте над обходным маневром

1. CREATE TABLE tmp NOLOGGING AS SELECT * FROM tab1
    WHERE fld1 != val1 OR fld2 != val2 (возможно уточнить с учетом NULL- значений)

2. DROP TABLE tab1

3. RENAME tmp to tab1 (возможно понадобятся гранты)


И получаем радость перекомпиляции инвалидированных объектов.
M_IV
Дата: 08.03.2007 15:37:31
ssv1977
Может кто может подсказать в чем может быть причина?
- ? версия DB, ? параметры TS
- бубен подсказывает, что в раздувании таблицы из-за частых удалений
- посмотрите в сторону совета от dmidek
M_IV
Дата: 08.03.2007 15:39:18
Гхость
И получаем радость перекомпиляции инвалидированных объектов.
ну-ну, без паники, автор в курсе ...
ssv1977
...Если сделать truncate таблицы или ее пересоздать...
contr
Дата: 08.03.2007 17:12:29
dmidek
Половина данных ? Это большой процент.
Подумайте над обходным маневром


Я бы скорее предложил что-то в духе

1. CREATE TABLE tmp NOLOGGING AS SELECT * FROM tab1
    WHERE NOT (fld1 = val1 and fld2 = val2) -- с учетом NULL-значений, разумеется

2. TRUNCATE TABLE tab1

3. INSERT /*+ APPEND*/ select * from tmp

4. DROP table tmp

или, если позволяет жизненный цикл данных, попробовал бы секционировать "бегущим окном" или hash с ротацией секций.
SERG1257
Дата: 08.03.2007 17:52:40
Несколько прописных истин.
(in vino veritas судя по дате :-)))
1 Чтобы ускорить удаление индексы надо не создавать, а удалять.
2 Если запрос охватывает такой процент данных - индекс ненужен (в общем случае)
3 Для такого типа запроса fld1=val1 and fld2=val2 лучше не ДВА индекса, а один (а лучше вообще ниодного см п 1 и п2, еще имеются битмап индексы, но автору еще рано с ними играться)
4 Ну и про удаление contr меня опередил.
ssv1977
Дата: 08.03.2007 20:04:09
Спасибо, за советы!
Предложение с пересозданием таблицы действительно не подходит, из за сложного разграничения доступа и появления большого кол-ва инвалидных объектов.
Попробую вариант предложенный contr.
Но все таки не могу понять почему такие проблемы происходят.
Так как такая же ерунда возникает на таблицах,
которые содержат временные данные....по 200-5000
записей.
Как то это не правильно.
Про индексы согласен....но просто уже из крайности в крайность бросался.
contr
Дата: 08.03.2007 20:33:35
ssv1977
Но все таки не могу понять почему такие проблемы происходят.

Так и мы не можем - Вы же ни планов, ни статистики выполения не привели... Гадаем-с.
ssv1977
Так как такая же ерунда возникает на таблицах,
которые содержат временные данные....по 200-5000
записей.
Как то это не правильно.

Неправильно. Надо внимательно смотреть на техпроцесс - что куда когда и как пишете, как, что и зачем удаляете.
ssv1977
Дата: 08.03.2007 20:59:02
Сделаем-с план и статистику! -)