Oracleのスタンバイ（MOUNT状態）でできること・できないこと｜初期化パラメータ・表領域の拡張・GRANTはどこで実行する？ ORA-01109・ORA-01219の意味（19c）

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

（会話は説明用の架空の場面です）

うどん屋でたとえます。
朝の仕込み中のお店は、鍵も開いているし、店主もいるし、帳簿も見られます。
でも、客席の椅子はまだテーブルの上。お客さんを座らせることはできません。

Oracle の MOUNT 状態は、この「仕込み中」の札がかかったお店なんです。

読者「じゃあ、仕込み中に新メニューを黒板に書くのは？」

それがまさに今日の話。書けるものと、書けないものがあるんです。

これは、おうどんも「スタンバイ DB が MOUNT のときに、CPU の設定、表領域の拡張、権限の付与はできるの？」と迷ったことがある疑問です。
同じ「設定変更」なのに、操作によって条件がまるで違う。今回はその理由を、置き場所の違いから整理します。

今日の結論を先に書いておきます。

• 作業の前に、V$DATABASE の DATABASE_ROLE（プライマリかスタンバイか）と OPEN_MODE（MOUNTED か READ WRITE か）を見る
• ユーザー・権限・表領域の変更は、プライマリで行う。フィジカル・スタンバイには REDO で届く
• 初期化パラメータ（CPU_COUNT など）は、スタンバイ側にも別に設定が要るかを考える

3つの「設定変更」は、書き込む場所が違う

置き場所が違えば、仕込み中に触れるかどうかも違う。理屈はこれだけです。

変えたいもの	書き込む場所	MOUNT で触れるか	スタンバイではどうする
初期化パラメータ（CPU_COUNT など）	インスタンスのメモリー／SPFILE（SCOPEによる）	触れる場面がある（公式の Data Guard の手順にも出てくる）	スタンバイのインスタンスに、別に設定するか考える
表領域・データファイルの構造	データファイルと制御ファイル	ファイルの名前の付け替えなど、一部は MOUNT で行う	多くはプライマリの変更が REDO で届く。手作業が要るものは決まっている
ユーザー・権限（GRANT など）	データ辞書（データファイルの中の表）	触れない（ORA-01109）	プライマリで実行する。スタンバイには REDO で届く

用語を少しだけ。

• SPFILE：サーバー側に置く初期化パラメータのファイル。インスタンスを起動するときに読まれる
• 制御ファイル：どのデータファイルがどこにあるか、などを書いたデータベースの帳簿
• データ辞書：ユーザー・表・権限などの情報を入れた表の集まり。中身はデータファイルに入っている
• REDO：データベースへの変更の記録。フィジカル・スタンバイはこれを受け取って、自分にも同じ変更を当てる

椅子の裏はどうかと思いますが、客席側にあるのは本当です。
客席が開いていなければ、権限の紙も貼れない。

もう1つ大事なのが、スタンバイは「本店のレシピをそのまま写す支店」だということ。
Data Guard の概念のマニュアル（19c）では、フィジカル・スタンバイはプライマリと物理的に同じコピーで、ディスク上の構造がブロック単位で同じ、索引を含めてスキーマも同じ、REDO Apply（受け取った REDO を当てる仕組み）でプライマリと同期する、と説明されています。

支店で勝手にメニューを書き足すのではなく、本店で書いたものが支店に届く。
権限も、表領域も、この流れに乗せるのが基本です。

読者「支店長にも、ちょっとは裁量がほしい」

あります。お店の設備、つまり初期化パラメータです。これはあとで。

NOMOUNT・MOUNT・OPEN は、お店の開け方の3段階

結論から言うと、MOUNT は「帳簿は開いたが、客席はまだ」です。

Oracle Database 管理者ガイド（19c）の起動と停止の章では、起動の段階がこう説明されています。

段階	マニュアルの説明（要約）	うどん屋でいうと
NOMOUNT	インスタンスだけ起動し、データベースはマウントしない。通常はデータベースの作成や制御ファイルの再作成のときだけ	店主が来て、電気がついただけ
MOUNT	データベースをマウントするが、閉じたまま。一部の DBA 作業はできるが、一般のアクセスはできない	帳簿は開いた。仕込み中
OPEN	マウントしてオープンする。全ユーザーがアクセスできる（制限モードもある）	営業中

同じ章では、MOUNT で行う作業の例として、REDO ログのアーカイブの有効化・無効化や、データベース全体のリカバリが挙げられています。

それはそれで、お客さんの記憶には残りそうです。

スタンバイは、ふだんから仕込み中のことが多い

Data Guard のフィジカル・スタンバイ管理の章（19c）によると、フィジカル・スタンバイはマウントまたはオープンしたあと、プライマリから REDO を受け取れます。

そして、Active Data Guard（オプションのライセンス）がない場合は、REDO Apply が動いている間はスタンバイをオープンできません。オープンする前に REDO Apply を止める必要があります。
ライセンスがある場合は、REDO Apply を動かしたまま読み取り専用でオープンでき、これをリアルタイム問合せと呼びます。

だから、ライセンスのないスタンバイは、REDO を当て続けるために MOUNT のまま運用されていることがよくあるわけです。

読者「ずっと仕込み中の支店」

仕込みしかしていない支店、と言うと切ないですが、本店が倒れたときに即営業できるように、ずっと仕込みを続けている支店です。えらい。

実験：PDB を MOUNTED にして、何ができるか確かめた

スタンバイは今回の検証環境では作れません。
そこで、PDB（CDB の中にあるプラグ可能なデータベース）を閉じて、MOUNTED にして試しました。

なぜ PDB で代わりになるのか。
ALTER PLUGGABLE DATABASE のリファレンス（19c）には、MOUNTED の PDB は、MOUNT 状態の非 CDB と同じようにふるまう、オブジェクトの変更はできず、データベース管理者だけがアクセスでき、データファイルを読み書きできない、と書かれています。

ただし、これはスタンバイそのものの実験ではありません。データファイルが開いていない状態で何が起きるかを見るための代わりです。

PDB を閉じる

alter pluggable database pdb19 close immediate;
select con_id, name, open_mode from v$pdbs;
select instance_name, status from v$instance;

Pluggable database altered.


    CON_ID NAME         OPEN_MODE
---------- ------------ ----------
         2 PDB$SEED     READ ONLY
         3 PDB19        MOUNTED

2 rows selected.


INSTANCE_NAME    STATUS
---------------- --------
cdb19            OPEN

1 row selected.

（今回の検証環境：Oracle Database 19c 19.3、シングルインスタンス・CDB 構成。SYSDBA で CDB$ROOT に接続し、SQL ファイルにまとめて流した実行結果から該当部分を抜き出しています。区切りに入れた prompt の行、列幅を整える COL コマンドの行は省略。SQL*Plus が列の区切りに入れたタブは空白に置き換えています。以下のブロックも同じです）

PDB19 は MOUNTED。でも、インスタンス（CDB 全体）は OPEN のまま。
ビルの中の1店舗だけが仕込み中、という状態です。

MOUNTED の PDB の中で、V$ と DBA_ を見る

その仕込み中の PDB の中に入って、2種類のビューを見ます。

alter session set container=pdb19;
select name from v$tablespace order by ts#;
select tablespace_name from dba_tablespaces;

Session altered.


NAME
------------
SYSTEM
SYSAUX
UNDOTBS1
TEMP
USERS

5 rows selected.

select tablespace_name from dba_tablespaces
                            *
ERROR at line 1:
ORA-01219: database or pluggable database not open: queries allowed on fixed tables or views only

（実際には、間に SHOW CON_NAME・V$PDBS・V$DATAFILE の確認と、次に載せる DBA_USERS の SELECT を挟んで流しています。このブロックはその部分を省きました）

同じ「表領域の一覧」なのに、V$TABLESPACE は答えて、DBA_TABLESPACES は ORA-01219 で断りました。
ORA-01219 のメッセージは、データベース（または PDB）がオープンしていないので、固定表・固定ビューへの問合せしかできない、という意味です。

固定ビューは、V$ で始まる動的パフォーマンス・ビューのように、データ辞書の表ではないビューのこと。
DBA_ で始まるビューは、データ辞書（データファイルの中）を読みます。データファイルが開いていなければ、読めない。

読者「帳簿の表紙は読めるけど、中のページは糊づけされている感じ？」

近い。表紙に「SYSTEM・SYSAUX・USERS……」と目次だけ書いてあるイメージです。

DBA_USERS も同じでした。

select count(*) from dba_users;

select count(*) from dba_users
                     *
ERROR at line 1:
ORA-01219: database or pluggable database not open: queries allowed on fixed tables or views only

GRANT と CREATE USER は ORA-01109

いよいよ本題です。PDB が開いているうちに作っておいたテスト用ユーザー OUDON_T に、MOUNTED のまま権限を付けてみます。

grant create session to oudon_t;
create user oudon_t2 identified by "Oudon_t_2026y";

grant create session to oudon_t
*
ERROR at line 1:
ORA-01109: database not open


create user oudon_t2 identified by "Oudon_t_2026y"
*
ERROR at line 1:
ORA-01109: database not open

どちらも ORA-01109（データベースがオープンしていない）。
権限もユーザーもデータ辞書に書くものなので、客席が開いていなければ書けません。

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

ここまでの話を、作業の前の確認にまとめます。

1. まず V$DATABASE で、どの店にいるか（DATABASE_ROLE）と、開いているか（OPEN_MODE）を見る
2. ユーザー・権限・表領域の変更は、プライマリで行う。スタンバイには REDO で届く
3. スタンバイで ORA-01109 や ORA-01219 が出たら、壊れたのではなく、MOUNT（仕込み中）で客席が開いていないだけ

読者「壊れたと思って、再起動しかけました」

再起動の前に、看板を見ましょう。仕込み中の店を何度開け直しても、テーブルの上の椅子は自分では降りてきません。

確認の SQL はこれです。今回の検証環境（プライマリ）で実行しました。

select name, database_role, open_mode from v$database;
select instance_name, status from v$instance;
select con_id, name, open_mode from v$pdbs;

NAME       DATABASE_ROLE    OPEN_MODE
---------- ---------------- --------------------
CDB19      PRIMARY          READ WRITE

1 row selected.


INSTANCE_NAME STATUS
------------- ------------
cdb19         OPEN

1 row selected.


    CON_ID NAME       OPEN_MODE
---------- ---------- --------------------
         2 PDB$SEED   READ ONLY
         3 PDB19      READ WRITE

2 rows selected.

V$DATABASE のリファレンス（19c）では、DATABASE_ROLE の値は PRIMARY・PHYSICAL STANDBY・LOGICAL STANDBY・SNAPSHOT STANDBY・FAR SYNC、OPEN_MODE の値は MOUNTED・READ WRITE・READ ONLY・READ ONLY WITH APPLY（リアルタイム問合せでオープンしたフィジカル・スタンバイ）です。

MOUNT のままのフィジカル・スタンバイなら、1つ目の SQL はたとえばこうなります（未実行の出力例です。今回の検証環境にスタンバイはありません）。

NAME       DATABASE_ROLE    OPEN_MODE
---------- ---------------- --------------------
CDB19      PHYSICAL STANDBY MOUNTED

PHYSICAL STANDBY と MOUNTED が並んでいたら、「ここは支店で、仕込み中」です。権限の紙は本店で書きましょう。

絵がなくても、1行目に PRIMARY と書いてあれば本店です。

ここから先は中級者向け：スタンバイで、何をどこで変えるか

ここからは、相談でよく出る3つの作業を、1つずつ置き場所で振り分けます。
基準になるのは、Data Guard のフィジカル・スタンバイ管理の章にある「プライマリの変更のうち、スタンバイで手作業が必要なもの」の表（表10-1）です。

この章は、プライマリに加えた構造の変更の多くは REDO を通じてフィジカル・スタンバイに自動で伝わるが、手作業が要る変更もある、と説明し、その一覧を載せています。

権限の付与：プライマリで実行する

スタンバイはブロック単位のコピーなので、データ辞書もプライマリと同じものが REDO で作られていきます。
つまり、プライマリで GRANT すれば、その変更が REDO に乗ってスタンバイに届く、という流れです。

読者「スタンバイを OPEN READ ONLY にすれば、そこで GRANT できますか」

読み取り専用です。
管理者ガイドの読み取り専用オープンの節では、読み取り専用のデータベースではデータベース・オブジェクトを書き込めない（DML・DDL など）ことが制限として挙げられています。開ければ GRANT できる、ではありません。

なお、表10-1 にはパスワード・ファイルの扱いも載っています。19c のマニュアルでは、12.2 以降、プライマリでのパスワード・ファイルの変更はスタンバイに自動で伝わる（ファー・シンク・インスタンスは例外で手でコピーする）とされています。SYSDBA などの管理権限の付与・取消しで、パスワード・ファイルが更新されるケースです。

表領域の拡張：プライマリで実行し、スタンバイ側は確認する

表10-1 を見ると、データファイルの追加・表領域の作成は、スタンバイの STANDBY_FILE_MANAGEMENT が AUTO なら手作業は不要、MANUAL なら新しいデータファイルをスタンバイにコピーする必要がある、とされています。
データファイルの名前の変更（リネーム）は、スタンバイでも手作業で名前を付け替えます。その手順は、スタンバイを STARTUP MOUNT してから行う流れになっています。

表に載っていないのを「必ず自動」と読むのは、言い過ぎです。マニュアルが言っているのは、構造の変更の「多く」が REDO で伝わる、ということまで。
だから、プライマリで拡張したら、REDO の適用が進んだあとにスタンバイ側の V$DATAFILE の BYTES を見比べる。これを作業の手順に入れておくのがおすすめです。

初期化パラメータ（CPU_COUNT など）：スタンバイに別に設定するか考える

ここが支店長の裁量です。
表10-1 の最後の行には、初期化パラメータについて、スタンバイの初期化パラメータにも対応する変更が要るか検討する、と書かれています。

初期化パラメータは、プライマリとスタンバイが、それぞれ起動時に使う SPFILE（または PFILE）から読みます。プライマリの CPU を増やして CPU_COUNT を変えても、スタンバイのインスタンスの値が変わるとは限りません。
スタンバイが本店の代わりに営業する日（ロールを切り替えた日）に、設備が足りなかった、では困ります。

読者「本店で厨房を広げたら、支店の厨房も広がる魔法は」

ないです。支店の厨房は、支店で工事します。

CPU_COUNT の値の意味や、CPU_COUNT だけでは CPU の使用量が制限されない話は、OracleのCPU_COUNTとOSのCPU数・OCPUの違いにまとめました。SCOPE の選び方はSCOPE=MEMORY・SPFILE・BOTHの違いを見てください。

3つの作業の早見表

作業	どこで実行する	スタンバイで確かめること
ユーザー作成・GRANT	プライマリ	REDO の適用が進んでいるか
データファイルの追加・表領域の作成	プライマリ	STANDBY_FILE_MANAGEMENT が AUTO か（MANUAL ならコピーが要る）
データファイルの RESIZE	プライマリ	適用後に V$DATAFILE の BYTES が同じになったか（自動と決めつけない）
データファイルのリネーム	プライマリとスタンバイの両方	スタンバイで MOUNT して名前を付け替える手順（表10-1・10.3.4）
初期化パラメータ（CPU_COUNT など）	必要ならスタンバイでも	スタンバイの V$PARAMETER・V$SPPARAMETER の値

中級者の落とし穴：CDB_ ビューは、閉じた PDB の行を黙って落とす

これは今回の検証中に見つけた、地味に怖い話です。
PDB19 を MOUNTED にしたまま、CDB$ROOT から V$DATAFILE と CDB_ ビューを見比べました。

select con_id, count(*) from v$datafile group by con_id order by con_id;
select con_id, count(*) from cdb_data_files group by con_id order by con_id;
select con_id, count(*) from cdb_users group by con_id order by con_id;

    CON_ID   COUNT(*)
---------- ----------
         1          4
         2          3
         3          4

3 rows selected.


    CON_ID   COUNT(*)
---------- ----------
         1          4

1 row selected.


    CON_ID   COUNT(*)
---------- ----------
         1         36

1 row selected.

V$DATAFILE には CON_ID 3（PDB19）のデータファイルが4つ出ています。
でも CDB_DATA_FILES と CDB_USERS には、CON_ID 3 の行がありません。エラーも出ません。

仕込み中のテナント「いません」

閉じた PDB の中のデータ辞書は読めないので、行が出てこないわけです。
困るのは、エラーにならないこと。監視や棚卸しのスクリプトが CDB_ ビューを数えていると、閉じている PDB が丸ごと「ないこと」になります。

（CON_ID 2 の PDB$SEED も CDB_ ビューの結果に出ていませんが、閉じる前の結果を同じ形で取っていないので、ここでは理由を扱いません）

対策は、集計の前に V$PDBS の OPEN_MODE を見ることです。

select con_id, name, open_mode from v$pdbs;

MOUNTED の PDB があったら、その PDB の数字は CDB_ ビューからは取れていない、と考える。
棚卸しの表に「0件」と書く前に、そもそも店が開いていたかを見ましょう。

読者「0件なら、平和な証拠では」

シャッター街も、たしかに静かです。

ここから先は上級者向け。読み飛ばしてもOKです：MOUNTED の PDB でも、SCOPE=SPFILE だけは通った

最後に、今回の検証でいちばん意外だった結果です。
MOUNTED の PDB の中で、初期化パラメータの OPEN_CURSORS を変えてみました。OPEN_CURSORS は PDB の中でも変えられるパラメータです。

変更の前提・影響・戻し方

• 前提：テスト用の PDB19 だけを対象にする。CDB$ROOT の値は変えない
• 影響：PDB19 の OPEN_CURSORS（1セッションが同時に開けるカーソルの上限）が変わる
• 反映時期：SCOPE=SPFILE なので、次に PDB19 をオープンしたとき
• 変更後の確認：PDB19 の中で V$PARAMETER と V$SPPARAMETER を見る
• 戻し方：PDB19 の中で ALTER SYSTEM RESET open_cursors SCOPE=SPFILE をして、PDB19 を閉じて開き直す

-- PDB19 が MOUNTED の状態で、PDB19 の中で実行
alter system set open_cursors=400 scope=memory;
alter system set open_cursors=400 scope=spfile;
select con_id, name, value from v$parameter where name='open_cursors';

alter system set open_cursors=400 scope=memory
*
ERROR at line 1:
ORA-01219: database or pluggable database not open: queries allowed on fixed tables or views only



System altered.


    CON_ID NAME         VALUE
---------- ------------ ----------
         3 open_cursors 300

1 row selected.

SCOPE=MEMORY は ORA-01219 で断られ、SCOPE=SPFILE は System altered. で通りました。
V$PARAMETER は 300 のまま。予約の伝票だけ受け付けて、今すぐの変更はできない、という返事です。

読者「仕込み中に、今日の黒板は書けないけど、明日の黒板は予約できる」

まさにそれでした。うどん屋のほうがわかりやすいの、ちょっと悔しい。

PDB19 をオープンしてから、中で見ると。

-- CDB$ROOT で PDB19 をオープンしてから、PDB19 の中で実行
select con_id, name, value, ismodified from v$parameter where name='open_cursors';
select sid, name, value from v$spparameter where name='open_cursors';

    CON_ID NAME         VALUE      ISMODIFIED
---------- ------------ ---------- ----------
         3 open_cursors 400        FALSE

1 row selected.


SID                                                                              NAME         VALUE
-------------------------------------------------------------------------------- ------------ ----------
*                                                                                open_cursors 400

1 row selected.

オープンした時点で 400 が効いていました。ISMODIFIED が FALSE なのは、起動（オープン）のあとに ALTER SYSTEM で変えたのではなく、オープンのときに読まれた値だからと読めます。

SCOPE=MEMORY が ORA-01219 になる理由は、メッセージからは「内部で固定ビュー以外の何かを読もうとして断られた」ように見えます。ただ、何を読もうとしたのかは公式資料で確かめられなかったので、ここでは断定しません。
また、これは MOUNTED の PDB での結果です。CDB 全体（インスタンス）を MOUNT で起動したときの ALTER SYSTEM は、今回の検証環境では試していません（起動オプションを変えない約束で検証しているため）。

元に戻した結果

-- PDB19 の中で
alter system reset open_cursors scope=spfile;
-- CDB$ROOT で
alter pluggable database pdb19 close immediate;
alter pluggable database pdb19 open;
-- PDB19 の中で
select con_id, name, value, isdefault, ismodified from v$parameter where name='open_cursors';
select sid, name, value from v$spparameter where name='open_cursors';

System altered.


Pluggable database altered.


Pluggable database altered.


    CON_ID NAME         VALUE      ISDEFAULT ISMODIFIED
---------- ------------ ---------- --------- ----------
         3 open_cursors 300        FALSE     FALSE

1 row selected.


SID                                                                              NAME         VALUE
-------------------------------------------------------------------------------- ------------ ----------
*                                                                                open_cursors

1 row selected.

（このブロックは、別の SQL ファイルで流した結果から該当部分を抜き出し、間の確認用の SELECT とセッション切り替えの行を省いています）

PDB19 の値は 300 に戻り、PDB19 の V$SPPARAMETER の VALUE は空（PDB 用の値の指定なし）になりました。CDB$ROOT の OPEN_CURSORS は、検証の前後とも 300 のままです。

予約は、店を開け直したときに読まれる。取り消しも同じ、というわけです。

スタンバイの話に戻すと

この結果から言えるのは、MOUNTED の PDB でも、次回のオープンで効く設定（SCOPE=SPFILE）は受け付けられることがある、ということまでです。
スタンバイの CDB 全体が MOUNT のときに、どのパラメータをどの SCOPE で変えられるかは、この実験からは言えません。本番のスタンバイで試す前に、同じ構成の検証環境で確かめてください。

それと、もう1つ大事なこと。
Data Guard の管理の章では、フィジカル・スタンバイで引数なしの STARTUP を実行すると、読み取り専用でオープンまでする、とされています。
Active Data Guard のライセンスがない環境では、REDO Apply を動かしたままオープンできない決まりでした。「とりあえず STARTUP」で開けてしまう前に、その環境のライセンスと運用の手順を確かめましょう。

読者「いつもの癖で STARTUP って打ちそう」

札を裏返す前に、V$DATABASE の1行目です。

冒頭の新人さんに、もう一度

冒頭では、MOUNT のスタンバイで GRANT して ORA-01109 でした。
今なら、こう言えます。

読者「おうどんさんは、看板は読む派ですか」

読みます。メニューの写真を3周したあとで。

変える前に、それがどこに書き込まれるものかを考える。
SPFILE ならお店の設備、データファイルなら客席、そしてスタンバイは本店を写す支店。置き場所がわかれば、仕込み中に何ができるかは自然に決まります。

まずは次の作業の前に、V$DATABASE の DATABASE_ROLE と OPEN_MODE を1回だけ見てみてください🍜

参考資料

• Oracle Database 管理者ガイド 19c：データベースの起動と停止 — NOMOUNT・MOUNT・OPEN の説明、MOUNT で行う作業の例、読み取り専用オープンの制限
• Oracle Data Guard 概要および管理 19c：フィジカル・スタンバイ・データベースの管理 — スタンバイの起動（引数なしの STARTUP は読み取り専用でオープン）、マウント・オープン後の REDO 受信、Active Data Guard なしのオープンの決まり、表10-1（手作業が要るプライマリの変更、データファイルの追加・リネーム、パスワード・ファイル、初期化パラメータ）
• Oracle Data Guard 概要および管理 19c：Data Guard の概念 — フィジカル・スタンバイはブロック単位で同じコピーで REDO Apply で同期する
• Oracle Database SQL 言語リファレンス 19c：ALTER PLUGGABLE DATABASE — MOUNTED の PDB は MOUNT 状態の非 CDB と同じようにふるまう、CLOSE は MOUNTED にする
• Oracle Database リファレンス 19c：V$DATABASE — DATABASE_ROLE と OPEN_MODE の値

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