データベースSYSUDTLIBはデータベースDBCとリンクされており、DBCが復元される場合にのみ復元されます。 SYSUDTLIBは、RESTORE文で個別のオブジェクトとして指定できません。
データベースDBCが復元操作に関与している場合には、常にデータベースDBCが最初に復元され、その後でデータベースSYSUDTLIBが復元されます。 さらにデータベースが復元される場合、アルファベット順にSYSUDTLIBの後で復元されます。
全AMPレベルの復元および個々のAMPレベルの復元には、次の操作によって作成されたアーカイブ ファイルを使用することができます。
- 全AMPレベルのアーカイブ
- クラスタ レベルのアーカイブ
- 個々のAMP単位のアーカイブ
- 選択パーティションのアーカイブ
Teradata Databaseの復元処理では、さまざまなタイプのオブジェクトを復元する際に、Teradata ARCは次のような形式のメッセージを発行します。
"UDFname" - n,nnn,nnn BYTES, n,nnn,nnn ROWS RESTORED "procedurename" - n,nnn,nnn BYTES, n,nnn,nnn ROWS RESTORED "macroname" - MACRO RESTORED "methodname" - METHOD RESTORED "methodname" - n,nnn,nnn BYTES, n,nnn,nnn ROWS RESTORED "tablename" - n,nnn,nnn BYTES, n,nnn,nnn ROWS RESTORED "triggername" - TRIGGER RESTORED "UDTname" - TYPE RESTORED "viewname" - VIEW RESTORED
すべてのテーブルが復元されると、次のメッセージが表示されます。
STATEMENT COMPLETED
復元の開始時およびシステムの再起動時に、すべてのオフライン状態のAMPが出力ログにリストされます。
復元の終了後には、出力ログをテーブルのリストと比較し、オフライン状態のため復元できなかったテーブルがないかどうかを確認してください。
Teradata ARCは、復元操作で重複行をサポートしています。 ただし、重複行を含むテーブルの復元中に再起動が発生した場合は、再起動に関係した重複行が除去されることがあります。
構成の異なる古いバージョンのソース システムからデータベースやテーブルの復元を実行するときには、ターゲット システムにデータを復元するために必要となる時間と領域が影響を受けます。 データは、AMPの新しいセット間で再分散されなければなりません。 AMPの数がソース システムとターゲット システムで異なる場合、システムは、別のアルゴリズムを使用してコピーおよび復元を実行します。 構成が異なる場合は、その新しいアルゴリズムを使用した方が通常は高速になります。 限定的な状況においては、古いアルゴリズムの方が高速になる可能性があります。
固有セカンダリ インデックスは、すべてのAMPに分散されます。 そのため、復元されていないクラスタにインデックスがある場合でも、RESTOREで固有のセカンダリ インデックスが再作成されることはありません。 BUILD文を使用して固有インデックスを作成し、再検証してください。