2024年3月5日 高速リカバリ領域
Facebook にシェア
LINEで送る

はじめに

こんにちは！2019年に新卒で入社した、技術チームの「たくみ」です。
現在はお客様環境の保守・運用業務に奮闘する日々です。

今回はバックアップの管理に役立つ高速リカバリ領域についてご紹介いたします。
　

今回執筆してくれた社員は資格取得記事も多数あります。
Oracle Cloud Infrastructure Foundations 2021 Certified Associateを取得しました！
ORACLE MASTER Silver DBA 2019を取得しました！
Oracle Cloud Infrastructure Classic 2018 Associate Architectを取得しました！

高速リカバリ領域とは

早速、高速リカバリ領域についてご紹介致します。
高速リカバリ領域とはリカバリ関連ファイルを格納しているディレクトリです。
主に以下のファイルを格納することができます。

これらのファイルを自動的に管理してくれるのが高速リカバリ領域です。
そのメリットは主に以下の3つです！

  • リカバリ関連のファイルを一元管理することができる。
  • 各ファイルの出力先を細かく指定する手間がない。
  • 各ファイルの保存ポリシーに則り、不要になったファイルを自動的に削除してくれる。
    ※各ファイルの保存ポリシーはそれぞれ設定する必要があります。

早速、実機で高速リカバリ領域を触ってみたいと思います！

どんな検証になるのか楽しみですね！
検証環境をお持ちの方は是非一緒に試してみて下さい。

高速リカバリ領域の検証

高速リカバリ領域の設定方法

高速リカバリ領域を構成するためには以下の初期化パラメータを設定する必要があります。

  • db_recovery_file_dest
  • db_recovery_file_dest_size

db_recovery_file_destは高速リカバリ領域に指定するディレクトリを設定し、db_recovery_file_dest_sizeは高速リカバリ領域として利用できるサイズを指定します。

今回はそれぞれのパラメータを下記のように設定しています。

db_recovery_file_dest＝/home/oracle/db_recovery
db_recovery_file_dest_size=2048MB

 RMAN バックアップの取得

それでは早速、 RMAN バックアップを取得してみましょう！

今回はバックアップファイルの出力先を明示的に指定するパラメータである、CONFIGURE CHANNEL DEVICE TYPE DISK FORMATは設定していません。
また、この RMAN バックアップではOracleのデータファイル、アーカイブ・ログ、制御ファイルの自動バックアップを取得しています。

[oracle@ORA19-DG db_recovery]$ rman target /

Recovery Manager: Release 19.0.0.0.0 - Production on 土 5月 21 18:09:16 2022
Version 19.8.0.0.0
Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.
ターゲット・データベース: ORCL (DBID=1633004344)に接続されました
RMAN> backup database plus archivelog;

backupを2022/05/21 18:10:03で開始しています

・
【略】
・

Control File and SPFILE Autobackupを2022/05/21 18:10:40で開始しています
ピース・ハンドル=/home/oracle/db_recovery/ORCL/autobackup/2022_05_21/o1_mf_s_1105294240_k8kc4jkv_.bkp コメント=NONE
Control File and SPFILE Autobackupを2022/05/21 18:10:41で終了しました

RMAN> exit

[oracle@ORA19-DG 2022_05_21]$ ls -ltr /home/oracle/db_recovery/ORCL/backupset/2022_05_21
合計 866636

-rw-r----- 1 oracle oinstall 255140352  5月 21 18:10 o1_mf_annnn_TAG20220521T181006_k8kc3hb2_.bkp
-rw-r----- 1 oracle oinstall 617136128  5月 21 18:10 o1_mf_nnndf_TAG20220521T181022_k8kc40o2_.bkp
-rw-r----- 1 oracle oinstall  15155200  5月 21 18:10 o1_mf_annnn_TAG20220521T181038_k8kc4h5d_.bkp

[oracle@ORA19-DG 2022_05_21]$

[oracle@ORA19-DG 2022_05_21]$ ls -ltr /home/oracle/db_recovery/ORCL/autobackup/2022_05_21
合計 10464

-rw-r----- 1 oracle oinstall 10715136  5月 21 18:10 o1_mf_s_1105294240_k8kc4jkv_.bkp

[oracle@ORA19-DG 2022_05_21]$

無事、高速リカバリ領域にバックアップが取得されましたね！
また、データファイルとアーカイブ・ログのバックアップファイルは
/home/oracle/db_recovery/ORCL/backupset/2022_05_21
制御ファイルの自動バックアップは
/home/oracle/db_recovery/ORCL/autobackup/2022_05_21
に格納されています。

このようにバックアップファイルの種類ごとに、自動的にディレクトリ分割をしてくれます。

一目でなんのバックアップファイルか分かりますね！

不要なバックアップファイルの削除

さて、このバックアップを取得した時点の高速リカバリ領域のサイズは約1,126MＢでした。
そのうち今回取得したバックアップファイルの総サイズは860MBでした。
そのため、もう一度バックアップを取得すると高速リカバリ領域があふれてしまう可能性があります・・・

再度 RMAN バックアップを取得し、どうなるか見てみましょう。

ちなみに、バックアップファイルの保存ポリシーは１世代保存になっています。
つまりバックアップを取得すると、それ以前に取得したファイルは不要なファイルとなります。
　

RMAN> backup database plus archivelog;
backupを2022/05/21 18:12:54で開始しています
現在のログがアーカイブされました。
・
【略】
・

Control File and SPFILE Autobackupを2022/05/21 18:13:07で開始しています
ピース・ハンドル=/home/oracle/db_recovery/ORCL/autobackup/2022_05_21/o1_mf_s_1105294387_k8kc93fj_.bkp コメント=NONE
Control File and SPFILE Autobackupを2022/05/21 18:13:08で終了しました
RMAN>

無事にバックアップが取得できました！

しかし、高速リカバリ領域のサイズを確認すると約1,638MBでした。
計算が合いませんね・・・
そこで、先ほどのバックアップ格納先を確認してみると・・・
　

[oracle@ORA19-DG 2022_05_21]$ ls -ltr /home/oracle/db_recovery/ORCL/backupset/2022_05_21
合計 1554360
-rw-r----- 1 oracle oinstall 617136128  5月 21 18:10 o1_mf_nnndf_TAG20220521T181022_k8kc40o2_.bkp
-rw-r----- 1 oracle oinstall  15155200  5月 21 18:10 o1_mf_annnn_TAG20220521T181038_k8kc4h5d_.bkp
-rw-r----- 1 oracle oinstall 319734272  5月 21 18:12 o1_mf_annnn_TAG20220521T181255_k8kc8qb2_.bkp
-rw-r----- 1 oracle oinstall 639565824  5月 21 18:13 o1_mf_nnndf_TAG20220521T181258_k8kc8v03_.bkp
-rw-r----- 1 oracle oinstall     67072  5月 21 18:13 o1_mf_annnn_TAG20220521T181306_k8kc925g_.bkp

[oracle@ORA19-DG 2022_05_21]$

お分かりいただけますでしょうか。先ほどのバックアップで取得されていた
「o1_mf_annnn_TAG20220521T181006_k8kc3hb2_.bkp」が削除されています！
これは高速リカバリ領域があふれそうになった際に、その時点では不要となった上記ファイルが削除されたということです。

※注意
バックアップは順番に取得されています。そのため、以前に取得されたバックアップファイルは次のバックアップコマンドが実行されたタイミングではなく、そのバックアップに対応するバックアップが取得されたタイミングで不要とみなされます。

このように各ファイルの保存ポリシーの観点から不要とみなされたファイルが自動的に削除されるため、領域にファイルが永遠にたまっていくことはありません。

明示的に管理する手間が省けますね！

しかし、不要なファイルが存在しない状態で高速リカバリ領域があふれてしまうと、下記のようにバックアップが失敗してしまいます。
また、アーカイブ・ログを高速リカバリ領域に出力している場合も、高速リカバリ領域があふれてしまう事でアーカイブ・ログが出力できなくなりDB障害が発生するケースもあります。

そのため、管理者はサイズに余裕をもって高速リカバリ領域を設計する必要があります。
　

RMAN> backup database plus archivelog;
backupを2022/05/21 18:54:47で開始しています

・
【略】
・

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: backup plus archivelogコマンドが05/21/2022 18:54:56で失敗しました
ORA-19809: リカバリ・ファイルの制限を超えています
ORA-19804: 67108864バイトのディスク領域を1073741824バイト制限から再利用できませんど

同様のエラーに遭遇した際には、ディスク領域の使用量も着目してみてくださいね。
保守・運用業務の参考になれば幸いです！

まとめ

今回は高速リカバリ領域とバックアップに関する機能についてご紹介致しました。
最後にまとめさせて頂きます。

高速リカバリ領域のメリット
  • リカバリ関連のファイルを一元管理することができる。
  • バックアップ の出力先を細かく指定する手間がない。
  • 各ファイルの保存ポリシーに則り、不要となったファイルを自動的に削除してくれる。
高速リカバリ領域に格納できるファイル
高速リカバリ領域を構成するために
設定が必要な初期化パラメータ
  • db_recovery_file_dest
  • db_recovery_file_dest_size

最後までご精読頂きまして、ありがとうございました！
以上になります。

Oracle Databaseでお困りのことがありましたらお気軽にお問い合わせください。

投稿者プロフィール

DBひとりでできるもん運営チーム
DBひとりでできるもん運営チーム
「DBひとりでできるもん」運営チームです。
「親しみやすさと技術力」をテーマに、技術情報・サービス・インフラ系資格取得に役立つ情報、社員等の情報をお届けします。
70名弱の事業部員で鋭意、執筆中です。
少しでも当社を知って頂けるよう、愛情込めて頑張ります！
※facebook、X(旧twitter)、インスタグラムでは「DBひとりでできるもん」の更新情報を発信しています。

　　アナタにおすすめのこちらの関連記事も読んでみませんか？

Facebook にシェア
LINEで送る

カテゴリー
高速リカバリ領域