LinuxラップトップにDb2データベースがあります。データベースの負荷が高くありません。私は時々、開発目的でそれにアクセスします。
列を削除しました:
db2 "alter table SCHEMA.TABLE drop column COLUMN"
次に、REORGCHK
を実行します。
db2 "reorgchk update statistics on table all"
次のメッセージが表示されました:
Doing RUNSTATS ....
SQL2310N The utility could not generate statistics. Error "-668" was
returned.
ただし、REORGCHK
に統計の更新を要求しない場合、コマンドは成功します。
db2 "reorgchk current statistics on table all"
さらなる調査により、変更されたテーブルでRUNSTATS
が示されています。
db2 "runstats on table SCHEMA.TABLE for indexes all"
上記と同じエラーで失敗します(SQL2310N、-668など)。
同じパラメーター(LOGFILSIZ
、LOGPRIMARY
、LOGSECOND
、およびSTAT_HEAP_SZ
)の値を増加させようとしましたが、それは役に立ちませんでした。
エラーの理由は何ですか?デバッグする方法は?どうすれば修正できますか?
REORGCHK UPDATE STATISTICSがテーブルに対する破壊的な操作(列の削除)の後に進む方法であるかどうかはわかりません。 dropステートメントが一部のカタログテーブルにZロックを設定しているため、STATISTICSが更新されないのではないかと思います。ドロップのためにテーブルを再編成する必要があるかどうかにのみ関心がある場合は、次のことができます。
SELECT NUM_REORG_REC_ALTERS, REORG_PENDING
FROM SYSIBMADM.ADMINTABINFO
WHERE (TABSCHEMA, TABNAME) = (..., ...)
何らかの理由で、それは本当に遅いです(存在しないテーブルを要求しないでください)が、それはreorgchkより速いです。
テーブルが本当に大きい場合を除いて、念のため、通常は移行スクリプトにREORGコマンドを追加します。
REORG TABLE ...;
REORGは進行中のトランザクションをコミットするため、REORGの前に現在のuowを終了し、それらを別のトランザクションに入れる必要があることに注意してください。
補足として、REORGCHK
は、ALTER
後にテーブルを再編成する必要があるかどうかを判断する正しい方法ではありません。オブジェクト統計を分析して、テーブルまたはそのインデックスを何らかの方法で最適化できるかどうかを判断することを目的としています。その後、そのインデックスをスキャンして統計を更新しようとすると、必ず失敗します。
REORGCHK
はいくつかのメトリックを計算します 、たとえば、テーブル内の未使用スペースの量、オーバーフロー行の数、インデックスの同様の効率メトリック、テーブルのクラスター率など。を使用して、再編成によってクエリのパフォーマンスが向上するかどうかを判断できます。それがしていないことは、テーブルの「reorg pending」ステータスを確認することです。