DB2DBA: ChatGPTにDB管理者をやらせてみた

概要

目的に応じたサンプルSQL・コマンドの例示のレベルであれば当たり前にできそうなので、より抽象度の高い問題として、各種DB障害に対する解決策を提示させてみます。

GPT-4を利用しており、シンプルに一問一答の形で検証しています。

ChatGPTへの質問と回答

ケース1. アクティブログ・フルへの対処

質問

Db2のテーブルを更新するSQLがSQL0964Cのメッセージと共に異常終了しました。異常終了したSQLは以下のようなものです。

DELETE FROM TABLE01 WHERE CREATED_TIMESTAMP < ?

この問題に対するワークアラウンドと、恒久的な対応を検討してください。

回答

SQL0964Cエラーは、トランザクションログがいっぱいになった場合に発生します。この問題に対処するために、次のワークアラウンドと恒久的な対応策を提案します。

ワークアラウンド:

1. トランザクションログを確認し、不要なトランザクションが終了していない場合は終了させます。

2. DELETE文の範囲を狭めて、より少ない行を一度に削除します。これにより、トランザクションログに記録されるデータ量が削減されます。

   例:

DELETE FROM TABLE01 WHERE CREATED_TIMESTAMP < ? FETCH FIRST 1000 ROWS ONLY

1. 上記の範囲を狭めたDELETE文を繰り返し実行し、全ての対象データが削除されるまで続けます。

恒久的な対応:

1. トランザクションログのサイズを増やすことを検討してください。これにより、より多くのデータがトランザクションログに格納できます。
2. テーブルのパーティション化を検討してください。これにより、削除操作が特定のパーティションに限定され、トランザクションログへの負荷が軽減されます。
3. データのアーカイブ戦略を検討してください。定期的に古いデータをアーカイブし、本番環境から削除することで、トランザクションログの負荷を軽減できます。

これらのワークアラウンドと恒久的な対応策を検討し、適切なものを適用することで、SQL0964Cエラーを回避できます。

感想

手順の番号として同じ数字が繰り返されていますが、ChatGPTからの出力のままです。

何がワークアラウンドで何が恒久的な対応かはケースバイケースの部分もありますが、概ね妥当な回答が返ってきました。ただし、テーブルのパーティション化は効果がないはずです。ワークアラウンド1つ目は方向性としては合っていますが、もっと具体的でDb2に適した回答が欲しいですね。

最早当然ですが、Db2特有のFETCH FIRST n ROWS ONLYの構文には対応できています。

ケース2. データベースの復旧

質問

あなたはECサイトのデータベース管理者です。ある日、リリースしたバッチプログラムのバグにより、商品マスタテーブルの一部のレコードが誤って削除されてしまいました。

サービスのダウンタイムを伴う対応はビジネスサイドから許可されていません。しかし、幸いにも削除されたレコードは少数であり、そのIDは特定できています。また、データベースは前日の夜間にバックアップが取得されています。データベースにはDb2が利用されています。

以上の状況で、削除されたレコードを復元するために最適と思われる手順を検討してください。

回答

削除されたレコードを復元するために、以下の手順を検討してみました。この手順は、サービスのダウンタイムを最小限に抑えつつ、削除されたレコードを復元することができると考えられます。

1. 前日の夜間バックアップから、バックアップされたデータベースを別の環境にリストアします。これにより、復元作業が本番環境に影響を与えることなく行えます。

2. リストアした環境のデータベースから、削除されたレコードのIDに該当するレコードを抽出します。これには、以下のようなSQLクエリを使用できます。

SELECT * FROM 商品マスタテーブル WHERE 商品ID IN (削除された商品ID1, 削除された商品ID2, ...);

1. 抽出したレコードをCSVファイルやSQLスクリプトなどの形式でエクスポートします。
2. エクスポートしたデータを本番環境のデータベースにインポートします。Db2では、IMPORTコマンドやLOADコマンドを使用してデータをインポートできます。以下は、IMPORTコマンドを使用した例です。

IMPORT FROM '/path/to/exported_data.csv' OF DEL INSERT INTO 商品マスタテーブル;

もしくは、LOADコマンドを使用した例です。

LOAD FROM '/path/to/exported_data.csv' OF DEL INSERT INTO 商品マスタテーブル;

1. インポートが完了したら、本番環境のデータベースで削除されたレコードが復元されていることを確認します。
2. 問題が解決したら、リストアした環境は削除しておきましょう。

この手順により、サービスのダウンタイムを伴わずに、削除されたレコードを復元することができると考えられます。ただし、手順を実行する前に、現在のデータベースとバックアップの状況を確認し、適切な対応を検討してください。

感想

RESTOREコマンドやEXPORTコマンドの例示がなかったり、サービスを停止させてしまうLOADコマンドが候補に入っているものの、こちらも概ね状況を踏まえた手順が返ってきました。結果の確認やリストア環境削除についてもケアしてくれているのは素晴らしいですね。

まとめ

回答を全面的に信頼することはできないものの、状況に応じた障害対応手順を返してくれることが確認出来ました。誤りを指摘して訂正させれば、典型的な障害パターンにはすぐにでも活用できそうです。