パーティション表をアーカイブする場合は注意してください。 好ましくない状況に陥る場合があります。 復元操作時に生じる可能性がある他の問題については、データ復元を実行する前の考慮事項を参照してください。
- 仕様書を参照すること – 仕様に合わない使い方は、次の問題が生じる原因となります。
- バックアップ処理でPARTITIONS WHEREが正しく指定されていない場合は、アーカイブが不完全になったり、復元操作を正しく実行できなかったりすることがあります。
- 復元処理でPARTITIONS WHEREまたはALL PARTITIONSが正しく指定されていない場合は、テーブルのデータが失われることがあります。また、復元するアーカイブに部分的、不完全、または古くなったバージョンの既存パーティションが含まれていると、古いデータがテーブルに復元されることもあります。
- 更新はアクティブなパーティションに限定すること – どのパーティションが最後のバックアップ以降に変更されたのかは確認できません。 変更されたパーティションが再びアーカイブされなければ、復元時に変更内容が失われます。
例えば、あるテーブルに関して次のようなシナリオが存在する場合を考えてみます。
- このテーブルの中からは、アクティブな(最新の)パーティションのみをバックアップすることになっている。
- 適切でない更新を修正するため、非アクティブ パーティションに変更を加える。
変更点をアーカイブする唯一の方法は、変更されたパーティションのアーカイブ処理を別途実行することです。
このような状況に対処するためには、更新をアクティブなパーティションのみに限定する(更新する行/パーティションを制御するビューを使用する)か、または変更されたすべてのパーティションを再度アーカイブします。
- 関数や変数の値は変更しないこと - PARTITIONS WHERE条件でビルトインSQL関数または変数を使用している場合、その関数または変数の値がジョブの実行中に変化すると、その単一のアーカイブ内のいくつかのオブジェクトについて、別のパーティション セットがアーカイブ(または復元)されることがあります。
例えば、アーカイブ ジョブがCURRENT_DATEビルトイン関数を使用してアクティブなパーティションを確認している場合に、バックアップが真夜中を過ぎてから実行されるとすると、日付が変更されたことで別のパーティションが選択されることになります。 その場合、真夜中を過ぎてからアーカイブされるオブジェクトは、(おそらく内容が空の)新しいパーティションをアーカイブすることになります。
このような状況には、次のいずれかで対処します。
- PARTITIONS WHERE条件では、変化する関数や変数を使用しないようにする。
- バックアップは、値が変化しないときに実行する。
- パーティションを選択するPARTITIONS WHERE式を、値が変化することを考慮したものに変更する。 例えば、範囲を‘BETWEEN CURRENT_DATE - n AND CURRENT_DATE’のように定義すると、日付が変わってもアクティブなパーティションをアーカイブできます。
- PARTITIONS WHEREまたはALL PARTITIONSを必ず指定すること – RESTOREまたはCOPY操作でPARTITIONS WHEREまたはALL PARTITIONSが指定されていない場合、デフォルトのアクションでは、アーカイブされたテーブル定義とデータで、テーブル全体が上書きされます。基本的に、これはテーブル全体の復元と同じです。
例えば、1つのパーティションのバックアップからの復元処理時にPARTITIONS WHEREが省略されていると、データがテーブルから除外され、アーカイブに保存されている1つのパーティションが復元されます。
この問題を解決するためには、必ずPARTITIONS WHEREまたはALL PARTITIONSを指定してパーティションを既存のテーブルに復元するようにします。 そうしないと、既存のテーブルが上書きされます。
- 削除されるパーティションを把握しておくこと – RESTOREまたはCOPY操作では、PARTITIONS WHERE条件に一致するすべてのパーティションが削除されます。この処理は、パーティションがアーカイブに保存されていなくても行なわれます。
例えば、2007年4月のデータを含み2007年3月と4月の両方に一致するPARTITIONS WHERE条件を持つアーカイブを復元する場合は、2007年3月と4月のデータは削除され、2007年4月のデータのみが復元されます。
このため、PARTITONS WHEREの使用時には注意が必要です。 影響を受けるパーティションがよくわからない場合は、選択したパーティション バックアップをステージング テーブルにCOPYし、INSERT ... SELECTおよび/またはDELETEを使用して目的のパーティションをターゲット テーブルにコピーします。
- 前回のパーティション スキームからの復元は避けること – テーブルのパーティション式を変更すると、既存パーティションの範囲が変化する可能性があります。 このようなパーティションが復元される場合、選択パーティションに対するデータの一部がアーカイブに含まれていないと、想定するより多くのデータが削除されたり、想定するより少ないデータが復元されたりすることがあります。
例えば、月でパーティション化され2004年3月のアーカイブ データを持つテーブルに対してアーカイブ処理し、そのテーブルが週で再度パーティション化された場合、3月のバックアップのPPI復元(ALL PARTITIONSを使用)を実行すると、1日でも3月に含まれているすべての週についてデータが上書きされます。 その結果、2月の終わりと4月の初めの何日かが削除され復元されないことも起こりえます。
したがって、更新するテーブルには、以前のパーティション スキームのパーティション バックアップを復元しないようにします。 または、3月と2月/4月の両方に含まれる週についてLOG WHEREを使用し、行を手動でテーブルにコピーするようにします。
- 各アーカイブ内のパーティションを追跡すること – あるバックアップ ジョブでどのパーティションがアーカイブされるかを確認する場合や特定のパーティションの最新バージョンがどのバックアップ ジョブに含まれているかを確認する場合は、手動での処理が必要です。ANALYZEを実行すると、アーカイブされるパーティションを示す、Teradataで生成された範囲条件が表示されます。(これは、部分パーティションのみを表わすユーザー入力の条件とは異なります。)このとき、パーティションに対して誤ったアーカイブが復元されたり、パーティション レベルのアーカイブが順不同で復元されアーカイブにパーティションの重複があったりすると、整合性のないデータや古いデータが表に復元されることがあります。
例えば、更新データは次のような場合に失われます。 2007年3月のパーティションの最終バックアップが2007年4月1日に実行されるものとします。 4月5日に、3月16日の行の誤りが発見されたため、その行が更新され、3月のパーティションについて新しいバックアップ処理が実行されます。 例えば、1か月後に誤ってテーブルが削除されたときに、4月5日ではなく4月1日のバックアップを復元すると、更新されたデータは失われます。
各アーカイブ内のパーティションの内容を確認するためには、アーカイブした各テーブルのパーティションの内容を常に把握しておくか、テープに関連する出力リストを保持しておくか、またはアーカイブに対してANALYZEジョブを実行します。