マルチテナント（PDB リロケート）難易度 高無料
本番 CDB（CDB1）で稼働中の PDB SALES を、ほぼ無停止で別の CDB（CDB2）へ移設したい。CDB2 から CDB1 へのデータベースリンク cdb1_link（CDB1 の共通ユーザーを指す）を作成済みで、CDB2 側で次を実行した。
-- CDB2 の CDB$ROOT に接続して実行 SQL> CREATE PLUGGABLE DATABASE sales 2 FROM sales@cdb1_link 3 RELOCATE; Pluggable database created. SQL> SELECT open_mode FROM v$pdbs WHERE name='SALES';
この RELOCATE 操作の前提と挙動として最も適切なものを選べ。（単一選択）
- A作成直後の
SALESはCDB2でREAD WRITEになっており、即座に利用できる。移設はこの時点で完了している - B作成直後の
SALESはCDB2でMOUNTEDであり、ALTER PLUGGABLE DATABASE sales OPEN;を実行した時点で移設が確定し、CDB1側の元 PDB はクローズされる。前提として両 CDB は ローカル UNDO モードかつソース CDB は ARCHIVELOG モードである必要がある - C
RELOCATEはソース PDB をREAD ONLYにしてからでないと実行できず、移設中はソース側のユーザーは更新できない - D
RELOCATEは共有 UNDO モードでのみ使用可能で、ローカル UNDO 環境ではORA-65114になる
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：B✓Gold監修
解説
CREATE PLUGGABLE DATABASE ... FROM <pdb>@<link> RELOCATE は、
PDB を別の CDB へほぼ無停止で移設（relocate）するための構文である。リモートの「ホットクローン」基盤の上に成り立つ。
前提条件（これが満たされないと実行できない）：
- ローカル UNDO モード：ソース PDB がオープン（READ WRITE）のまま移設・クローンするには、CDB がローカル UNDO（local undo）である必要がある。共有 UNDO ではホット（オンライン）操作はできない。
- ソース CDB が ARCHIVELOG モード：オープン中の PDB を一貫した状態でコピーするためにアーカイブ REDO が要る。
挙動の流れ：
- ターゲット
CDB2でCREATE ... RELOCATEを実行すると、SALESはMOUNTED状態で作成される（まだオープンしていない）。この間、ソースCDB1側のSALESは READ WRITE のまま稼働を続け、ユーザーは更新できる。 - ターゲットで
ALTER PLUGGABLE DATABASE sales OPEN;を実行すると、移設が確定（finalize）する。差分が同期され、ソース側SALESはクローズされ、リスナーの接続転送によって既存接続が新しい場所へ引き継がれる（ダウンタイム最小）。
- A作成直後は
MOUNTEDであってREAD WRITEではない。移設はOPENで初めて確定する。「作成＝完了」ではない。 - Cそれはコールド（オフライン）クローン（
RELOCATEなしの単純クローン）の前提。RELOCATE／ホットクローンの主眼は「ソースを READ WRITE のまま」移すことにある。READ ONLY 化は不要。 - D逆。ホット（オンライン）な
RELOCATEはローカル UNDO が前提で、共有 UNDO ではできない。共有 UNDO 必須という説明は誤り。
ひっかけ： 「作成した時点でもう使える（A）」という思い込みと、ローカル UNDO ⇄ 共有 UNDO の前提の取り違え（B vs D）。
オンライン操作（ホットクローン／リロケート／PDB のオンライン化）はローカル UNDO が前提。また「ソースを READ ONLY にする必要があるか」はコールドクローン（必要）とリロケート/ホットクローン（不要）で分かれる。
実機確認の答え合わせ
SELECT open_mode FROM v$pdbs WHERE name='SALES'; → 作成直後は MOUNTED。 ALTER PLUGGABLE DATABASE sales OPEN; 後に READ WRITE となり、CDB1 側 SALES はクローズされる。
✓Gold 保有者による書き下ろし解説・実機で検証済