公式文書によると、Recovery Manager（RMAN）を使用することが推奨されており、Oracleデータベースをバックアップおよび復元するための最も最適な方法の1つです。 また、「ホット」バックアップを実行して、データベースを読み取りや変更のためにアクセスできるようにしておくと、このユーティリティはアクセス性の高いシステムをバックアップするための強力なツールとなります。
この記事では、Recovery Managerのすべての機能については説明しませんが、エンタープライズでのフォールトトレランスシステムの構築を再検討できる興味深いバックアップ戦略の1つについて説明します。 増分更新されたバックアップテクノロジーは、Oracleの10番目のバージョンに登場しました。 データベースイメージのコピー（イメージコピー）と同じ回復オプションを提供しますが、より高速で、システムリソースの負荷が低くなります。 また、このオプションは、データの更新に使用する必要のあるログが少ないため、回復時間を短縮します。
コンセプト
Recovery Managerの助けを借りてデータを保存することの本質は、データベースの完全なコピーを一度作成し、その後、変更をコピーするだけでなく、増分バックアップを実行するたびに、前のバックアップがデータベースイメージにロールされ、データが更新されることです。 その結果、物理レベルのバックアップは常にデータのコピーと変更ファイルで構成されます。
実行例を考えてみましょう。
走る
{
データベースのコピーを復元する
WITH TAG 'incremental';
バックアップ
増分レベル1
タグ「インクリメンタル」を使用したコピーのリカバリ用
データベース
}
このコマンドを毎日実行するようにスケジュールできます。 解釈方法は次のとおりです。
0日目
- RECOVER-増分バックアップも完全コピーもないため、コマンドは効果がありません。
- BACKUP-データのコピーがないため（レベル0）、コマンドは指定されたタグでデータを作成します。 このレベルは、ループを作成するために必要です。
1日目
- RECOVER-今回はデータベースのコピーがありますが、適用できる最初のレベルの増分バックアップはありません。 コマンドは効果がありません。
- バックアップ-チームは最初のレベルの増分バックアップを作成し、それに必要なタグを割り当てます。 0日目から1日目に行われた変更が含まれます。
2日目以降
- RECOVER-前日に作成された最初のレベルの増分バックアップがデータベースのコピーに適用され、記録された変更がロールフォワードされます。
- バックアップ-チームは最初のレベルの増分バックアップを作成し、それに必要なタグを割り当てます。 1日目から2日目に行われた変更が含まれます。
選択したバックアップ戦略により、最後の増分バックアップの時点でデータベースを復元できます。 たとえば、週ごとの回復間隔を作成するなど、過去に必要な期間の回復の可能性を維持しながら間隔を延長することは許可されます。したがって、増分コピーは、取得から7日が経過するまでデータを更新しません。 同時に、差分の変更を含む新しいファイルが毎日生成され、以前のバックアップから考慮されます。
7日間の回復コマンドの例を考えてみましょう。
走る
{
データベースのコピーを復元する
WITHタグ「インクリメンタル」
時間「SYSDATE-7」まで;
バックアップ
増分レベル1
タグ「インクリメンタル」を使用したコピーのリカバリ用
データベース
}
最適化
増分更新バックアップとともに、別のテクノロジーであるブロック変更追跡を使用できます。 バックアップを実行するとき、Recovery Managerは各データブロックを調べ、変更を追跡します。 このようなプロシージャの実行時間は、データファイルのサイズに直接比例します。 わずかなブロックのみが変更された場合でも、非常に長くなる可能性があります。 10番目のバージョンから、Oracleは新しいテクノロジーを導入しました-BLOCK CHANGE TRACKING、以前のバックアップの瞬間から変更されたブロックを記録する特別なファイルを作成できます。 Recovery Managerはそれを使用して変更を識別します。 使用可能なすべてのデータを完全に調査する必要がなくなりました。 したがって、増分コピーの実行速度は、変更されたブロックに正比例します。 このような機能の実装により、バックアップ時間を大幅に短縮できます。
- 変更追跡ファイルのサイズは非常に小さく、管理の必要はまったくありません（すべてのデータファイルの合計サイズに対する割合は約1 / 30,000です）。
- デフォルトでは、ファイルはFRAゾーンにありますが、この機能がオンになっているときに指定された場所に配置することもできます。
- RMANは変更追跡ファイルを予約しないため、破損または誤って削除された場合、新しいファイルを作成するだけで済みます（したがって、変更されたデータの最初の入力が再度実行されます）。
素早い回復
DBMSをバックアップするための上記の戦略を使用して、個々の破損したファイルを迅速に回復できます。
- データベースが開いている場合-ファイルをオフラインにします。
- 次のコマンドを実行します。コピーするデータファイル 'datafile_name'を切り替えます。
- recoverを実行して現在のログを適用します。
- ファイルをオンラインにします。
この場合、インスタンスは新しい場所にあるファイルで動作するようになります。 同様に、以前の場所に戻すことができます。
すべてのファイルが失われた場合、次のコマンドを使用して事前にマウントすることにより、データベース全体を完全に復元できます。
データベースをコピーして切り替えます。
データベースの回復。
おわりに
この記事で紹介するバックアップ戦略は、DBMSをデータ損失から保護するための非常に効果的な方法です。 すでに変更されたブロックを増分バックアップと組み合わせて修正する技術により、毎日のホットバックアップ手順を大幅に高速化できます。 また、破損したファイルを新しいコピーにすばやく切り替えることができるため、リカバリ時間にとって重要なシステムで非常に役立ちます。 また、バックアップは個別のファイル操作を必要としない完全なコピーであるため、たとえば開発環境用にベースクローンを展開する単純さにも注目する価値があります。
著者はオレグ・コンスタンチノフです。