最近これに遭遇しました。 DB2 LUW(少なくとも9.5以上)でテーブルを定義する場合、NOT LOGGED INITIALLY
として定義できます。
私が読んだ本の例:
CREATE TABLE products (
productID INT,
product_Name VARCHAR(30)
)
NOT LOGGED INITIALLY;
私が読んだドキュメントでは、INSERT
、UPDATE
、DELETE
、CREATE INDEX
、ALTER TABLE
、またはDROP INDEX
の実行中は、COMMIT
まで、テーブルはログに記録されません。ステートメントが実行されます。 COMMIT
より前のすべてはログに記録されません。 COMMIT
以降はすべてです。
そして、どうやらテーブルをNOT LOGGED INITIALLY
として定義している限り、_COMMIT
が再度発行されるまで、いつでもALTER TABLE <table-name> ACTIVATE NOT LOGGED INITIALLY
を発行してテーブルを非ログ状態に戻すことができます。
彼らは、これがどこに役立つかを私が見ることができる一例を挙げました。私が読んだ本は、あなたが以下を発行することができると述べました
ALTER TABLE <table-name> ACTIVATE NOT LOGGED INITIALLY WITH EMPTY TABLE;
これにより、ログに記録されずに、テーブル内のすべてのデータが削除されます。これは、ロールバックのために削除をログに記録するというパフォーマンスのオーバーヘッドなしにデータをクリアして再テストしたいテスト環境で望ましいと理解できます。
しかし、この場合を超えて、私は困惑しています。テスト環境外のテーブルにログオンしたくない理由はありますか?この種類のテーブルには他にどのような用途がありますか?
古典的な実例は、私が作成しているテーブルが静的外部ソースからのコピーである場合です。初期ロード中にDBに障害が発生した場合、部分的にロードされたテーブルを削除してインポート操作を最初からやり直す方が、トランザクションを完全にログに記録するオーバーヘッドを被るよりも速くなります。
たとえば、トランザクション環境のバックアップファイルから顧客のリストをレポート環境にロードしています。
また manual から:
NOT LOGGED INITIALLYオプションは、代替ソース(別のテーブルまたはファイル)からのデータを使用して大きな結果セットを作成する必要があり、テーブルのリカバリが不要な場合に役立ちます。このオプションを使用すると、データのロギングのオーバーヘッドを節約できます。このオプションを指定すると、次の考慮事項が適用されます。
作業単位がコミットされると、作業単位中にテーブルに加えられたすべての変更がディスクにフラッシュされます。
ロールフォワードユーティリティを実行し、データベース内のテーブルがロードユーティリティによって入力されたか、NOT LOGGED INITIALLYオプションを使用して作成されたことを示すログレコードを検出すると、テーブルは使用不可としてマークされます。後でDROP TABLEログが検出されると、ロールフォワードユーティリティによってテーブルが削除されます。そうしないと、データベースがリカバリーされた後、表にアクセスしようとするとエラーが出されます(SQLSTATE 55019)。許可される唯一の操作は、テーブルを削除することです。
このような表がデータベースまたは表スペースのバックアップの一部としてバックアップされると、表のリカバリーが可能になります。
これは本番環境でも意味があります。
最初にログを記録しないことは、テーブルを作成した直後に大量のデータを入力する必要がある場合に役立ちます。データはすでにどこかにあるので、データの回復について心配する必要はありません。したがって、データ入力のログを記録する必要はありません。ログに記録する必要がない場合は、データの取り込み時間を大幅に短縮できます。
この質問の制作部分はまだ回答されていないので、それが役立つ場所の例を示します。実稼働テーブルをユーザースペースにバックアップしています。このテーブルには大量のデータが含まれており(約850GB圧縮)、通常の方法でバックアップすることはできません。これは、生成されるログファイル(挿入を強制終了する前に18GBを超える)により、いくつかのダウンストリーム関数が失敗するためです。 NOT LOGGED INITIALLYは、これが起こらないようにするための私の唯一のオプションです。