MENU
癒しと創作をまぜこぜに
  1. ホーム
  2. Database
  3. RMANのCONFIGUREはスクリプトで実行しても残る？ コマンドファイル（@）実行後のSHOW ALLで確かめる

RMANのCONFIGUREはスクリプトで実行しても残る？ コマンドファイル（@）実行後のSHOW ALLで確かめる

Database
「スクリプトを閉じても、設定は残る」を、画面の前で気づきを得た表情と、残り続ける光のイメージ

こんにちは、おうどんです🍜

（会話は説明用に作ったものです）

バックアップ用のシェルスクリプトを読んでいたら、こんな行がありました。

rman target / @${rman_sample}

一時ファイルに RMAN のコマンドを書き込んで、それを RMAN に渡して実行する。
よくある作りです。
その一時ファイルの中身はこう。

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET;
CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2G;
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO SBT;

後輩くん「スクリプトの中で設定してるだけだから、終わったら元に戻りますよね？」

おうどん「……戻る、のかな？」

正直に言うと、おうどんもここで手が止まりました。

CONFIGURE が永続設定なのは知っています。
RMAN のプロンプトで打てば残る。それは当たり前。
でも、一時ファイルに書いて、スクリプトから流して、ファイルも消して、それでも残るのか？

調べてみると、「CONFIGURE は永続設定です」と書いたページはたくさんあります。
ところが「ファイルを渡して流しても残ります」と書いたページは、ほとんど見つかりませんでした。

自分で試すしかないやつだ、これ。

というわけで、公式ドキュメントの根拠と、実際に試した結果をまとめます。

目次

結論：ファイルで渡しても、CONFIGURE は制御ファイルに残る

先に答えです。
スクリプトが終わっても、元の値には戻りません。

うどん屋さんでたとえると、CONFIGURE は「壁のお品書きを書き換える」コマンドです。
注文を口で言っても、メモに書いて店員さんに渡しても、書き換えたお品書きは閉店後もそのまま。
次の日に来たお客さんも、新しいお品書きを見ることになります。

後輩くん「メモを捨てたら、お品書きも元に戻りません？」

戻りません。メモはただの伝言なので。

根拠は Oracle Database 19c の公式リファレンスです。
CONFIGURE のページには、こう書かれています。

A configuration is in effect for any RMAN session on this database until the configuration is explicitly cleared or changed.

明示的に CLEAR するか変更するまで、その DB のどの RMAN セッションにも効く、という意味です。
保存先についても、同じページの Usage Notes に書かれています。

The CONFIGURE command always stores a configuration for a target database in the target database control file.

設定はターゲット DB の制御ファイル（DB の構成情報を持つ大事なファイル）に保存されます。
リカバリ・カタログ（バックアップの情報を別の DB で管理するしくみ）を使っている場合は、カタログにも保存されます。

では、ファイルで渡した場合はどうか。
RMAN コマンドのリファレンスの CMDFILE の説明に、答えがあります（@ は CMDFILE と同じ扱いです）。

The contents of the command file are identical to commands entered at the RMAN prompt.

コマンドファイルの中身は、プロンプトで打ったコマンドと同じ。
つまり、ファイルの中の CONFIGURE も、プロンプトで打った CONFIGURE と同じように制御ファイルに書かれます。

日本語版の「バックアップおよびリカバリ・ユーザーズ・ガイド」には、さらに直接的な使い方まで載っています。
SHOW ALL の出力をテキスト・ファイルに保存しておけば、「このコマンド・ファイルを使用して同じまたは別のデータベースに構成を再作成することができます」。

ファイルで流して構成を作り直せる、と Oracle 自身が案内しているわけです。
ファイル経由の CONFIGURE が残らなかったら、この使い方は成り立ちません。

おうどん「公式が、お品書きの写しを取っておけって言ってる」

後輩くん「写しがあれば、別の店でも同じお品書きにできますね」

それ、のれん分けです。

実際に確かめた：変更前 → スクリプト実行 → 別セッションのSHOW ALL

公式の根拠だけだと、なんとなく落ち着かないので、試しました。
今回の検証環境は Oracle Database 19c 19.3、シングルインスタンス・CDB 構成、リカバリ・カタログなし（制御ファイルだけ）です。掲載する bash スクリプトは今回の検証環境で実行したもので、Linux の bash では未実行です。

流す6行は、19c の「バックアップおよびリカバリ・ユーザーズ・ガイド」第5章（RMAN環境の構成）に載っている CONFIGURE の例から選びました。
保存期間、バックアップの最適化、制御ファイルの自動バックアップ、圧縮、ピースの最大サイズ、アーカイブログの削除ポリシー。お品書きで言えば、定番メニューを一通りです。

変更前

まず、何も変えていない状態で SHOW ALL を見ます。

RMAN configuration parameters for database with db_unique_name CDB19 are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default

SHOW ALL の出力から、このあとのスクリプトと同じ grep で、関係する行と先頭の行だけを抜き出しています。
末尾の # default は「初期値のまま」という印です。
CONTROLFILE AUTOBACKUP ON は、19c では最初から ON になっていますね。ここ、あとで効いてきます。

スクリプトで CONFIGURE を流す

次に、冒頭と同じ形のスクリプトを用意しました。
一時ファイルを作って CONFIGURE を書き込み、rman target / @一時ファイル で実行します。
終わったら、別の RMAN セッションを起動して SHOW ALL を確かめます。

#!/bin/bash
# RMAN の永続設定をコマンドファイルで変えて、別セッションで残ったかを確かめる
set -u

work_dir=${TMPDIR:-/tmp}
rman_sample=$(mktemp "$work_dir/rman_cmd.XXXXXX") || exit 1
log_file="$work_dir/rman_configure_$(date +%Y%m%d%H%M%S).log"
trap 'rm -f "$rman_sample"' EXIT

cat > "$rman_sample" <<'EOF'
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET;
CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2G;
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO SBT;
EOF

rman target / @"$rman_sample" log="$log_file"
rc=$?
if [ "$rc" -ne 0 ]; then
  echo "RMAN が失敗しました（exit=$rc）。CONFIGURE は1つも反映されていない可能性があります。ログ: $log_file" >&2
  exit "$rc"
fi
echo "RMAN 正常終了（exit=$rc）。ログ: $log_file"

# 別セッションで SHOW ALL を実行し、接続先と設定を確かめる
rman target / <<'EOF' | grep -E 'db_unique_name|RETENTION POLICY|BACKUP OPTIMIZATION|AUTOBACKUP ON|DEVICE TYPE DISK|ARCHIVELOG DELETION POLICY'
SHOW ALL;
EXIT;
EOF

ORACLE_HOME・ORACLE_SID・PATH は、実行前に設定してある前提です。
一時ファイルは、スクリプトが終わると trap で消えます。

実行結果はこうなりました。

RMAN> 2> 3> 4> 5> 6> 7> RMAN 正常終了（exit=0）。ログ: <作業ディレクトリ>/rman_configure_<日時>.log
RMAN configuration parameters for database with db_unique_name CDB19 are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 1;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2 G;
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO 'SBT_TAPE';

ログのパスと日時を伏せています。

別セッションの SHOW ALL で、6つとも新しい値になっていて、# default も消えています。
流していない行（AUTOBACKUP FORMAT や BACKUP COPIES）には、# default が付いたままです。
この時点では一時ファイルはまだあり、SHOW ALL のあと、スクリプト終了時の trap で削除されます。設定の保存先は一時ファイルではなく、DB の制御ファイルです。

後輩くん「このあとファイルを消しても、残るんですね……」

RMAN「お品書きは、もう壁に書きましたので」

もうひとつ見てほしいのが、CONFIGURE CONTROLFILE AUTOBACKUP ON; の行です。
もともと ON だったので、値は何も変わっていません。
それでも # default が消えました。
# default が付いていない行は「初期値から変わった行」ではなく、「誰かが明示的に CONFIGURE した行」なんです。

後輩くん「同じ値を書き直しただけなのに、印だけ消えるんですね」

おうどん「お品書きの『かけうどん 300円』を、300円のまま書き直した感じ。値段は同じでも、書き直した跡は残る」

先頭の RMAN> 2> 3> 4> 5> 6> 7> は、log= を付けても画面に出てきた入力の行番号です。今回の検証環境ではこう表示されました。気にしなくて大丈夫です。

ログファイルの中身も見ておきます（RMAN の起動時のあいさつ部分は省略しています）。

RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
2> CONFIGURE BACKUP OPTIMIZATION ON;
3> CONFIGURE CONTROLFILE AUTOBACKUP ON;
4> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET;
5> CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2G;
6> CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO SBT;
7> 
using target database control file instead of recovery catalog
new RMAN configuration parameters:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
new RMAN configuration parameters are successfully stored

new RMAN configuration parameters:
CONFIGURE BACKUP OPTIMIZATION ON;
new RMAN configuration parameters are successfully stored

new RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
new RMAN configuration parameters are successfully stored

new RMAN configuration parameters:
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 1;
new RMAN configuration parameters are successfully stored

new RMAN configuration parameters:
CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2 G;
new RMAN configuration parameters are successfully stored

new RMAN configuration parameters:
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO 'SBT_TAPE';
new RMAN configuration parameters are successfully stored

Recovery Manager complete.

successfully stored（保存しました）が6回出ています。

よく見ると、書いたとおりの形で保存されていない行があります。

スクリプトに書いた形保存された形（SHOW ALL の表示）
BACKUP TYPE TO COMPRESSED BACKUPSETBACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 1
MAXPIECESIZE 2GMAXPIECESIZE 2 G
TO SBTTO 'SBT_TAPE'

RMAN が、省略された部分を補ったり、書き方をそろえたりしてから保存しているようです（今回の検証環境での表示です）。

おうどん「2G で注文したのに、伝票には 2 G って書かれてる」

空白ひとつでも、grep で文字どおりに探すと見つからなくなります。
SHOW ALL の結果をスクリプトで照合するなら、書いた形ではなく、保存された形で比べてください。

再起動しても残るか

念のため、DB インスタンスを SHUTDOWN IMMEDIATE → STARTUP で再起動してから、もう一度見ました。
結果は同じで、6つとも残っていました。
メモリの上だけの話ではなく、制御ファイルに書かれていることが分かります。

🔰 ここまで読めば今日から困らない

  • スクリプト（コマンドファイル）で流した CONFIGURE も、終わったあとも残ります。元の値には戻りません
  • 確かめるときは、別のセッションで SHOW ALL を実行し、# default が付いていない行を見ます。その行は、明示的に設定された項目です。値そのものは初期値と同じ場合もあります
  • そのジョブの間だけ効かせたいなら、CONFIGURE ではなく SET やコマンドのオプションを使います（次の章）

ここから先は中級者向け。読み飛ばしてもOKです。

CONFIGUREとSETの違い：お品書きの書き換えか、その場の注文か

CONFIGURE がお品書きの書き換えなら、SET は「今日だけ、つゆ少なめで」という、その場の注文です。

19c の SET のリファレンスの Purpose には、こうあります。

Use the SET command to control RMAN behavior within a job or session. Use CONFIGURE to configure options that persist across sessions.

SET はジョブかセッションの中だけ。
セッションを越えて残したいなら CONFIGURE。
効く範囲は、どこで SET を実行したかで変わります。

CONFIGURESET（RMAN のプロンプト）SET（RUN ブロックの中）
効く範囲その DB のすべての RMAN セッションRMAN を終了するまでRUN ブロックが終わるまで
保存先制御ファイル（カタログを使うならカタログにも）保存されない保存されない
元に戻すにはCONFIGURE ... CLEARRMAN を終了するブロックが終わると戻る
コマンドファイルの中で使うと同じ（残る）そのファイルの実行が終わるまで同じ

コマンドファイルの中で RUN の外に書いた SET は、そのファイルの実行（RMAN の起動から終了まで）の間だけ効きます。
コマンドファイルを OS のコマンドラインから渡した場合、RMAN はファイルの最後まで実行したら終了するからです。

後輩くん「じゃあ、全部 SET で書けば安全ですね！」

おうどん「つゆ少なめ、ネギ多め、削除ポリシー変更で」

店員さん「最後のだけ、うちの店では口頭で受けてないんです」

SET で指定できる項目は決まっています。
19c の SET のリファレンスを見ても、アーカイブログの削除ポリシーとバックアップの最適化を一時的に変える項目はありませんでした。

その実行だけ変えたいときの書き方は、項目ごとにこうなります。

  • バックアップの最適化：BACKUP コマンドに FORCE を付けると、その BACKUP だけ最適化を無視します。19c の BACKUP のリファレンスには「even if CONFIGURE BACKUP OPTIMIZATION is set to ON, RMAN backs up all specified files」とあります
  • チャネル：RUN ブロックの中で ALLOCATE CHANNEL すると、そのジョブでは設定済みのチャネルが使われません
  • コピー数・圧縮・暗号化など：SET BACKUP COPIES、SET COMPRESSION ALGORITHM、SET ENCRYPTION などがあります
  • アーカイブログの削除ポリシー：一時的に変える SET はありません。DB ごとに正しい値を決めておく永続設定として扱います

削除ポリシーは、お品書きの中でも「閉店時間」みたいなものです。
今日だけ変えます、とはいかない。

変えた設定を元に戻す

スクリプトで変えてしまった設定を初期値に戻すときは、CLEAR を使います。

CONFIGURE RETENTION POLICY CLEAR;
CONFIGURE BACKUP OPTIMIZATION CLEAR;
CONFIGURE CONTROLFILE AUTOBACKUP CLEAR;
CONFIGURE DEVICE TYPE DISK CLEAR;
CONFIGURE CHANNEL DEVICE TYPE DISK CLEAR;
CONFIGURE ARCHIVELOG DELETION POLICY CLEAR;
  • 前提：ターゲット DB に接続できること（マウントまたはオープン）
  • 影響範囲：その DB の、以降のすべての RMAN ジョブ（ほかのバックアップジョブや手作業の RMAN も含む）
  • 反映時期：実行した直後から
  • 変更後の確認：別セッションで SHOW ALL を実行し、# default が付いていること
  • 戻し方：変更前の SHOW ALL の行（CONFIGURE ...;）をそのまま流し直す

今回の検証環境でもこの6行をコマンドファイルで流し、SHOW ALL が全部 # default に戻ったことを確かめました。
ほとんどの行は old RMAN configuration parameters: のあとに RMAN configuration parameters are successfully reset to default value と出ましたが、チャネルの行だけは old RMAN configuration parameters are successfully deleted でした。チャネルの設定は初期値に戻すというより、消す扱いのようです。

CLEAR は「初期値に戻す」です。
「スクリプトを流す前の値に戻す」ではありません。
流す前から初期値以外だったなら、変更前の SHOW ALL を取っておかないと戻せません。

白紙に戻す消しゴムはあるけど、昨日のお品書きに戻す消しゴムはない。

1行のタイプミスで、正しいCONFIGUREも流れない

ここ、地味に大事です。

さっきのスクリプトの2行目だけ、わざと綴りを間違えてみました。

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
CONFIGUR BACKUP OPTIMIZATION ON;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET;
CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2G;
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO SBT;

間違えたのは2行目だけなので、ほかの5行は反映されそうな気がします。
結果はこうでした（変更前の状態から実行しています）。

RMAN> 2> RMAN が失敗しました（exit=1）。CONFIGURE は1つも反映されていない可能性があります。ログ: <作業ディレクトリ>/rman_configure_<日時>.log

ログのパスと日時を伏せています。

ログにはこう出ていました（長い RMAN-01009 の行とファイルのパスは省略しています）。

RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;
2> CONFIGUR 
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00558: error encountered while parsing input commands
RMAN-01008: the bad identifier was: CONFIGUR
RMAN-01007: at line 2 column 1 file: <一時ファイル>

そして、別セッションの SHOW ALL（同じ grep で抜き出しています）。

RMAN configuration parameters for database with db_unique_name CDB19 are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default

正しく書いたほかの5行も、反映されていません。

理由は、RMAN コマンドのリファレンスの CMDFILE の説明に書かれています。

Parses and compiles all RMAN commands in a file and then sequentially executes each command in the file. RMAN exits if it encounters a syntax error during the parse phase or if it encounters a runtime error during the execution phase.

RMAN は、ファイルを渡されると、まず全部の行の構文をチェックしてから、上から順に実行します。
構文チェックの段階でエラーがあると、1行も実行せずに終了します。

後輩くん「店員さん、注文メモの2行目が読めないからって、1行目のかけうどんまで出さないんですか？」

店員さん「全部読めてから作り始める店なので」

融通は利かないけれど、半分だけ設定が変わる事故は起きにくい。
そう考えると、悪くない作りです。

ただし、実行の途中で起きたエラー（実行時エラー）は別です。
リファレンスにあるとおり、その時点で終了するので、それより前の行は実行済みになります。
構文エラーなら全部なし、実行時エラーなら途中まで。この2つは分けて考えます。

注文メモを読む前に断られるか、作っている途中で鍋が壊れるか、の違いです。
鍋が壊れても、それまでに出したうどんは戻ってきません。もう食べられています。

なお、rman target / で起動してから、RMAN のプロンプトで @ファイル と打った場合は、扱いが違います。
同じ CMDFILE の説明に、プロンプトから実行したときは1つのジョブとして扱わず、1行ずつ読んで実行する、と注意書きがあります。
冒頭のスクリプトのように OS のコマンドラインで渡す形とは、エラー時の動きが変わりうるので注意してください（プロンプトから実行する形は、今回は試していません）。

スクリプトの終了コード（$?）を見ていれば、この失敗には気づけます。
見ていないと、「スクリプトは毎日動いているのに、設定が変わっていない」という謎が生まれます。

SHOW ALLがスクリプトの値と違うときに見るところ

「スクリプトは動いているはずなのに、SHOW ALL の値がスクリプトと違う」。
そんなときに疑う場所を、確認しやすい順に並べます。
ここに挙げるのは仕様から考えられる候補で、どれが原因かは環境ごとに確かめる必要があります。

1. そもそも別の DB を見ていないか

SHOW ALL の1行目を見ます。

RMAN configuration parameters for database with db_unique_name CDB19 are:

この db_unique_name が、スクリプトの対象の DB かどうか。
cron（決まった時刻にコマンドを動かす Linux のしくみ）から動かすスクリプトは、手で実行するときと環境変数が違うことがあります。
ORACLE_SID が違えば、rman target / がつながる DB も違います。
Data Guard なら、スタンバイ側を見ていた、スイッチオーバー（プライマリとスタンバイの役割の入れ替え）のあとで見ている DB が入れ替わっていた、ということもありえます。

お品書きは正しく書き換えたのに、見ていたのは隣の支店の壁だった、というパターンです。
じっくり見れば見るほど、隣の支店にだけ詳しくなっていきます。

2. CONFIGURE まで実行されていたか

  • 構文エラーが1行でもあれば、ファイル全体が実行されません（前の章）
  • 接続に失敗していれば、もちろん何も変わりません
  • 一時ファイルの作り方もあやしい場所です。たとえばヒアドキュメント（<<EOF でファイルに書き込む書き方）の区切りをクォートしないと、$ で始まる文字が変数として展開されます

ここはスクリプトの終了コードと、log= で残したログを見れば分かります。

3. あとから上書きされていないか

  • 別のスクリプトや手作業で、CONFIGURE や CLEAR が実行された
  • リカバリ・カタログを使っていて、カタログ側で CONFIGURE ... FOR DB_UNIQUE_NAME が設定されていた

2つ目は分かりにくいので、上級者向けの章で説明します。

4. 制御ファイルが入れ替わっていないか

設定は制御ファイルにあるので、制御ファイルが変われば設定も変わります。
制御ファイルの再作成（CREATE CONTROLFILE）や、古いバックアップからのリストアのあとは、設定が変わっている可能性があります。
これも上級者向けの章で、実際の様子を見ます。

スクリプトに残しておくと切り分けが楽なもの

  • RMAN の終了コード
  • log= で出したログ
  • 実行直後の SHOW ALL（db_unique_name の行も含めて）

冒頭のスクリプトは、設定変更時の RMAN の終了コードと、別セッションの SHOW ALL を画面に表示し、設定変更時のログをファイルに保存する形です。終了コードと SHOW ALL も記録に残すなら、スクリプト全体の出力も保存してください。
未来のおうどんが困らないように、です。たぶん困るので。

なお、最後の SHOW ALL は grep に渡しているため、パイプラインの終了コードだけでは RMAN 自体の成功を判定できません。自動処理に使う場合は、bash の PIPESTATUS[0] などで RMAN 側の終了コードも確認してください。

ここから先は上級者向け。読み飛ばしてもOKです。

設定はどこにある？ v$rman_configurationと制御ファイルのトレース

SHOW ALL 以外にも、SQL*Plus から設定を見る方法があります。
19c のリファレンスによると、V$RMAN_CONFIGURATION は RMAN の永続設定を一覧にしたビューです。

スクリプトで CONFIGURE を流したあと、SQL*Plus で見るとこうなりました。

select conf#, name, value, con_id from v$rman_configuration order by conf#;
     CONF# NAME                                     VALUE                                                            CON_ID
---------- ---------------------------------------- ------------------------------------------------------------ ----------
         1 RETENTION POLICY                         TO RECOVERY WINDOW OF 7 DAYS                                          0
         2 BACKUP OPTIMIZATION                      ON                                                                    0
         3 CONTROLFILE AUTOBACKUP                   ON                                                                    0
         4 DEVICE TYPE                              DISK BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 1                0
         5 CHANNEL                                  DEVICE TYPE DISK MAXPIECESIZE 2 G                                     0
         6 ARCHIVELOG DELETION POLICY               TO BACKED UP 2 TIMES TO 'SBT_TAPE'                                    0

6 rows selected.

列の間の空白は読みやすく整えています。

変更前は no rows selected（0行）でした。
このビューでは、明示的に保存された設定を確認できます。初期値と同じ値を明示的に設定した場合もあるので、初期値との差分一覧とは限りません。
実際、値の変わっていない CONTROLFILE AUTOBACKUP ON も3行目に入っています。
なお、リファレンスによると CONFIGURE SNAPSHOT CONTROLFILE はこのビューには出ません（EXCLUDE と AUXNAME も別のビュー）。

後輩くん「0行って、設定が全部消えたってことですか？」

おうどん「今回の6項目は、SHOW ALL でも初期値と確認できているよ。ビューに出ない設定もあるから、0行だけで全部を判断しないでね」

制御ファイルのトレースにも、設定が書かれている

制御ファイルの中身を SQL の形で書き出す ALTER DATABASE BACKUP CONTROLFILE TO TRACE を実行して、出てきたファイルを見ました。

-- Configure RMAN configuration record 1
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('RETENTION POLICY','TO RECOVERY WINDOW OF 7 DAYS');
-- Configure RMAN configuration record 2
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('BACKUP OPTIMIZATION','ON');
-- Configure RMAN configuration record 3
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('CONTROLFILE AUTOBACKUP','ON');
-- Configure RMAN configuration record 4
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('DEVICE TYPE','DISK BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 1');
-- Configure RMAN configuration record 5
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('CHANNEL','DEVICE TYPE DISK MAXPIECESIZE 2 G');
-- Configure RMAN configuration record 6
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('ARCHIVELOG DELETION POLICY','TO BACKED UP 2 TIMES TO ''SBT_TAPE''');

トレースの中から、RMAN の設定に関係する行だけ抜き出しています。

トレースには、制御ファイルを作り直すための CREATE CONTROLFILE の手順が入っていて、その中に RMAN の設定を書き戻す行がありました。
つまり、制御ファイルを作り直すとき、この行を流さないと RMAN の設定は戻らない、ということです。

お品書きの壁ごと建て替えるなら、写しを貼り直す必要がある。
スクリプトの CONFIGURE を「流しっぱなし」にしていると、この写しの存在も忘れがちです。

カタログの設定が、制御ファイルを上書きすることがある

ここからはリカバリ・カタログを使う環境の話です。今回の検証環境にはカタログがないので、公式ドキュメントで確かめた範囲だけ書きます。

19c の CONFIGURE のリファレンスによると、FOR DB_UNIQUE_NAME を付けた CONFIGURE は、カタログの設定を直接書き換えます。
そして、RMAN がその DB に TARGET として接続したとき、カタログの設定で制御ファイルが更新されます。

When RMAN connects as TARGET to a database whose configurations were changed with FOR DB_UNIQUE_NAME, RMAN updates the mounted control file with the configuration metadata from the recovery catalog.

スクリプトで制御ファイルの設定を変えても、カタログ側に別の値があれば、次に接続したときに書き戻されることがあるわけです。
本店のお品書きが、支店の壁に貼り直される感じです。

Data GuardではDBごとに別のお品書き

Data Guard（本番 DB の変更をスタンバイ DB に送り続けて、障害に備えるしくみ）の環境では、RMAN の設定はプライマリとスタンバイで別々に持てます。
今回の検証環境には Data Guard がないので、ここも公式ドキュメントの範囲です。

19c の CONFIGURE のリファレンスには、こうあります。

Thus, the primary and standby databases can have different channel configurations, control file autobackup locations, and so on.

ただし、保存ポリシー（RETENTION POLICY）、表領域の除外（EXCLUDE）、AUXNAME の3つは例外として、DB ごとには持てないと書かれています。

19c の Data Guard の管理ガイドでは、アーカイブログの削除ポリシーの推奨も、DB の役割ごとに分かれています。

DB推奨されている削除ポリシーの例
プライマリTO APPLIED ON ALL STANDBY（全部のスタンバイで適用されたら削除してよい）など
バックアップを取るスタンバイBACKED UP n TIMES TO DEVICE TYPE SBT
バックアップを取らないスタンバイTO APPLIED ON ALL STANDBY

同じスクリプトをプライマリでもスタンバイでも流していると、片方には合わない値が入ることがあります。
本店の持ち帰りメニューを、持ち帰りのない支店の壁に貼ってしまうやつです。貼った本人は、だいたい気づいていません。
それぞれの DB で SHOW ALL を見て、その DB の役割に合った値かを確かめてください。

後輩くん「全店舗、同じお品書きでいいじゃないですか」

おうどん「本店は持ち帰りあり、支店は持ち帰りなし、みたいな違いがあるんよ」

RMAN「どちらも、書いたとおりにやります」

まとめ：流したら、残る

冒頭の後輩くんの質問に戻ります。

後輩くん「スクリプトの中で設定してるだけだから、終わったら元に戻りますよね？」

今なら、こう答えられます。

おうどん「戻らない。ファイルで渡しても、お品書きは書き換わったまま」

スクリプトで流した CONFIGURE は、スクリプトが終わっても残ります。
一時ファイルを消しても、RMAN を終了しても、DB を再起動しても。

後輩くん「じゃあ、お店が閉店しても？」

閉店しても、お品書きは壁に残ります。壁ごと建て替えない限り（制御ファイルの再作成のことです）。

だから、スクリプトに CONFIGURE を書くときは、その値が今日からずっとその DB の設定になる、と思って書く。
そのジョブだけでいい設定なら、SET や FORCE のような、その場の注文にする。

まずは、いつも使っている DB で SHOW ALL を1回見てみてください。
# default が付いていない行があったら、それは誰かが明示的に設定した跡です。値が初期値と違うとは限りません。
書き換えたのが過去の自分だったら……そっと心の中で謝っておきましょう🍜

参考資料

2026年9月時点の内容です。

Database
CONFIGURE Data Guard Oracle Oracle 19c RMAN SHOW ALL シェルスクリプト バックアップ
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

この記事を書いた人

おうどんのアバター おうどん

おうどん｜癒しと創作をたのしむ雑食クリエイター
写経アプリやクレイセラピー、優しい和風デザインがすき。
ZARDと刀剣と文字に癒されて、今はアプリ作ってます。

関連記事

コメント

コメントする

目次