ステージング

ステージングについて

ステージングでは、バックアップ・イメージ・インスタンスを別のコンテナに自動的にコピーまたは移動する準備として、1つ以上のバックアップ・イメージのインスタンスをコンテナに格納できます。

Oracle Secure Backupの場合、ステージング・コンテナはディスク・プールまたはクラウド・デバイスです。一般的なステージング・シナリオでは、バックアップ・インスタンスはディスク・プールからテープ・ドライブに移動されます。

ステージングには複数のバックアップ・イメージ・インスタンスを含めることができ、スケジュールされた時刻に特定の条件に基づいて実行されるように構成できます。条件の例には、一連のバックアップ・イメージのサイズ、バックアップのクライアント・ホスト、およびデータベース情報などが含まれます。

ステージングはオンデマンドでも実行できます。

ステージングの利点

ディスクを使用すると、テープよりも高速にバックアップ・ファイルにランダム・アクセスできます。テープは、長期保存用のオフサイトに移動できます。ステージングでは、ディスクとテープの両方にバックアップを自動的に格納できるため、高速なリストアおよびテープに格納する利点の両方が実現します。
ステージングでは、バックアップおよびリカバリ操作で複数のストリームをパラレルに使用できます。バックアップの場合、データは後でテープ・ドライブにコピーされます。
ステージングが使用されている場合、ステージング操作が遅いクライアントは同時にディスク・プールにバックアップされてから、単一の高速なデータ・ストリームでテープにコピーされるため、ステージング操作が遅いクライアントをテープにバックアップする場合に発生する停止および再配置の問題を最小限に抑えることができます。
ステージングでは、バックアップ・インスタンスはテープに書き込まれた後もディスク上に残ります。各インスタンスには異なる有効期限を設定できるため、バックアップは、迅速にリストアするためにディスク上に残る一方で、長期保存用のテープにも存在します。
ステージングを使用すると、リモートOracle Secure Backupメディア・サーバーを使用してオフサイトの場所でバックアップ・イメージ・インスタンスの追加のコピーを作成できるため、冗長性による追加のデータ保護を提供できます。

ステージングの概念

次の用語は、ステージングの概念を説明しています。

ステージング: ステージングとは、最終的に別のコンテナに書き込まれる予定のバックアップ・イメージの仮コンテナとしてディスク・プールを一時的に使用することです。特定のバックアップ・ジョブで排他的に使用するために物理テープ・ドライブに割り当てる時間を削減して効率を向上させるために、バックアップは最初にディスク・プール・デバイスに書き込まれます。ディスク・プールにステージングされたバックアップ・イメージは、スケジュールに基づいて、あるいはディスク・プール・デバイス内のデータ量に基づいて、テープへの移動がスケジュールされます。ディスク・プールのバックアップ・イメージ・インスタンスが別のコンテナにコピーされた後は、必要に応じて削除できます。
ステージ・ソース・ジョブ: ステージ・ソース・ジョブ(通常は単にソース・ジョブと呼ばれます)は、バックアップ・イメージをステージ・プールに書き込む最初のバックアップ・ジョブです。ソース・ジョブは、バックアップ・イメージ・インスタンスを別のステージ・ディスク・プール・デバイスに書き込むオンデマンド・バックアップ・ジョブ、バックアップ・スケジュール、cpinstanceジョブ、または別のcopyfromstageジョブの場合があります。
Copy-from-stage: Copy-from-stageは、バックアップ・イメージ・インスタンスを宛先コンテナに自動的にコピーすることを指します。
copyfromstageジョブ: copyfromstageジョブは、ステージ・ソース・ジョブで作成されたバックアップ・イメージ・インスタンスを宛先コンテナにコピーするジョブです。
stagescanジョブ: stagescanジョブは、バックアップ・イメージ・インスタンスをスキャンして、1つ以上のステージ・ディスク・プール・デバイスにフィルタ処理します。デバイスにアタッチされているステージ・ルールと一致するインスタンスは、stagescanジョブが作成したcopyfromstageジョブによってグループ化され、コピーされます。stagescanジョブは、0個以上のcopyfromstageジョブを作成できます。stagescanジョブは通常、stagescanスケジュールによって起動されますが、obtool stagescanコマンドを使用してオンデマンドで起動することもできます。

ノート:
すべてのcopyfromstageジョブには、1から開始して増加するシステム・ジョブID番号があります。スケジュールされたstagescanジョブにも、システム・ジョブIDがあります。obtool lsjobコマンドの出力では、システム・ジョブは常にジョブ・リストの最初に表示され、これは非常に長いジョブ・リストの最上部に表示されます。copyfromstageジョブおよびstagescanジョブの両方を表示するには、lsjobコマンドを発行するときにそれらのジョブをジョブ・タイプとして指定します。lsjobコマンドの詳細は、『Oracle Secure Backupリファレンス』を参照してください。
ステージング済: バックアップ・イメージ・インスタンスは、そのインスタンスが即時にまたは将来の時点でステージ・コピーされた場合、ステージング済であるといいます。
移行: バックアップ・イメージ・インスタンスの移行とは、ソース・コンテナから宛先コンテナへのバックアップ・イメージ・インスタンスのステージ・コピーを実行し、正常にコピーされた後、ソース・コンテナ内のバックアップ・イメージ・インスタンスを削除することを指します。移行という用語は、ステージングのコンテキストでは移動と同義です。
オンデマンド・ステージング: オンデマンド・ステージングとは、特定のステージ・デバイスおよび特定のステージ・ルール・セットと一致するすべてのバックアップ・イメージ・インスタンスをコピーする即時stagescanジョブを作成するためにobtoolコマンドを発行することを指します。
ソース・コンテナ: 1つ以上のバックアップ・イメージのインスタンスが含まれているステージング・ディスク・プール・デバイス。
宛先コンテナ: copyfromstageジョブがステージング・ディスク・プールからバックアップ・イメージをコピーするターゲット・デバイス。宛先コンテナにはテープ・デバイスまたは別のディスク・プールを使用できます。

Oracle Secure Backupのデフォルト・ステージ・ルールについて

ステージ・ルールは、どのバックアップ・イメージをいつコピーするかを制御します。また、このルールを使用して、バックアップ・イメージがステージ・デバイス上に確実に残る最小時間を制御できます。

Oracle Secure Backupには、すべてのインスタンスと一致するデフォルト・ステージ・ルールが用意されています。スケジュールされたstagescanジョブについて、デバイスの他のステージ・ルールがバックアップ・イメージ・インスタンスと一致しない場合、そのインスタンスは常にデフォルト・ステージ・ルールによってコピーされます。デフォルト・ステージ・ルールの目的は、ステージ・ディスク・プール内のすべてのインスタンスが必ずコピーされるようにすることです。すべてのインスタンスをコピーすることで、構成エラーが発生して必要なインスタンスがコピーされていない場合に、ソース・ディスク・プールで期限切れになったバックアップ・イメージ・インスタンスが完全に失われることがないようにします。

ステージ・ルールに一致するとは、インスタンスがメディア・ファミリ名および1つ以上の場所(データベースID、データベース名、またはファイル・システムのホスト名)と一致することを意味します。ステージ・ルール制限リストにクラウド・デバイスが含まれている場合、インスタンスがルールと一致するには暗号化されている必要もあります。条件が一致しない場合、インスタンスに対してデフォルト・ステージ・ルールは起動されません。次の状況では、一致した場合でもインスタンスがコピーされない可能性があります。

stagescanジョブを起動した現在のstagescanスケジュールと一致しないstagescanスケジュールがステージ・ルールにリストされている場合。インスタンスは後で他のスケジュールが実行されるときに、そのルールによってコピーされます。
一致するステージ・ルールの最小経過時間フィルタの値、または最小コピー・サイズ・フィルタの値が、インスタンスがコピーされることのないような大きな値に設定されている場合。インスタンスはその有効期限を超えた場合でも削除されません。これらのフィルタに値を設定する場合は、常に注意が必要です。

デフォルト・ステージ・ルールの制限リストにあるデバイスはエラー・デバイスとみなされるため、デフォルト・ステージ・ルールによってそこにコピーされたインスタンスは誤りとみなされます。これらの誤りは、ソース・ディスク・プール・デバイスに格納されているこれらのバックアップ・イメージのインスタンスと一致する追加ステージ・ルールを追加することで訂正できます。

ノート:

ステージ対応のOracle Secure Backupクラウド・ストレージ・デバイスでは、デフォルトのステージ・ルールはサポートされていません。ステージ対応のOracle Secure Backupクラウド・ストレージ・デバイス内に格納されていて、ステージ・ルールで選択されていないバックアップ・インスタンスは、期限切れになるとパージされる場合があります。このようなインスタンスは、ステージングされていない場合は削除できます。すべてのバックアップ・インスタンスが確実にステージングされるようにするには、デバイスのステージング・ルールのリストの最後に"catch all"ステージ・ルールを追加します。

ステージ・ループ

Oracle Secure Backupでは、copyfromstageジョブがソースと宛先の両方に同じディスク・プールを使用するのを防止します。ただし、複数の単一プールでステージングが有効になっていると、ステージ・ループが発生した場合に、インスタンスが元のプールにコピーして戻される可能性があります。たとえば、次の状況では、ステージ・ループが発生する場合があります。

copyfromstageジョブのstagescanスケジュールによって、ソース・ディスク・プールAから、ステージングが有効になっている宛先ディスク・プールBにインスタンスがコピーされた場合。後で別のstagescanスケジュールによって、宛先プールBの新しいインスタンスをコピーして元のソース・ディスク・プールAに戻すcopyfromstageジョブが作成された場合。
インスタンスがプールAからプールBに、次にプールBからプールCに、その後プールCから元のプールAにコピーして戻された場合。

ステージ・ループは、ディスク・プールの領域がなくなるまで同じインスタンスが何度も容易にレプリケートする可能性があるため、回避する必要があります。

ステージ・ループを防止するために、Oracle Secure Backupでは、ステージ・ルールがデバイスに追加されたり、ステージ・ルール制限リストに対して変更が行われたときに次の処理が実行されます。

ソース・デバイスのステージ・ルール・リストをスキャンし、各ステージ・ルール制限リストにあるディスク・プールのいずれかにインスタンスがコピーされる可能性があると想定します。
潜在的な宛先ディスク・プール・デバイスの各ステージ・ルールの制限リストをスキャンし、これらのディスク・プールのいずれかにインスタンスがコピーされる可能性があると想定します。

これらのディスク・プールのいずれかが元のディスク・プール、またはすでにインスタンスの宛先として想定されている他のディスク・プールの場合は、構成コマンドが失敗し、エラー・メッセージが表示されます。たとえば:

ob> chstage --restrict pool1 srule2
Error: stage loop - pool1 -> srule2:pool0 -> srule1:pool1
Error: restriction list not changed
ob>

ステージ・ループ検出の制限

ディスク・プールでステージングが有効になっている場合でもインスタンスが任意のステージ・ルールと一致するかどうかを確認するためのチェックはありません。ステージ・ルール制限リストを変更して、ステージ・ループを作成することはできません。
通常、Oracle Secure Backupでステージ・ループ検出のために検索するのは、深さ4までのディスク・プールのみです。多数のディスク・プールとステージ・ルールがある場合は、検索が10秒後にタイムアウトする可能性があります。Oracle Secure Backupでは、所要時間に関係なく常に深さ2ディスク・プール・レベルを検索することが保証されます。したがって、前述の例の場合は、必ず検出されます。
ディスク・プールに、ステージ・ルール制限リストにディスク・プール・デバイスが指定されたステージ・ルールがある場合は、ステージ・ループの原因となるため、そのディスク・プール・デバイスをデフォルト・ステージ・ルールの制限リストに追加することはできません。
制限リストにディスク・プールが指定されたステージ・ルールは、デフォルト・ステージ・ルールの制限リストにすでにあるディスク・プール・デバイスには追加できません。

ステージングの設定

次に、ステージングを設定するときに注意する必要のある概念とガイドラインをいくつか示します。

ステージングを使用するとき、ステージ・ディスク・プール・デバイスにコピーされたバックアップ・イメージ・インスタンスは、すべて別の場所にコピーされると想定されます。この想定によって、コピーが必要なインスタンスがコピーされていない状態や、インスタンスが失効して削除され、リストアするバックアップがないといった不適切な構成が防止されます。これを防止するために、ステージング・ディスク・プール内のインスタンスは、失効した場合でも、コピーされるまで自動的に削除されることはありません。(ただし、必要に応じて、rminstanceコマンドを使用してインスタンスを明示的に削除できます。)

意図的にバックアップ・イメージ・インスタンスがコピーされるようにデフォルト・ステージ・ルールを使用しないでください。かわりに、エラーが発生したディスク・プールにインスタンスが表示されたときに、他のステージ・ルールと一致しないインスタンスが識別されるように、エラー・ディスク・プールをターゲット・デバイスとして指定して使用してください。

デフォルト・ステージ・ルールを使用すると、ステージング設計内の複数のインスタンスをコピーできますが、そのようにすると、デフォルト・ルールは常にいずれのルールとも一致しないインスタンスをコピーするため、インスタンスが予定どおりにコピーされていないことを検出しづらくなる可能性があることに注意してください。したがって、ルールでコピーする必要があるインスタンスがそのルールと一致しない場合、そのインスタンスは、デフォルト・ステージ・ルールによってコピーされる他のすべてのインスタンスと混在して取得されます。
必要な最小数のステージ・ルールを使用して、stagescanジョブが可能なかぎり高速で実行されるようにします。
copyfromstageジョブのインスタンスが多すぎないようにするには、最初にステージングを使用するようにアップグレードするときに、既存のディスク・プールをステージング・デバイスとして使用しないでください。既存のディスク・プールのインスタンスが比較的少数である場合は、このガイドラインを無視できます。
ステージ・ルールの制限リストを空のままにしないでください。宛先デバイスを明示的にリストします。

ステージングを設定するには様々な方法があります。次に、1つの例を示します。

ステージングを設定するには:

mkdevコマンドを使用して、ターゲット・ディスク・プール・デバイスを作成します。
```
ob> mkdev --type disk --initialize --attach somehost:/somepath/pooltarget pooltarget
```

mkschedコマンドを使用して、2つのstagescanスケジュールを作成します。

ob> mksched --type stagescan --day daily --time 6:00 scheda
ob> mksched --type stagescan --day daily --time 12:00 schedb

3つのステージ・ルールを作成します。--dbid、--dbnameおよび--fshostオプションは、これらの例で指定されていないため、すべてデフォルトでアスタリスク・ワイルドカード文字(*)に設定されます。
```
mkstage --schedule scheda --matchfamily mfa  --targetfamily mftarget --restrict pooltarget rulea
mkstage --schedule schedb --matchfamily mfb  --targetfamily mftarget --restrict pooltarget ruleb
mkstage --matchfamily mfc  --targetfamily mftarget --restrict pooltarget rulec
```
最初のステージ・ルールruleaは、メディア・ファミリmfaと一致し、スケジュールschedaを使用します。

2番目のステージ・ルールrulebは、メディア・ファミリmfbと一致し、スケジュールschedbを使用します。

最後のステージ・ルールrulecは、メディア・ファミリmfcと一致し、スケジュールがありません。
デフォルト・ステージ・ルールのターゲット・メディア・ファミリと制限を設定します。

ターゲット・メディア・ファミリと制限リストがデフォルト・ステージ・ルールに設定されるまで、--staging yesを使用してディスク・プール・デバイスでのステージングを有効にすることはできません。これは、1回のみ実行する必要があります。(次の例では、vt1という名前のテープ・デバイスがあると想定しています。)
```
ob> chstage --targetfamily mftarget --restrict vt1 OSB-DEFAULT-STAGE-RULE
```
ステージング・ディスク・プール・デバイスを作成します。
```
ob> mkdev --type disk --initialize --stagerule rulea,ruleb,rulec --staging yes
 --attach somehost:/somepath/poolstage poolstage
```
スケジュールschedaがトリガーされると、ステージ・ルールと一致するインスタンスstagea(つまり、メディア・ファミリmfaを使用してバックアップされたインスタンス)は、メディア・ファミリmftargetを使用してディスク・プールpoolstageにコピーされます。ステージ・ルールrulecと一致するインスタンス(つまり、メディア・ファミリmfcを使用してバックアップされたインスタンス)がコピーされます。rulecにはスケジュールがないため、すべてのスケジュールと一致します。

スケジュールschedbがトリガーされると、ステージ・ルールと一致するインスタンスstageb(つまり、メディア・ファミリmfbを使用してバックアップされたインスタンス)は、メディア・ファミリmftargetを使用してディスク・プールpoolstageにコピーされます。ステージ・ルールrulecと一致するインスタンス(つまり、メディア・ファミリmfcを使用してバックアップされたインスタンス)がコピーされます。