データ ウェアハウス設計の主な課題として、失敗からいかにすみやかに回復するかが挙げられます。 通常、回復作業には、クライアント システムやサーバー システムの修復、構成パラメータやシステム リソースの変更、割り込まれたジョブの前回のチェックポイントからの再始動、綿密な人手による手間や、段階的な回復手順の記述なしでシステムを正常化することが含まれます。
「失敗ウィンドウ」の間に溜まったトランザクションをできるだけ速やかにターゲット システムに適用できるよう、ジョブはほとんど常時「キャッチ アップ」も実行しなければなりません。
そのため、Teradata PTには、ジョブの失敗後もジョブ スクリプトを変更しなくても、迅速に回復プロセスを実行できる独自の機能がいくつかあります。以下にそれらの機能を示します。
- すべてのジョブ チェックポイントをデフォルトで再始動可能にする。
- Duplicate APPLY機能でターゲット テーブルにトランザクション データをロードするのと並行して、すぐにロードできる形式でそれらのトランザクション データをアーカイブする。これにより、同じデータを異なる場所に保存できます。
- すべてのオペレータを1つのスクリプト言語で定義する。オペレータを共通の方式で定義できるだけでなく、メタデータとオペレータの実質的な再利用可能性を実現できます。
- ジョブ変数ファイルによる無限の変数置換のサポート。「属性」と呼ばれる、変動的で、共通のジョブ パラメータを、値割り当て用の1箇所に分離できます。
- Producerオペレータ(データ抽出用)とConsumerオペレータ(データ ロード用)が1つのジョブ内で完全に分かれているため、「エクスポート/ロード プロトコルの切り替え」プロセスが大幅にシンプルになりました。 したがって、1つのジョブ内のProducerオペレータとConsumerオペレータのどちらを変更してもお互いに影響を受けることがありません。
再始動性の前述の機能を活用するには、ジョブ スクリプトの設計と実装でいくつかのベスト プラクティスを導入する必要があります。 以下に示すベスト プラクティスの目的は、ジョブ スクリプトの使いやすさと管理しやすさ、ジョブ スクリプトの構築の柔軟性、増加の一途をたどるデータ量と実行環境の変化に対処するジョブ スクリプトの機能強化、ジョブ失敗後の再始動性です。 これらのジョブ プラクティスはデータ ウェアハウスを構築する際の標準指針にもなります。
- ジョブ名は必ずジョブを実行するときの名前を使用する。
- ジョブ変数ファイルは、ユーザー ID、パスワード、ファイル名、ソース名/アーカイブ ディレクトリ名、プロデューサ インスタンスとコンシューマ インスタンスの数など、変動的で、共通のパラメータのキャプチャに使用する。
- APPLY文のたびに異なるターゲットに同じデータを送信できるよう、Duplicate APPLY機能を利用してバックアップまたはアーカイブを並行して実行する。
- チェックポイントの頻度を定義して、失敗時のロードの精度を制御する。 頻度の値が小さくなるほど、ジョブの回復時間を短縮できますが、チェックポイントの設定時間が長くなります。
- システム失敗後のキャッチ アップのためにロード プロトコル(StreamからUpdateなど)を切り替える。
- パラメータをジョブ スクリプト間に分散させず、一箇所に定義できるよう、ジョブは常にジョブ変数ファイルとともに実行する。