3

バッチジョブとして複数のテーブルから数百万のオーダーの行を削除する必要があります（すべての行を削除するのではなく、インデックス付きの列に格納されているタイムスタンプに基づいて削除することに注意してください）。明らかに、通常のDELETEは永久にかかります（ロギング、参照制約チェックなどのため）。LUWの世界では、ALTER TABLEが最初にログに記録されていないことは知っていますが、DB2 v8 z/OSに相当するSQLステートメントが見つからないようです。誰かがこれを本当に速くする方法について何かアイデアがありますか？また、行を削除するときに参照チェックを回避する方法についてのアイデアはありますか？私にお知らせください。

4

3 に答える 3

1

過去に、データをエクスポートし、スタイルの置換コマンドで再ロードすることで、この種の問題を解決しました。例えば：

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;

これがあなたにとってより速いかどうかはわかりません（おそらく、保持している以上に削除しているかどうかによって異なります）。

于 2010-04-15T05:36:32.070 に答える
0

  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

于 2010-04-05T19:49:02.173 に答える
0

ページ レベルではなくテーブルスペース レベルでロックが発生するように、テーブルスペースを変更しました。DB2 が DELETE を実行するために必要なロックは 1 つだけであることを変更すると、ロックに関する問題は発生しませんでした。ロギングに関しては、お客様に必要なロギングの量を認識していただくようお願いしました (ロギングの問題を回避する解決策がないように思われたため)。制約に関しては、削除後に削除して再作成しました。

ご協力ありがとうございます。

于 2010-04-15T15:51:44.623 に答える