こんにちは、おうどんです🍜
新人さん「LOG_ARCHIVE_DEST_2 の転送先、変えておきました！ SHOW PARAMETER で見たら、ちゃんと新しい値になってます。完了です！」
おうどん「ありがとう。で、REDO は届いてる？」
新人さん「……SHOW PARAMETER に、届いたかどうかの列ってありましたっけ」
おうどん「ないね」
（会話は説明用の架空の場面です）
出前のうどん屋でたとえます。
SHOW PARAMETER で見えるのは、壁に貼った出前の伝票です。
住所はちゃんと書いてある。字もきれい。
でも、伝票がきれいなことと、うどんがお客さんの家に着いたことは、別の話なんです。
読者「伝票を貼った時点で、出前は終わったことにしたい」
気持ちはわかります。おうどんも、ボタンを押した瞬間に仕事が終わってほしい。
これは、おうどんも「設定を変えたあと、なんで SHOW PARAMETER だけじゃなくて SELECT でも確かめるの？」と迷ったことがある疑問です。
今回は、ローカルの Oracle Database 19c で、存在しない転送先をわざと設定して、どこに何が出るかを確かめました。
今日の結論を先に書いておきます。
- SHOW PARAMETER が見せるのは「設定に何と書いたか」だけ。転送先が使えるかは
V$ARCHIVE_DESTの STATUS・VALID_NOW・ERROR で見る - 存在しない宛先を書いても、
ALTER SYSTEMは成功し、STATUS は VALID になることがある - 実際に REDO を送るまで、ERROR 列には何も出ないことがある。送ったあとにもう一度見る
SHOW PARAMETER が見せているのは、壁の伝票だけ
まずは何も考えずに、転送先を書き換えて SHOW PARAMETER で見てみます。
宛先の nosuch_stby は、どこにも存在しない名前です（tnsnames.ora にもありません）。
alter system set log_archive_dest_2='SERVICE=nosuch_stby ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=nosuch_stby' scope=memory;
show parameter log_archive_dest_2System altered.
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_2 string SERVICE=nosuch_stby ASYNC VALI
D_FOR=(ONLINE_LOGFILES,PRIMARY
_ROLE) DB_UNIQUE_NAME=nosuch_s
tby
log_archive_dest_20 string
log_archive_dest_21 string
log_archive_dest_22 string
log_archive_dest_23 string
log_archive_dest_24 string
log_archive_dest_25 string
log_archive_dest_26 string
log_archive_dest_27 string
log_archive_dest_28 string
log_archive_dest_29 string（今回の検証環境：Oracle Database 19c 19.3、シングルインスタンス・CDB 構成、NOARCHIVELOG。SYSDBA で CDB$ROOT に接続して実行。この記事の出力は、SQL ファイルにまとめて流した実行結果から、区切りに入れた prompt の行を除いて該当部分を抜き出しています）
受付さん（ALTER SYSTEM）「System altered. 伝票、貼っておきました！」
存在しない住所なのに、受付は笑顔です。
伝票はきれいに貼られ、SHOW PARAMETER はそれを正確に読み上げました。どちらも嘘はついていない。
ついでに、出力に気になるところが2つあります。
1つ目は、頼んでいない log_archive_dest_20 〜 29 まで出てきたこと。
SQL*Plus の SHOW コマンドのリファレンスでは、SHOW PARAMETERS のあとに書いた文字列は、その文字列を名前に含むパラメータを表示する、とされています。log_archive_dest_2 を含む名前は、20 〜 29 にもあるわけです。
新人さん「2番だけ頼んだのに、20番台が全員ついてきました」
おうどん「名字が同じだと、呼ばれてもいないのに返事しちゃうタイプ」
2つ目は、値が30文字で折り返されて VALI と D_FOR に割れていること。
SQL*Plus の表示幅の都合なので、値そのものが壊れているわけではありません。ただ、長い値をこの画面でコピーすると、途中に空白や改行がまざった伝票ができあがります。
読者「VALI D_FOR という新しい属性かと思った」
ない。長い値を確かめるときは、V$PARAMETER を列幅を広げて SELECT するほうが安全です。
存在しない宛先でも、STATUS は VALID だった
じゃあ、転送先の状態を見るビューで見てみます。
V$ARCHIVE_DEST のリファレンス（19c）によると、このビューは、いまのインスタンスについて、各転送先の現在の値・モード・状態を表示します。
出前でいえば、厨房の配達ボードです。
select dest_id, status, destination, valid_now, valid_type, valid_role, error
from v$archive_dest
where dest_id = 2; DEST_ID STATUS DESTINATION VALID_NOW VALID_TYPE VALID_ROLE ERROR
---------- --------- -------------------- ---------------- --------------- ------------ --------------------------------------------------
2 VALID nosuch_stby YES ONLINE_LOGFILE PRIMARY_ROLE（実行時は SQL*Plus の COL コマンドで列幅を整えています。COL の行はこのブロックでは省略しました）
STATUS は VALID。VALID_NOW も YES。ERROR は空っぽ。
存在しない住所なのに、配達ボードは全部緑です。
配達ボード「2番、配達の準備OKです！」
おうどん「その住所、地図に載ってないよ」
配達ボード「まだ地図は見ていません！」
元気な返事ですが、言っていることは筋が通っています。
リファレンスでは、STATUS の VALID は「初期化されていて使える状態」、ERROR は「オープンまたはコピーのときのエラー」です。
つまり ERROR は、実際に送ろうとして、はじめて出るもの。今回の検証環境は NOARCHIVELOG（REDO をアーカイブしない運用）なので、そもそも一度も送っていません。送っていなければ、失敗もしない。
読者「一度も出前に行っていない人は、一度も道に迷っていない」
その理屈で、皆勤賞をもらおうとしないでください。
出前に出ていないのに緑。ここが今日いちばん大事なところです。
VALID は「準備ができた」であって、「届いた」ではありません。
存在しないフォルダでも、同じだった
リモートだから見ていないのかな、と思って、ローカルのフォルダ（LOCATION）でも試しました。
alter system set log_archive_dest_3='LOCATION=C:\nosuch_dir_oudon' scope=memory;
select dest_id, status, destination, valid_now, error from v$archive_dest where dest_id = 3;System altered.
DEST_ID STATUS DESTINATION VALID_NOW ERROR
---------- --------- ------------------------ ---------------- --------------------------------------------------
3 VALID C:\nosuch_dir_oudon YES存在しないフォルダでも、今回の検証環境では成功して VALID でした（NOARCHIVELOG で、まだ書き込みに行っていない状態です）。
新人さん「フォルダくらいは見てくれると思ってました」
受付さん「伝票の形は見ました！」
形は見たらしいので、形を崩してみます。
書き方を間違えると、そこは止めてくれる
ASYNC を ASYNCH と書き間違えた場合です。
alter system set log_archive_dest_3='SERVICE=nosuch_stby ASYNCH' scope=memory;alter system set log_archive_dest_3='SERVICE=nosuch_stby ASYNCH' scope=memory
*
ERROR at line 1:
ORA-02097: parameter cannot be modified because specified value is invalid
ORA-16024: parameter LOG_ARCHIVE_DEST_3 cannot be parsedこっちは断られました。ORA-16024 は「パラメータを解析できない」。
受付さんは、伝票の書式は見るけれど、住所が実在するかは見ない。今回の実験からは、そういう受付に見えます。
受付さん「字が読めない伝票はお返しします。読める伝票は、宛先が月でもお預かりします」
月へのお届けは、たぶん REOPEN の間隔（再試行までの秒数）を何回待っても無理です。
V$ARCHIVE_DEST で見る列は STATUS・VALID_NOW・ERROR
配達ボードの見方を整理します。中身は V$ARCHIVE_DEST のリファレンス（19c）の説明を日本語にしたものです。
| 列 | 何がわかるか | 主な値 |
|---|---|---|
| STATUS | 転送先の今の状態 | VALID（初期化済みで使える）、INACTIVE（転送先の情報なし）、DEFERRED（ユーザーが手で無効にした）、ERROR（オープンまたはコピーのときのエラー）、DISABLED（エラーのあと無効）、BAD PARAM（パラメータにエラー）、ALTERNATE（代替先として待機）、FULL（割り当て量を超えた） |
| VALID_NOW | 今のデータベースのロール（プライマリかスタンバイか）で、この転送先が使われるか | YES、WRONG VALID_TYPE、WRONG VALID_ROLE、INACTIVE |
| ERROR | エラーの文面 | 空ならエラーは記録されていない |
| FAIL_DATE | 最後のエラーの日時 | |
| DESTINATION | 送り先（フォルダかサービス名） |
新人さん「STATUS が VALID なら、あとは見なくていいですか？」
おうどん「さっき、存在しない住所で VALID が出たよね」
新人さん「……3列とも見ます」
DEFER にすると、伝票は残って配達だけ止まる
LOG_ARCHIVE_DEST_STATE_2 を DEFER にすると、どう見えるか。
alter system set log_archive_dest_state_2='DEFER' scope=memory;
show parameter log_archive_dest_state_2
select dest_id, status, destination, valid_now, error from v$archive_dest where dest_id = 2;System altered.
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_state_2 string DEFER
log_archive_dest_state_20 string enable
log_archive_dest_state_21 string enable
log_archive_dest_state_22 string enable
log_archive_dest_state_23 string enable
log_archive_dest_state_24 string enable
log_archive_dest_state_25 string enable
log_archive_dest_state_26 string enable
log_archive_dest_state_27 string enable
log_archive_dest_state_28 string enable
log_archive_dest_state_29 string enable
DEST_ID STATUS DESTINATION VALID_NOW ERROR
---------- --------- -------------------- ---------------- --------------------------------------------------
2 DEFERRED nosuch_stby UNKNOWNLOG_ARCHIVE_DEST_STATE_n のリファレンス（19c）では、defer は「転送先の情報と属性は残したまま、再び有効にするまでアーカイブの対象から外す」です。既定値は enable。
ここで怖いのは、LOG_ARCHIVE_DEST_2 だけを SHOW PARAMETER で見ていると、伝票は完璧に見えることです。
配達係が「保留」の札を下げているのは、別のパラメータ（STATE_2）と、配達ボードにしか出てきません。
おうどん「伝票は合ってる。でも配達係は休憩中」
新人さん「休憩の札、伝票の横に貼っておいてほしかったです」
20番台が全員ついてくるくせに、隣の STATE_2 はついてこない。SHOW PARAMETER の部分一致、気が利くのか利かないのか。
WRONG VALID_ROLE は「今のロールでは送らない」
VALID_FOR を STANDBY_ROLE（スタンバイのときだけ使う）に変えてみます。
alter system set log_archive_dest_2='SERVICE=nosuch_stby ASYNC VALID_FOR=(ONLINE_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=nosuch_stby' scope=memory;
select dest_id, status, destination, valid_now, valid_type, valid_role, error from v$archive_dest where dest_id = 2;System altered.
DEST_ID STATUS DESTINATION VALID_NOW VALID_TYPE VALID_ROLE ERROR
---------- --------- -------------------- ---------------- --------------- ------------ --------------------------------------------------
2 VALID nosuch_stby WRONG VALID_ROLE ONLINE_LOGFILE STANDBY_ROLESTATUS は VALID のまま、VALID_NOW が WRONG VALID_ROLE になりました。
リファレンスにも、VALID_FOR=(ONLINE_LOGFILE,STANDBY_ROLE) の転送先がプライマリで動いているときに WRONG VALID_ROLE になる、と例が載っています。
これは間違いではなく、「今は配達しない伝票」です。ロールが切り替わったら使われる予定のもの。
裏を返すと、ロールが切り替わるまで、一度も試されない伝票でもあります。
支店長「本店になったら、この住所に出前します」
おうどん「本店になるまで、誰もその住所に行ったことがないんだよね」
切替のあとにだけ転送エラーが出る、という話は、だいたいここから始まります（切替そのものは今回の検証環境では試していません）。
🔰 ここまで読めば今日から困らない
- SHOW PARAMETER で確かめられるのは「設定に何と書いたか」まで
- 転送先は
V$ARCHIVE_DESTの STATUS・VALID_NOW・ERROR を3つセットで見る - STATUS が VALID でも、まだ一度も送っていないだけかもしれない。REDO が送られたあとに、ERROR と FAIL_DATE をもう一度見る
LOG_ARCHIVE_DEST_STATE_nが DEFER になっていないかも見る
ここから先は中級者向けです。名前解決の確かめ方と、変更作業の確認手順をまとめます。
宛先の名前が引けるかは、サーバーの上で確かめる
SERVICE に書いた名前（ネットサービス名）が引けないと、転送は失敗します。
Data Guard のトラブルシューティング（19c）には、スタンバイに REDO が届かないときは、まず V$ARCHIVE_DEST でエラーを見る、とあります。そのうえで、届かない原因の候補として、次のようなものが並んでいます（抜粋）。
- プライマリの tnsnames.ora で、スタンバイのサービス名が正しく設定されていない
LOG_ARCHIVE_DEST_nに書いたネットサービス名が間違っているLOG_ARCHIVE_DEST_STATE_nが ENABLE になっていない- スタンバイのリスナーが起動していない、スタンバイのインスタンスが起動していない
- スタンバイの転送先をプライマリの SPFILE に追加したが、その変更をまだ有効にしていない
新人さん「つまり、伝票の住所が住所録に載っているか、ですね」
おうどん「そう。しかも、見るのは厨房の住所録。自分のスマホの連絡先じゃない」
住所録（tnsnames.ora）は、データベースが動いているサーバーの Oracle Home 側のものを見ます。手元のパソコンで tnsping が通っても、サーバーの住所録に載っているとは限りません。
tnsping と SQL*Plus で、名前が引けるかを見る
今回の検証環境で、存在しない名前と、存在する名前を tnsping してみました。
tnsping nosuch_stby
tnsping cdb19### tnsping nosuch_stby exit=1
TNS Ping Utility for 64-bit Windows: Version 19.0.0.0.0 - Production on 21-OCT-2026 08:12:32
Copyright (c) 1997, 2019, Oracle. All rights reserved.
Used parameter files:
C:\app\<user>\product\19.0.0\dbhome_1\network\admin\sqlnet.ora
TNS-03505: Failed to resolve name
### tnsping cdb19 exit=0
TNS Ping Utility for 64-bit Windows: Version 19.0.0.0.0 - Production on 21-OCT-2026 08:12:37
Copyright (c) 1997, 2019, Oracle. All rights reserved.
Used parameter files:
C:\app\<user>\product\19.0.0\dbhome_1\network\admin\sqlnet.ora
Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = cdb19)))
OK (20 msec)（Python から tnsping.exe を2回呼び、出力をそのまま並べたものです。### の行は区切りとして Python 側で足した行です。パスの一部を伏せています）
同じ名前で SQL*Plus から接続しようとすると、こうなりました（ユーザー名もパスワードも書かず、名前解決だけで失敗させています）。
sqlplus -S -L /@nosuch_stbyERROR:
ORA-12154: TNS:could not resolve the connect identifier specified
SP2-0751: Unable to connect to Oracle. Exiting SQL*Plustnsping は TNS-03505、SQL*Plus は ORA-12154。言い方は違いますが、どちらも「その名前、住所録にありません」です。
新人さん「じゃあ、tnsping が OK なら転送もOKですね！」
おうどん「玄関のチャイムが鳴っただけで、うどんを受け取ってもらえるかは別」
Net Services 管理者ガイドの接続テストの章（19c）では、tnsping はサービスのリスナーに到達できるかを確かめるもので、データベースが動いているかまでは確かめない、データベースへの接続は SQL*Plus で試す、と書かれています。
リスナーは玄関の受付係。玄関まで行けても、家の人（データベース）が留守かもしれません。
変更作業の確認は、伝票・帳簿・配達ボード・到着の4段
ここまでを、作業手順に落とします。確認用と変更用を分けて書きます。
確認用：今の伝票と帳簿と配達ボードを並べる
V$PARAMETER が「今のインスタンスの伝票」、V$SPPARAMETER が「SPFILE（次の起動で読まれる帳簿）」です。
この2つの違いは SCOPE=MEMORY・SPFILE・BOTH の記事で詳しく書いたので、ここでは並べて見るだけにします。
set lines 200 pages 100
col name for a24
col memory_value for a40
col spfile_value for a20
select p.name,
p.value memory_value,
s.value spfile_value
from v$parameter p
join v$spparameter s on s.name = p.name
where p.name like 'log_archive_dest%'
and (p.ismodified <> 'FALSE' or s.isspecified = 'TRUE')
order by p.name;
col destination for a30
col error for a40
col valid_now for a16
select dest_id, status, valid_now, destination, error, fail_date
from v$archive_dest
where status <> 'INACTIVE'
order by dest_id;今回の検証環境で、LOG_ARCHIVE_DEST_2 を SCOPE=MEMORY だけで変えた状態で実行した結果です。
NAME MEMORY_VALUE SPFILE_VALUE
------------------------ ---------------------------------------- --------------------
log_archive_dest_2 SERVICE=nosuch_stby ASYNC VALID_FOR=(ONL
INE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAM
E=nosuch_stby
DEST_ID STATUS VALID_NOW DESTINATION ERROR FAIL_DATE
---------- --------- ---------------- ------------------------------ ---------------------------------------- ------------------
2 VALID YES nosuch_stbySPFILE_VALUE が空です。今は効いているけれど、帳簿には書いていない。再起動したら、この伝票は消えます。
逆に SCOPE=SPFILE だけで変えると、帳簿には書いてあるのに今は効いていない、という形になります。Data Guard のトラブルシューティングの「SPFILE に追加したが、まだ有効にしていない」は、たぶんこの状態です。
新人さん「今の伝票と帳簿、どっちか片方だけ合ってればいいですよね」
おうどん「片方だけ合ってると、今日か、次の再起動の日か、どっちかに出前が迷子になる」
変更用：変える前に書いておくこと
変更のコマンドは、環境ごとの手順書に従うのが前提です。ここでは、作業メモに書いておきたい項目だけ並べます。
| 項目 | 書いておくこと |
|---|---|
| 前提 | 対象のデータベース（DB_UNIQUE_NAME）・ロール・インスタンス。RAC なら全インスタンスか特定のインスタンスか |
| 変更前の記録 | 上の確認用 SQL の結果（V$PARAMETER・V$SPPARAMETER・V$ARCHIVE_DEST） |
| 変更内容 | ALTER SYSTEM SET log_archive_dest_n = '...' SCOPE = ... の全文と、STATE_n をどうするか |
| 影響範囲 | その転送先に REDO が届かなくなる間、何が守られなくなるか（スタンバイの遅れ、バックアップ先への転送など） |
| 反映時期 | SCOPE=MEMORY・BOTH ならすぐ。SCOPE=SPFILE なら次の起動から |
| 変更後の確認 | 伝票（V$PARAMETER）、帳簿（V$SPPARAMETER）、配達ボード（V$ARCHIVE_DEST）、そして実際に REDO が送られたあとの ERROR・FAIL_DATE と、受け側での受信 |
| 戻し方 | 変更前の値に戻す ALTER SYSTEM SET。SPFILE に書いていなかった値なら ALTER SYSTEM RESET |
読者「伝票を貼った人と、届いたのを確かめる人が、別の日に別の人だったら？」
それが一番危ない。作業メモの最後に「届いたことを、いつ、誰が見るか」まで書いておきます。
いちばん下の「実際に REDO が送られたあと」が、SHOW PARAMETER では絶対に見えないところです。
ログスイッチなどで REDO が送られるタイミングのあとに、配達ボードの ERROR と FAIL_DATE を見る。受け側（スタンバイやバックアップの基盤）でも、届いたことを確かめる。受け側の見方は製品や構成で変わるので、その製品のドキュメントで確認してください（今回の検証環境には受け側がないので、ここは試していません）。
上級者向け：なぜ ALTER SYSTEM は宛先を確かめないのか
ここから先は上級者向け。読み飛ばしてもOKです。
書式の検査と、宛先の検査は別の段階
今回の実験をまとめると、こうでした。
| 試したこと | ALTER SYSTEM | V$ARCHIVE_DEST |
|---|---|---|
| 存在しないサービス名（SERVICE=nosuch_stby） | 成功 | VALID・YES・ERROR なし |
| 存在しないフォルダ（LOCATION=C:\nosuch_dir_oudon） | 成功 | VALID・YES・ERROR なし |
| 属性の書き間違い（ASYNCH） | ORA-02097・ORA-16024 | （変更されない） |
| STATE_2 を DEFER | 成功 | DEFERRED・UNKNOWN |
| VALID_FOR を STANDBY_ROLE | 成功 | VALID・WRONG VALID_ROLE |
（今回の検証環境・NOARCHIVELOG での結果をまとめた表です）
受付さん「書式のチェックは私、配達の成否は出前係です」
おうどん「分業としては正しい。問題は、出前係が出発するまで誰も住所を見ないこと」
リファレンスの ERROR の定義が「オープンまたはコピーのときのエラー」である以上、宛先に問題があるかどうかは、オープン（つなぐ・開く）かコピー（送る・書く）のときにわかる、と読むのが自然です。
ALTER SYSTEM の時点で宛先を確かめる仕組みがあるかどうかは、今回の資料では確かめられていません。少なくとも今回の検証環境では、確かめずに受け付けていました。
なお、NOARCHIVELOG でなければ、設定直後にも転送やアーカイブが始まるので、もっと早く ERROR が出るかもしれません。ARCHIVELOG への切り替えは今回の検証環境のルールでしていないので、そこは未確認です。
設定値が同じでも、配達ボードが同じとは限らない
検証中に、もう1つ気づいたことがあります。
最初、何も設定していない状態で V$ARCHIVE_DEST を見ると、1番に行き先が出ていました。
1
LOG_ARCHIVE_DEST_1
VALID PRIMARY C:\app\<user>\product\19.0.0\dbhome_1\RDB
MS（最初の確認で実行した SELECT の出力から1番の行だけを抜き出したものです。列見出しは省略し、パスの一部を伏せています）
LOG_ARCHIVE_DEST_1 は空なのに、配達ボードには Oracle Home の下のフォルダが書かれていて、VALID。
ところが、2番を設定して RESET で戻したあとに見ると、1番は INACTIVE になっていました。
DEST_ID STATUS TARGET DESTINATION ERROR
---------- --------- ---------------- -------------------------------------------------- ----------------------------------------
1 INACTIVE PRIMARY
2 INACTIVE PRIMARY
3 INACTIVE PRIMARYV$PARAMETER の log_archive_dest_1 〜 3 と STATE は、どれも ISDEFAULT TRUE・ISMODIFIED FALSE で、最初と同じです。SPFILE に書いてあるパラメータの数も、最初と同じ19個でした。
インスタンスを再起動すると、1番は VALID に戻りました。
新人さん「パラメータは全部最初と同じなのに、配達ボードだけ違う……」
おうどん「伝票を全部はがしても、ボードのマグネットは自分では戻らなかった」
なぜこうなるのか（パラメータが空のときの既定の行き先がいつ決まるのか）は、今回読んだ資料には書かれていなかったので、断定しません。NOARCHIVELOG の環境での観察です。
ただ、教訓ははっきりしています。設定値が元どおりでも、稼働状態が元どおりとは限らない。戻したあとも、配達ボードまで見て確かめる。
RAC・ロール切替・転送先の番号
ここは今回の検証環境（シングルインスタンス）では試せないので、リファレンスで確かめた範囲だけ書きます。
V$ARCHIVE_DESTは「いまのインスタンス」の情報です。RAC では、どのインスタンスに接続して見ているかを意識します。全インスタンスを並べて見るなら GV$ のビューを使うことになります（RAC での出力は未確認です）LOG_ARCHIVE_DEST_nは PDB の中では変えられません（リファレンスの Modifiable in a PDB は No）。CDB$ROOT で見て、CDB$ROOT で変えます- 転送先は1〜31番。LOG_ARCHIVE_DEST_n のリファレンス（19c）によると、11〜31番は SYNC・LOCATION・MANDATORY・ALTERNATE などに対応しません。番号の用途（何番をどこへの転送に使うか）は環境ごとの決めごとなので、番号だけで用途を決めつけないでください
- 定義した
LOG_ARCHIVE_DEST_nには、対応するLOG_ARCHIVE_DEST_STATE_nが必要です。STATE には enable・defer のほか、alternate（ほかの転送先との通信に失敗したら有効になる）、reset（defer と同じだが、前回失敗したときのエラーを消す）もあります
読者「reset でエラーが消えたら、直ったってことですよね」
おうどん「消えたのはエラーの文面。原因は、たぶんまだ住所録の中にいる」
Data Guard のトラブルシューティングの、スイッチオーバー（ロールの切り替え）のあとに REDO が適用されない場合の項でも、新しいプライマリ側の tnsnames.ora、LOG_ARCHIVE_DEST_n の設定、V$ARCHIVE_DEST を確かめるよう書かれています。
切替のあとにだけ問題が出る転送先は、WRONG VALID_ROLE のまま眠っていた伝票かもしれない。切替の前に、眠っている伝票の住所を tnsping と SQL*Plus で確かめておくと、当日の驚きが1つ減ります。
まとめ：伝票を見たら、配達ボードと到着まで見る
冒頭の新人さんの「SHOW PARAMETER で見たら新しい値になってます。完了です！」は、こう言い直せます。
新人さん「伝票は新しい値になっています。配達ボードは VALID・YES で、ERROR はまだありません。ログスイッチのあとにもう一度見て、受け側に届いたことも確かめてから完了にします」
おうどん「完璧。それなら、存在しない住所に出前を出しても、その日のうちに気づける」
20番さん「ところで、私たちはいつ呼ばれるんでしょう」
おうどん「SHOW PARAMETER のたびに、もう来てるよね」
部分一致の皆さんには、これからも勝手に来てもらいましょう。
SHOW PARAMETER は伝票、V$ARCHIVE_DEST は配達ボード、完了の判断は到着の確認。
まずは自分の DB で、V$ARCHIVE_DEST の STATUS・VALID_NOW・ERROR を1回だけ見てみてください。
全部きれいなら、安心してきつねうどんでもどうぞ🍜
参考資料
- Oracle Database 19c Reference：V$ARCHIVE_DEST — ビューの説明、STATUS・VALID_NOW・VALID_TYPE・VALID_ROLE・ERROR・FAIL_DATE の値と意味、WRONG VALID_ROLE の例
- Oracle Database 19c Reference：LOG_ARCHIVE_DEST_n — 1〜31 の転送先、LOCATION と SERVICE、PDB では変更不可、11〜31 番の制限、STATE_n が必要なこと
- Oracle Database 19c Reference：LOG_ARCHIVE_DEST_STATE_n — enable・defer・alternate・reset の意味と既定値
- Oracle Data Guard Concepts and Administration 19c：Troubleshooting Oracle Data Guard — REDO が届かないときに V$ARCHIVE_DEST を見ること、届かない原因の候補、スイッチオーバー後に確かめる項目
- SQL*Plus User’s Guide and Reference 19c：SHOW — SHOW PARAMETERS は名前にその文字列を含むパラメータを表示すること
- Oracle Database Net Services Administrator’s Guide 19c：Testing Connections — tnsping はリスナーへの到達を確かめ、データベースが動いているかは確かめないこと、TNS-03505 の意味
2026年10月時点の内容です。
コメント