はじめに
こんにちは!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,126MBでした。
そのうち今回取得したバックアップファイルの総サイズは860MBでした。
そのため、もう一度バックアップを取得すると高速リカバリ領域があふれてしまう可能性があります・・・
再度 RMAN バックアップを取得し、どうなるか見てみましょう。
ちなみに、バックアップファイルの保存ポリシーは1世代保存になっています。
つまりバックアップを取得すると、それ以前に取得したファイルは不要なファイルとなります。
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バイト制限から再利用できませんど
同様のエラーに遭遇した際には、ディスク領域の使用量も着目してみてくださいね。
保守・運用業務の参考になれば幸いです!
まとめ
今回は高速リカバリ領域とバックアップに関する機能についてご紹介致しました。
最後にまとめさせて頂きます。
高速リカバリ領域のメリット |
|
---|---|
高速リカバリ領域に格納できるファイル | |
高速リカバリ領域を構成するために 設定が必要な初期化パラメータ |
|
最後までご精読頂きまして、ありがとうございました!
以上になります。
Oracle Databaseでお困りのことがありましたらお気軽にお問い合わせください。
投稿者プロフィール
- Oracle Cloud2024年12月5日OCI ブロック・ボリュームのパフォーマンスについて検証してみた!
- 23ai2024年12月4日【Oracle 23ai 新機能】True Cacheを紹介・導入してみました
- Oracle Cloud2024年12月3日プライベートDNSで名前解決してみた!
- Oracle Cloud2024年11月28日OCIのMySQLでレプリケーションを使用してみました!