【再掲載】高速リカバリ領域アーカイブ・ログの管理について

2023年2月13日 Oracle Database 管理

1 はじめに
2 高速リカバリ領域にアーカイブ・ログを出力させる
3 実機検証
4 まとめ
5 さいごに

はじめに

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

「高速リカバリ領域について」という記事で高速リカバリ領域をご紹介させて頂きましたが、今回はその
高速リカバリ領域におけるアーカイブ・ログの管理についてご紹介します。

さっそくはじめていきましょう。

今回執筆してくれた社員の資格取得記事も是非ご覧ください♪
●Oracle Cloud Infrastructure Foundations 2021 Certified Associateを取得しました！
●ORACLE MASTER Silver DBA 2019を取得しました！
●Oracle Cloud Infrastructure Classic 2018 Associate Architectを取得しました！

高速リカバリ領域にアーカイブ・ログを出力させる

アーカイブ・ログの出力先はlog_archive_dest_nという初期化パラメータに設定します。
「n」には１から３１の数字が入ります。

各数字の初期化パラメータに対して、アーカイブ・ログの出力先を設定することで、同じ内容のアーカイブ・ログを別々のディレクトリに出力させることが可能となります。
こうすることによって、あるディレクトリのアーカイブ・ログが消失してしまっても、別のディレクトリのアーカイブ・ログを使用することでデータベースの復旧が可能となります。

今回は検証のために出力させますので、log_archive_dest_1のみに出力先を設定しています。

高速リカバリ領域にアーカイブ・ログを出力させるには、このパラメータに対して、下記のように設定致します。

log_archive_dest_1=LOCATION=USE_DB_RECOVERY_FILE_DEST

それでは早速、実機でアーカイブ・ログの管理について見ていきましょう。

実機検証

アーカイブ・ログの出力

実機では下記のように高速リカバリ領域とアーカイブ・ログの出力先を設定しています。
高速リカバリ領域の設定については、「高速リカバリ領域について」の記事をご参照ください。

log_archive_dest_1=LOCATION=USE_DB_RECOVERY_FILE_DEST
db_recovery_file_dest=/home/oracle/db_recovery
db_recovery_file_dest_size=6144MB

それではアーカイブ・ログを出力させます。
適当なテーブルを作成して、それを更新させていきます。

すると・・・

[oracle@ORA19-DG 2022_06_15]$ ls -ltr /home/oracle/db_recovery/ORCL/archivelog/2022_06_15
合計 80
-rw-r----- 1 oracle oinstall 14336  6月 15 10:14 o1_mf_1_150_kbldmfcs_.arc
-rw-r----- 1 oracle oinstall 11264  6月 15 10:15 o1_mf_1_151_kbldo876_.arc
-rw-r----- 1 oracle oinstall 36864  6月 15 10:16 o1_mf_1_152_kbldpr31_.arc
-rw-r----- 1 oracle oinstall  3072  6月 15 10:20 o1_mf_1_153_kbldz2j8_.arc
-rw-r----- 1 oracle oinstall 11264  6月 15 10:21 o1_mf_1_154_kblf0kvp_.arc
[oracle@ORA19-DG 2022_06_15]$

無事に高速リカバリ領域配下の
/home/oracle/db_recovery/ORCL/archivelog/2022_06_15
にアーカイブ・ログが出力されていますね！

また、アーカイブ・ログ用のディレクトリに格納されています。
「高速リカバリ領域について」でご説明した通り、高速リカバリ領域による自動的なディレクトリ分けもしっかり機能していますね！

ところが、このままアーカイブ・ログを出力させ続けるとテーブルの更新がフリーズしてしまいました。

・・・・原因を確認していきましょう。

原因特定のため、DBのアラートログを確認すると、下記のようなエラーが出力されていました。

ORA-19809: リカバリ・ファイルの制限を超えています
ORA-19804: 179432448バイトのディスク領域を6442450944バイト制限から再利用できません

高速リカバリ領域が足りないと怒られています…

さらに高速リカバリ領域のサイズを確認してみると…

[oracle@ORA19-DG 2022_06_15]$ ls -ltr /home/oracle/db_recovery/ORCL/archivelog/2022_06_15
合計 709244
-rw-r----- 1 oracle oinstall     14336  6月 15 10:14 o1_mf_1_150_kbldmfcs_.arc
-rw-r----- 1 oracle oinstall     11264  6月 15 10:15 o1_mf_1_151_kbldo876_.arc
-rw-r----- 1 oracle oinstall     36864  6月 15 10:16 o1_mf_1_152_kbldpr31_.arc
-rw-r----- 1 oracle oinstall      3072  6月 15 10:20 o1_mf_1_153_kbldz2j8_.arc
-rw-r----- 1 oracle oinstall     11264  6月 15 10:21 o1_mf_1_154_kblf0kvp_.arc
-rw-r----- 1 oracle oinstall 178147840  6月 15 11:28 o1_mf_1_155_kbljz0d4_.arc
-rw-r----- 1 oracle oinstall 179224064  6月 15 11:29 o1_mf_1_156_kblk0mm0_.arc
-rw-r----- 1 oracle oinstall 183022080  6月 15 11:30 o1_mf_1_157_kblk26l5_.arc
-rw-r----- 1 oracle oinstall 185780736  6月 15 11:31 o1_mf_1_158_kblk3zp7_.arc 
[oracle@ORA19-DG 2022_06_15]$ cd ..
・
【略】
・
[oracle@ORA19-DG db_recovery]$ pwd
/home/oracle/db_recovery
[oracle@ORA19-DG db_recovery]$ du -sh
6.0G	.
[oracle@ORA19-DG db_recovery]$

あ、高速リカバリ領域のサイズが6.0GB（6144MB）になっています。

高速リカバリ領域のサイズは6144MBに設定しているので、もう領域のサイズが足りません。
これらのことから更新処理がフリーズした原因は
高速リカバリ領域のサイズが足りなくなり、アーカイブ・ログが出力できなくなったためだとわかります。

その後、高速リカバリ領域のサイズを大きくして、高速リカバリ領域を空けるとフリーズした更新が無事に完了し、アーカイブ・ログが出力されました。

アーカイブ・ログの保存ポリシー

上記のように高速リカバリ領域が溢れてしまい、アーカイブ・ログが出力できなくなるとDBの更新がフリーズしてしまいます。

DBAとしては絶対に引き起こしてはいけないDB障害の発生です…
そうならないためにもアーカイブ・ログの管理が必要となってきます。

とはいえ、よく遭遇する障害でもありますので、
事象が起きたときは冷静かつ速やかに対処すれば大丈夫です。

アーカイブ・ログにも保存ポリシーが存在します。

そして、高速リカバリ領域に存在するアーカイブ・ログは
保存ポリシーに則り自動的に削除されます。

その設定方法についてご紹介します。

アーカイブ・ログの保存ポリシーは RMAN パラメータの
ARCHIVELOG DELETION POLICYに設定します。

このパラメータの詳細はご利用中のバージョンに該当するOracleDBのマニュアルをご参照ください。
参考として下記にOracleDB 21c のマニュアルを紹介します。
「バックアップとリカバリのリファレンス」

今回の検証ではデフォルトの「TO NONE」に設定しています。

RMAN> show all;
リカバリ・カタログのかわりにターゲット・データベース制御ファイルを使用しています
db_unique_name ORCLのデータベースにおけるRMAN構成パラメータ:
・
【略】
・
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default

詳細はマニュアルをご確認頂きたいのですが、こちらの設定でアーカイブ・ログが削除される条件は下記の2つの場合で別れます。

アーカイブ・ログのリモート宛先が構成されている場合
アーカイブ・ログのリモート宛先が構成されていない場合

今回はリモート宛先を構成しておりませんので、後者の場合について見てみましょう！

アーカイブ・ログの自動削除

さて、マニュアルを要約すると、リモート宛先が構成されていない場合のアーカイブ・ログは下記の2つのいずれかに当てはまった場合に自動削除されます。

アーカイブ・ログがディスクまたはSBT (システム・バックアップ・テープ)にバックアップされている。
アーカイブ・ログがフラッシュバックデータベースや保証付きリストアポイントへの復元で必要とされなくなった。

では先ほど出力したアーカイブ・ログの RMAN バックアップを取得することで、アーカイブ・ログの自動削除が行われるかを見ていきましょう！

下記の「backup database plus archivelog;」でデータファイルと共にアーカイブ・ログのバックアップを取得しています。

RMAN> backup database plus archivelog;
backupを2022/06/15 11:38:01で開始しています
・
【略】
・
Control File and SPFILE Autobackupを2022/06/15 11:39:00で開始しています
ピース・ハンドル=/home/oracle/db_recovery/ORCL/autobackup/2022_06_15/o1_mf_s_1107430740_kblkl4wx_.bkp コメント=NONE
Control File and SPFILE Autobackupを2022/06/15 11:39:01で終了しました

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

早速、先ほどと同様にテーブルを更新させますと、今度はフリーズしませんでした！

高速リカバリ領域を確認してみると・・・

[oracle@ORA19-DG 2022_06_15]$ ls -ltr /home/oracle/db_recovery/ORCL/archivelog/2022_06_15
合計 669656
-rw-r----- 1 oracle oinstall 183022080  6月 15 11:30 o1_mf_1_157_kblk26l5_.arc
-rw-r----- 1 oracle oinstall 185780736  6月 15 11:31 o1_mf_1_158_kblk3zp7_.arc
-rw-r----- 1 oracle oinstall 137357312  6月 15 11:38 o1_mf_1_159_kblkj9z6_.arc
-rw-r----- 1 oracle oinstall     76288  6月 15 11:38 o1_mf_1_160_kblkl2xl_.arc
-rw-r----- 1 oracle oinstall 179480064  6月 15 11:56 o1_mf_1_161_kblllx0g_.arc
[oracle@ORA19-DG 2022_06_15]$

お分かりいただけますでしょうか？

6月15日11時29分より前のアーカイブ・ログが自動的に削除されていますね。
無事にアーカイブ・ログが自動的に削除されることを確認できました！

また、11時56分に今回の更新によって出力されたアーカイブ・ログも確認できます。
※11時38分のアーカイブ・ログは先ほどのDB障害復旧時に出力されたファイルです。

まとめ

本記事では高速リカバリ領域のアーカイブ・ログの管理についてご紹介致しました。
今回の内容をまとめさせて頂きます。

アーカイブ・ログの保存ポリシーは RMAN パラメータの下記で設定します。

ARCHIVELOG DELETION POLICY

ARCHIVELOG DELETION POLICYを「TO NONE」に設定した場合、アーカイブ・ログが自動削除される条件は下記の2つの場合に分かれます。

アーカイブ・ログのリモート宛先が構成されている場合
アーカイブ・ログのリモート宛先が構成されていない場合

アーカイブ・ログのリモート宛先が構成されていない場合、アーカイブ・ログは下記のいずれかの条件を満たした時に自動削除されます。

アーカイブ・ログがディスクまたはSBT (システム・バックアップ・テープ)にバックアップされている。
アーカイブ・ログがフラッシュバックデータベースや保証付きリストアポイントへの復元で必要とされなくなった。

最後となりますが、記事にもございます通り
容量不足でアーカイブ・ログが出力できなくなった場合にDBがフリーズするというクリティカルな障害が発生します。

アーカイブ・ログは、今回ご紹介させて頂いたアーカイブ・ログの自動削除だけではなく
日頃から高速リカバリ領域の空き領域監視を行うことをおススメします。

領域監視をしておくことで、予期せぬ多くの更新処理により突然高速リカバリ領域の空き領域が少なくなって来た際に、手動でバックアップを行い、アーカイブ・ログを自動削除させることや、アーカイブ・ログを別な場所へ緊急退避させることでDB障害を未然に防ぐことも可能となります。

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

※高速リカバリ領域の使用状況は「V$RECOVERY_FILE_DEST」で確認可能です。

さいごに

さすが普段からお客様のシステムの運用・保守をしているだけありますね。
当社には今回の執筆社員をはじめとした優秀な技術者が複数名おります。

Oracle DBをはじめインフラ全般でお困りの際はお気軽にこちらまで連絡くださいませ。

サービス一覧はこちら！
掲載されていないことでも柔軟に問い合わせください！

投稿者プロフィール

DBひとりでできるもん運営チーム

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