удаление большого количества строк из таблицы

У нас есть требование удалять строки порядка миллионов из нескольких таблиц в виде пакетного задания (обратите внимание, что мы удаляем не все строки, мы удаляем на основе метки времени, хранящейся в индексированном столбце). Очевидно, что обычное DELETE занимает вечность (из-за ведения журнала, проверки ссылочных ограничений и т. д.). Я знаю, что в мире LUW ИЗМЕНЕНИЕ ТАБЛИЦЫ ИЗНАЧАЛЬНО НЕ ЗАРЕГИСТРИРОВАНО, но я не могу найти эквивалентную инструкцию SQL для DB2 v8 z/OS. У кого-нибудь есть идеи, как это сделать очень быстро? Кроме того, есть идеи, как избежать ссылочных проверок при удалении строк? Пожалуйста, дай мне знать.


sql db2 zos
person Azeem    schedule 05.04.2010    source источник

Ответы (3)


arrow_upward
1
arrow_downward

В прошлом я решал эту проблему, экспортируя данные и повторно загружая их с помощью команды стиля замены. Например:

EXPORT to myfile.ixf OF ixf
SELECT * 
FROM my_table 
WHERE last_modified < CURRENT TIMESTAMP - 30 DAYS;

Затем вы можете ЗАГРУЗИТЬ его обратно, заменив старый материал.

LOAD FROM myfile.ixf OF ixf
REPLACE INTO my_table
NONRECOVERABLE INDEXING MODE INCREMENTAL;

Я не уверен, будет ли это быстрее или нет для вас (вероятно, это зависит от того, удаляете ли вы больше, чем сохраняете).

person Scott Jones    schedule 15.04.2010
comment
Скотт, спасибо за ответ. Да, мы рассмотрели вариант этого (используя REORG DISCARD), но DB2 v8 для z/OS имеет ограничение на SELECT, который вы можете выполнить для таблицы (даже при выполнении LOAD/UNLOAD). Во всяком случае, это оказалось довольно легко решить. Я опубликую это как ответ в ближайшее время. - person Azeem; 15.04.2010

arrow_upward
0
arrow_downward

  1. У внешних ключей уже есть индексы?

  2. Как у вас настроено действие удаления? CASCADE, NULL, NO ACTION

  3. Используйте SET INTEGRITY, чтобы временно отключить ограничения на пакетный процесс. http://www.ibm.com/developerworks/data/library/techarticle/dm-0401melnyk/index.html

http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/admin/r

person jasonk    schedule 05.04.2010
comment
Да, внешние ключи уже имеют индексы. УДАЛИТЬ действие НЕТ ДЕЙСТВИЯ. Я посмотрю на SET INTEGRITY. Более серьезной проблемой здесь является возможность временно не регистрировать операцию DELETE. Возможно ли это сделать в DB2 z/OS v8? Спасибо за вашу помощь! - person Azeem; 06.04.2010
comment
Вы уверены, что именно часть LOG является подробной, а не проверка ссылочной целостности? Можете ли вы опубликовать SQL, используемый для возможных улучшений производительности? - person jasonk; 06.04.2010
comment
Вы уверены, что синтаксис начального пропуска журнала был правильным? 'ALTER TABLE [tablename] ACTIVATE NOT LOGGED INNITIALY' - person jasonk; 06.04.2010
comment
@jasonk, извините, да, я имел в виду АКТИВИРОВАТЬ НЕ ЗАРЕГИСТРИРОВАТЬСЯ ИЗНАЧАЛЬНО. Однако не похоже, что DB2 v8 поддерживает это. - person Azeem; 07.04.2010
comment
в части LOG я обновил исходный пост, включив в него SQL. - person Azeem; 07.04.2010
comment
Вот SQL: УДАЛИТЬ ИЗ table_a TA, ГДЕ НЕ СУЩЕСТВУЕТ (ВЫБЕРИТЕ UID ИЗ table_b TB, где TB.UID = TA.UID) - извините, мои правки не прошли. - person Azeem; 07.04.2010

arrow_upward
0
arrow_downward

Мы изменили табличное пространство, чтобы блокировка происходила на уровне табличного пространства, а не на уровне страницы. Как только мы изменили это, DB2 требовала только одну блокировку для выполнения DELETE, и у нас не было никаких проблем с блокировкой. Что касается ведения журнала, мы просто попросили клиента знать о необходимом объеме ведения журнала (поскольку не было решения, позволяющего обойти проблему ведения журнала). Что касается ограничений, мы просто удалили их и создали заново после удаления.

Спасибо всем за вашу помощь.

person Azeem    schedule 15.04.2010