Oracle Database のアーキテクチャは、過去20年間で最大の変革期を迎えています。Oracle Database 21c 以降、従来の Non-CDB（非マルチテナント）構成でのデータベース作成は完全に廃止され、マルチテナント（CDB/PDB）構成が唯一の選択肢となりました。さらに、次世代の長期サポート版（LTS）と言われる Oracle 26ai でもこの方針は継続・強化され、AI機能との統合もコンテナ技術を前提に進んでいます。
マルチテナント・アーキテクチャ自体は Oracle 12c から導入された機能であり、すでに10年以上の歴史があります。本記事で解説する手順は、最新の 26ai はもちろん、現在主流の 19c やそれ以前のバージョンでも基本的に共通して使用できる標準的な運用作法です。
これまでの「インスタンス起動＝DB利用可能」という単純な図式は通用しません。コンテナ技術の導入により、リソース管理、セキュリティ、バックアップの考え方が根本から変わるからです。
本記事では、マルチテナント環境で必須となる「起動停止・接続・ユーザー管理・バックアップ・パラメータ設定」について、単なるコマンド羅列ではなく「なぜそうするのか」という背景も含めて詳細に解説します。これまで当ブログで解説してきた運用ノウハウの総集編として、日々の業務や詳細な手順書作成にお役立てください。
[参考]
Oracle AI Database 26ai coming soon for Linux x86-64 on-premises platforms | database
💰 【PR】Oracleエンジニアの市場価値、調べてみませんか？
Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか？
0. 【図解】CDB/PDBアーキテクチャ詳細解説
操作に入る前に、この「マルチテナント構成」がどのような仕組みで動いているのか、内部構造をもう少し深く理解しておきましょう。ここを理解しておくと、トラブルシューティングの勘が鋭くなります。
仕組み：リソースは「共有」、データは「分離」
従来（Non-CDB）は、データベースごとに OS 上のメモリ領域（SGA）やバックグラウンドプロセス（PMON, SMON, DBWR, LGWR 等）を起動していました。CDB構成では、1つの巨大な器（CDB）の中に、複数のデータベース（PDB）を仮想的に同居させます。
+-------------------------------------------------------------------------------------+
| CDB (Container Database) / インスタンス |
| +-------------------------------------------------------------------------------+ |
| | メモリ (SGA) / プロセス (BG) 【共有】 | |
| | ※ REDOログバッファや共有プールは全員でシェアします | |
| +-------------------------------------------------------------------------------+ |
| | | | | |
| +--------------+ +--------------+ +--------------+ +--------------+ |
| | CDB$ROOT | | PDB$SEED | | PDB1 (App) | | PDB2 (Dev) | |
| | (管理領域) | | (ひな形) | | (本番用) | | (開発用) | |
| | メタデータ | | Read Only | | 人事アプリ | | 検証環境 | |
| +--------------+ +--------------+ +--------------+ +--------------+ |
| | | | | |
| +--------------+ +--------------+ +--------------+ +--------------+ |
| | システム定義 | | ひな形データ | | 顧客・売上 | | テストデータ | |
| | (Datafiles) | | (Datafiles) | | (Datafiles) | | (Datafiles) | |
| | Control File | | | | | | | |
| | Redo Logs | | | | | | | |
| +--------------+ +--------------+ +--------------+ +--------------+ |
+-------------------------------------------------------------------------------------+
- CDB (Container Database):
- いわば「マンションの建物全体」です。OS から見ると、プロセスは1セットしか動いていません。
- 制御ファイル (Control File) や REDOログファイル は CDB 全体で共有します。つまり、ログスイッチやチェックポイントは全 PDB に影響します。
- CDB$ROOT:
- 「大家さん（管理人室）」です。
- 全コンテナを管理するためのディクショナリ情報（メタデータ）のみを持ちます。
- ここに業務データ（テーブル等）を作成してはいけません。 管理人室に住み着くようなものです。
- PDB (Pluggable Database):
- 「各部屋」です。アプリケーションからは独立したデータベースに見えます。
SYSTEM,SYSAUX表領域は PDB ごとに独立して持っています。- ローカルUNDOモード（推奨）: 最近のバージョンでは UNDO 表領域も PDB ごとに持つのが標準となり、PDB 単位でのフラッシュバックなどが容易になりました。
- PDB$SEED:
- 「モデルルーム（ひな形）」です。読み取り専用です。
- 新しい PDB を作成する際は、内部的にこの SEED をコピーすることで高速に作成されます。
なぜこの構成なのか？（CDB構成のメリット）
単なる強制移行ではなく、運用面でも明確なメリットがあるため、多くの企業で導入が進んでいます。
- 集約密度の向上とコスト削減:
- 従来は DB 10個ならバックグラウンドプロセスも 10セット必要でした。CDB なら 1セットで済むため、OS リソース（特にメモリとプロセス数）を劇的に節約できます。
- 運用の俊敏性（ポータビリティ）:
- PDB は「ファイルとメタデータの集合体」として扱えます。
UNPLUG（取り外し）して別のサーバーの CDB にPLUG（取り付け）することで、データベースの引っ越しや複製がファイルコピー感覚で行えます。パッチ適用済みの新しい CDB へ引っ越すだけでアップグレードが完了する手法も取れます。
- 管理の一元化と役割分担:
- パッチ適用: CDB（家主）にパッチを当てれば、全PDB（住人）に反映されます（※PDB個別の適用も可能）。
- 役割分担: 「インフラ管理者はCDB全体を監視」「アプリ開発者はPDB内だけを自由に操作」といった明確な権限分離が可能です。
結論：CDB/PDB 運用コマンド・チートシート
まず、現場で頻繁に使うコマンドを拡張版リストとして整理しました。これらは空で打てるレベルにしておきましょう。
| 操作カテゴリ | 目的 | コマンド・要点 |
|---|---|---|
| 起動・停止 | CDB全体の起動 | sqlplus / as sysdba → STARTUP |
| 全PDBの状態確認 | SHOW PDBS または SELECT name, open_mode FROM v$pdbs; | |
| 特定のPDBオープン | ALTER PLUGGABLE DATABASE <pdb名> OPEN; | |
| 全PDB一括オープン | ALTER PLUGGABLE DATABASE ALL OPEN; | |
| 自動起動設定 | ALTER PLUGGABLE DATABASE <pdb名> SAVE STATE; | |
| 接続 | PDBへの直接接続 | sqlplus user/pass@<ホスト>:<ポート>/<サービス名> |
| コンテナ切り替え | ALTER SESSION SET CONTAINER = <pdb名>; | |
| 現在地の確認 | SHOW CON_NAME | |
| ユーザー | ローカルユーザー作成 | PDB接続後に CREATE USER <名> ... (c##不要) |
| 共通ユーザー作成 | CDB$ROOTで CREATE USER c##<名> ... | |
| パラメータ | PDB個別変更 | ALTER SYSTEM SET <param>=<val> SCOPE=BOTH; (PDB内で実行) |
| 複製 | PDBクローン作成 | CREATE PLUGGABLE DATABASE <新> FROM <元>; |
| 確認 | 全PDBの情報を参照 | SELECT * FROM CDB_USERS ... (DBA_ではなくCDB_を使用) |
1. 起動と停止・接続の作法（詳細編）
マルチテナント環境では、「インスタンスが上がっているのに接続できない」という問い合わせが頻発します。これは PDB のライフサイクル管理が漏れているケースが大半です。
インスタンス(CDB)とPDBのライフサイクル管理
CDB を STARTUP しても、PDB はデフォルトで MOUNT（マウント）状態となります。これは「OSで言えばファイルシステムがマウントされただけ」の状態であり、SQL は発行できません。
手順詳細：PDBの自動起動設定まで
毎回手動で PDB を開くのは運用リスクになります。SAVE STATE 機能を使って、CDB 再起動後も前の状態を復元するように設定します。
-- 1. CDB（インスタンス）への接続と起動
-- ※ここは従来と同じです
$ sqlplus / as sysdba
SQL> STARTUP;
-- 2. PDBの状態確認（MOUNT = 停止中、READ WRITE = 利用可）
-- CON_ID: 2 は必ず PDB$SEED です
SQL> SHOW PDBS;
CON_ID CON_NAME OPEN_MODE RESTRICTED
---------- ------------------------------ ---------- ----------
2 PDB$SEED READ ONLY NO
3 PDB1 MOUNTED -- ←まだ使えない（停止中）
4 PDB2 MOUNTED -- ←まだ使えない（停止中）
-- 3. PDBをオープンする（READ WRITEにする）
-- 特定のPDBのみ開く場合
SQL> ALTER PLUGGABLE DATABASE pdb1 OPEN;
-- すべてのPDBを一気に開く場合
SQL> ALTER PLUGGABLE DATABASE ALL OPEN;
-- 4. 【重要】現在のオープン状態を保存する（再起動対策）
-- これを実行すると、次回インスタンス起動時に自動で PDB1 が OPEN されます
SQL> ALTER PLUGGABLE DATABASE pdb1 SAVE STATE;
-- 保存された状態の確認（dba_pdb_saved_states ビュー）
SQL> SELECT con_name, state FROM dba_pdb_saved_states;
接続方法の正解：サービス名とリスナー設定
19c/26ai 時代において、ORACLE_SID 環境変数に頼る接続は「管理作業（CDBメンテナンス）」専用と考えてください。アプリケーションや開発ツールからの接続は、必ず Oracle Net（リスナー）経由のサービス名接続 を行います。
リスナーの状態確認
リスナーには、CDB 全体のサービスだけでなく、PDB ごとのサービス名も自動登録されています。
$ lsnrctl status
...
サービスのサマリー...
サービス"ORCLCDB" ... インスタンス"ORCLCDB" ... (CDB全体)
サービス"pdb1.example.com" ... インスタンス"ORCLCDB" ... (PDB1専用)
サービス"pdb2.example.com" ... インスタンス"ORCLCDB" ... (PDB2専用)
tnsnames.ora の記述例
開発者の PC や AP サーバーの tnsnames.ora には、以下のように PDB ごとのエイリアスを定義します。
# PDB1への接続設定
PDB1_APP =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = orasrv01)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = pdb1.example.com) # ←ここにPDBのサービス名を書く
)
)
コンテナ切り替え（ALTER SESSION）の活用
DBA がサーバー上で作業する場合、いちいち sqlplus を終了せずにコンテナを行き来できます。
-- CDB$ROOTからPDB1へ移動
SQL> ALTER SESSION SET CONTAINER = pdb1;
SQL> SHOW CON_NAME;
CON_NAME
------------------------------
PDB1
-- 作業が終わったらCDB$ROOTへ戻る（共通ユーザーのみ可能）
SQL> ALTER SESSION SET CONTAINER = cdb$root;
💰 【PR】Oracleエンジニアの市場価値、調べてみませんか？
Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか？
2. 共通ユーザーとローカルユーザー・権限管理（深掘り）
「ユーザー作成」は最もエラーが出やすいポイントです。26ai 時代には「ネームスペースの分離」という概念を理解する必要があります。
ユーザーの種類と命名規則の理由
なぜ共通ユーザーには c## が必要なのか？ それは 「名前の衝突」を防ぐため です。 もし scott という共通ユーザーと、PDB1 内の scott というローカルユーザーが同時に作れてしまったら、ログイン時にどちらが使われるか混乱します。そのため、CDB全体で有効なユーザーは c## を付ける強制ルールがあります。
| 種類 | 作成場所 | 命名規則 | 役割・用途 |
|---|---|---|---|
| 共通ユーザー (Common User) | CDB$ROOT | c## または C## 接頭辞が必須 | DBA、統合監視ツール、バックアップ運用。全PDBにアクセス可能（権限次第）。 |
| ローカルユーザー (Local User) | 各PDB | 制限なし（従来通り） | 業務アプリ、開発者スキーマ。そのPDB内でのみ有効。他のPDBには存在しない。 |
【重要】権限付与時の CONTAINER 句と落とし穴
CDB環境での権限管理には、「どの範囲で権限を行使できるか」 を指定する CONTAINER 句が追加されています。これを省略したときのデフォルト挙動（CURRENT）がトラブルの元凶です。
発生する問題のケーススタディ：なぜ ORA-01031 が出るのか
ケース：全体管理用の共通ユーザー(c##admin)を作ったが、PDB を操作できない
- DBAの操作: CDB$ROOT に接続し、
GRANT DBA TO c##admin;を実行。 （心の声：「よし、これで c##admin は最強の権限を持ったぞ」） - 実際の挙動:
CONTAINER句を省略したため、Oracle はCONTAINER=CURRENTと解釈します。つまり、「CDB$ROOT という管理領域の中だけで DBA 権限を行使できる」 という意味になります。 - トラブル発生:
c##adminで PDB1 に接続し、テーブルを作ろうとする。 → エラー発生！ORA-01031: 権限が不足しています。（理由：PDB1 の中では、c##admin はただの一般ユーザー扱いだからです）
正しい対処法：CONTAINER=ALL を明示する
共通ユーザーに対して、「すべての現在の PDB および将来作られる PDB」で権限を有効にするには、必ず CONTAINER=ALL を付けます。
-- 全PDBでSYSDBA権限を使えるようにする（真の管理者権限）
SQL> GRANT SYSDBA TO c##admin CONTAINER=ALL;
-- セッション権限なども同様
SQL> GRANT CREATE SESSION TO c##admin CONTAINER=ALL;
-- 【比較】以下は省略時の挙動（現在のコンテナのみ有効）
-- CDB$ROOTで実行した場合、PDBでは権限が無効になる
SQL> GRANT SELECT ANY TABLE TO c##admin; -- (暗黙に CONTAINER=CURRENT)
3. 初期化パラメータ設定と階層構造
パラメータ設定も「継承」と「オーバーライド」の概念が導入されています。 すべての初期化パラメータがPDB単位で自由に変更できるわけではありません。CDB$ROOTの設定を強制的に引き継ぐもの（変更不可）と、PDB独自に設定できるものがあります。
パラメータの階層構造
- グローバル値 (CDB$ROOT): デフォルト設定。特に指定がなければ全 PDB がこの値を使います。
- ローカル値 (PDB): PDB 側で個別に設定した値。グローバル値より優先されます。
ISPDB_MODIFIABLE の確認
パラメータを変更する前に、それが PDB 単位で変更可能かを確認します。
-- PDB単位で変更可能かチェック（例：open_cursors, processes）
SELECT name, ispdb_modifiable
FROM v$parameter
WHERE name IN ('open_cursors', 'sga_target', 'processes');
-- 結果例
-- open_cursors TRUE (PDBごとに変更可。アプリ要件に合わせて調整可能)
-- sga_target TRUE (PDBごとの上限を設定可。リソース分離に重要)
-- processes FALSE (CDB全体でしか設定不可！全PDBで共有するプロセス総数)
- FALSE の場合: そのパラメータは PDB 内で
ALTER SYSTEMしてもエラーになるか、無視されます。CDB$ROOT で設定された値が全 PDB に適用されます。
設定変更の実行パターン
-- パターン1: PDB単位で個別設定（オーバーライド）
-- アプリケーションA（PDB1）だけカーソル数を増やしたい
SQL> ALTER SESSION SET CONTAINER = pdb1;
SQL> ALTER SYSTEM SET open_cursors = 2000 SCOPE=BOTH;
-- ↑ このPDB1だけに反映されます
-- パターン2: CDB全体のデフォルト値を変更
SQL> ALTER SESSION SET CONTAINER = cdb$root;
SQL> ALTER SYSTEM SET open_cursors = 500 SCOPE=BOTH CONTAINER=ALL;
-- ↑ 今後作成されるPDBも含め、個別設定していない全PDBのデフォルトが変わります
4. PDBのクローニング（複製）テクニック
マルチテナント機能の目玉の一つが、稼働中のPDBをそのままコピーできる「ホットクローン」機能です。「本番データの最新スナップショットを使って、すぐに開発環境を作りたい」といった要望にコマンド一発で応えられます。
ホットクローンの実行手順（CREATE PLUGGABLE DATABASE）
前提条件:
- CDBが
ARCHIVELOGモードで運用されていること。 - ローカルUNDOモード（推奨）であること。
重要：FILE_NAME_CONVERT によるパス変換（非OMF環境）
Oracle Managed Files (OMF) を使用している環境（db_create_file_dest が設定されている）では、ファイル配置はOracleが自動管理するためパスの指定は不要です。
しかし、OMFを使わず手動でファイル管理している場合、FILE_NAME_CONVERT 句が必須となります。これを指定しないと、新PDBがコピー元PDBと同じファイルパス（例: /u01/oradata/pdb1/system01.dbf）を使おうとして、「ファイルが既に存在する」というエラーで失敗します。
FILE_NAME_CONVERT の仕組み
FILE_NAME_CONVERT = ('置換対象の文字列', '置換後の文字列') という形式で、コピー元のファイルパスの一部を書き換えます。
シナリオ例
- コピー元 (pdb_prod) のデータファイル:
/u01/oradata/CDB1/pdb_prod/system01.dbf/u01/oradata/CDB1/pdb_prod/users01.dbf
- コピー先 (pdb_dev) で配置したい場所:
/u01/oradata/CDB1/pdb_dev/system01.dbf/u01/oradata/CDB1/pdb_dev/users01.dbf
実行コマンド例：本番PDB(pdb_prod) をコピーして 開発PDB(pdb_dev) を作成
-- 1. CDB$ROOT に接続
$ sqlplus / as sysdba
-- 2. クローン実行（FILE_NAME_CONVERTを指定）
SQL> CREATE PLUGGABLE DATABASE pdb_dev FROM pdb_prod
FILE_NAME_CONVERT = ('/pdb_prod/', '/pdb_dev/');
-- 解説：
-- Oracleは '/pdb_prod/' という文字列を探し、'/pdb_dev/' に置換してファイルを生成します。
-- ディレクトリ '/u01/oradata/CDB1/pdb_dev/' はOS上で事前に作成しておく必要があります。
-- 3. 作成直後はMOUNT状態なのでオープンする
SQL> ALTER PLUGGABLE DATABASE pdb_dev OPEN;
-- 4. サービス名を確認（自動的に pdb_dev というサービスが起動します）
SQL> SELECT name, open_mode FROM v$pdbs;
これだけで、ユーザーデータ、権限、オブジェクトなど全てが含まれた「コピーDB」が完成します。Data Pump で何時間もかけてエクスポート/インポートしていた作業が、わずか数分（データ量とディスク速度に依存）で完了します。
5. RMANバックアップと復旧
CDB 環境のバックアップ戦略には柔軟性があります。基本は「丸ごとバックアップ」ですが、大規模環境では「分割バックアップ」も有効です。
バックアップ取得の戦略
基本は target /（CDB$ROOT）に接続して実行します。
$ rman target /
- 戦略A：CDB全体バックアップ【基本・推奨】
- 管理が最も楽です。CDB$ROOT、PDB$SEED、全 PDB をまとめて取得します。
- コマンド:
BACKUP DATABASE PLUS ARCHIVELOG;
- 戦略B：PDB単位バックアップ
- PDB ごとに更新頻度が極端に違う場合や、テラバイト級の PDB がある場合に有効です。
- コマンド:
BACKUP PLUGGABLE DATABASE pdb1, pdb2 PLUS ARCHIVELOG;
PDB単位の復旧（PDB PITR）
マルチテナントの最大の利点は、「障害が起きた PDB だけを停止して復旧できる」 点です。他の PDB（他システム）はサービスを継続できます。
シナリオ：PDB1 のデータファイルを誤って削除してしまった
-- 1. 障害PDBを閉じる（他のPDBは稼働中でOK）
RMAN> ALTER PLUGGABLE DATABASE pdb1 CLOSE;
-- 2. リストア＆リカバリ
-- 必要なバックアップピースとアーカイブログを自動で探して適用します
RMAN> RESTORE PLUGGABLE DATABASE pdb1;
RMAN> RECOVER PLUGGABLE DATABASE pdb1;
-- 3. PDBを開く
RMAN> ALTER PLUGGABLE DATABASE pdb1 OPEN;
6. Data Pump (expdp/impdp) の使用方法
論理バックアップや移行で使う Data Pump も、マルチテナント特有の作法があります。
【重要】CDB$ROOTでは実行しない・Oracle Net接続が必須
初心者が最もハマるポイントです。
- CDB$ROOTにデータはない: ユーザーデータは PDB にあります。CDB$ROOT で expdp しても、管理情報しか抜けません。
- ローカルユーザーはCDBにログインできない: PDB のユーザー（
app_userなど）は PDB にしか存在しません。そのため、OS認証（/ as sysdba）などの CDB 接続経由では認証すら通りません。
結論: Data Pump は 「必ず TNS サービス名を指定して、リモートDBであるかのように」 実行します。
準備と実行ステップ
Step 1: ディレクトリ・オブジェクトの作成（PDB内で！） ディレクトリ設定も PDB ごとに独立しています。
SQL> ALTER SESSION SET CONTAINER = pdb1;
SQL> CREATE OR REPLACE DIRECTORY dp_dir AS '/u01/app/oracle/admin/pdb1/dpdump';
SQL> GRANT READ, WRITE ON DIRECTORY dp_dir TO app_dev;
Step 2: エクスポート実行 (expdp) 接続文字列（@サービス名）を必ず指定します。
# 正しい例：サービス名を指定して PDB に直接ログイン
$ expdp app_dev/Password123@localhost:1521/pdb1 \
DIRECTORY=dp_dir \
DUMPFILE=pdb1_schema.dmp \
LOGFILE=exp_pdb1.log \
SCHEMAS=app_dev \
METRICS=Y
METRICS=Y: 進捗状況やスループットをログに出力するオプション（便利なので推奨）。
7. 運用監視の要：CDBビューの活用
従来の DBA_ ビューは、「現在接続しているコンテナの情報」しか見えません。CDB 全体を横断的に監視するには、CDB_ 系のビュー を使用します。
DBA_USERSなどのDBA_系ビュー:- 接続中のコンテナ内の情報のみを表示します。
- PDB1に接続していればPDB1の情報のみ、CDB$ROOTならCDB$ROOTの情報のみが見えます。
CDB_USERSなどのCDB_系ビュー:- 全コンテナ（ROOT, SEED, 全PDB）の情報を横断的に表示します。
- 通常、CDB$ROOT に接続して使用します。
CON_ID列で、「どのPDBの情報か」を識別できます。
活用例：全PDBのデータファイル使用量を一覧化する CDB$ROOT に接続して実行することで、個別のPDBにログインし直すことなく全体の容量監視が可能です。
-- CDB$ROOTで実行
SELECT
p.pdb_name,
f.file_name,
round(f.bytes / 1024 / 1024, 2) as size_mb
FROM cdb_data_files f
JOIN cdb_pdbs p ON f.con_id = p.con_id
ORDER BY p.pdb_name;
FAQ（よくある質問・拡張版）
Q1: startup コマンドだけで全PDBをオープンできませんか？ A1: 標準機能ではできません。かつては起動トリガー（AFTER STARTUP TRIGGER）を書くテクニックがありましたが、現在は ALTER PLUGGABLE DATABASE ALL SAVE STATE; を使用するのが公式のベストプラクティスです。これを一度実行すれば、次回から自動起動します。
Q2: アプリケーションの接続設定で SERVICE_NAME ではなく SID を使っていますが動きますか？ A2: 動きません。 CDB 環境ではインスタンス（SID）は一つ（CDB全体）であり、各 PDB はサービス名で区別されます。SID 指定で接続すると CDB$ROOT に繋がり、「テーブルが見つからない」エラーになります。接続文字列の SID= を SERVICE_NAME= に書き換える必要があります。
Q3: 共通ユーザー（c##user）をアプリで使ってもいいですか？ A3: 非推奨です。 共通ユーザーは権限管理が複雑で、CONTAINER 句のミスによる事故が起きやすいです。また、PDB を別の CDB へ引っ越した際、移動先に同じ共通ユーザーが存在しないと不整合が起きる可能性があります。アプリ用には可搬性の高い「ローカルユーザー」を使用してください。
Q4: 開発環境のPDBをクローン（複製）してテスト環境を作りたいのですが？ A4: 非常に簡単にできます。PDB がオープン状態でも CREATE PLUGGABLE DATABASE pdb_test FROM pdb_dev; というコマンド一発でホットクローンが可能です（※要件としてローカルUNDOモードであること、アーカイブログモードであること等が推奨されます）。
Q5: PDBクローン作成時、コピー元PDBへのアクセスは制限されますか？ A5: 19c以降のホットクローン機能では、コピー元PDBは READ WRITE（更新可能） のままでクローン作成が可能です。ユーザー業務を止める必要はありません。
まとめ：運用手順書の更新を急ごう
Oracle 21c/26ai 時代では、「どのコンテナに繋いでいるか」 と 「操作のスコープ（適用範囲）」 を常に意識することが DBA の必須スキルです。
- 必須化: Non-CDB は廃止。逃げ道はありません。
- 接続: サービス名接続（Oracle Net）への完全移行が必要です。
- 権限: 共通ユーザーの
CONTAINER=ALL漏れは、トラブルの最大要因です。 - 監視:
DBA_ビューだけでなくCDB_ビューを活用しましょう。
これらの知識は、クラウド上の Oracle Database (OCI BaseDB, Exadata Database Service) でも全く同じように適用されます。来るべき強制マルチテナント化に備え、今のうちに運用スクリプトや手順書をアップデートしておきましょう。
本記事は Oracle Database 19c/21c を対象に解説します（26aiでも基本概念は共通ですが、画面や既定値が異なる場合があります）。
💰 【PR】Oracleエンジニアの市場価値、調べてみませんか？
Oracleのスキルは需要が高く、特定の資格や経験を持っていると年収が大幅にアップするケースがあります。まずはIT専門のエージェントで非公開求人をチェックしてみませんか？
コメント