Oracle DBA Lesson 51A — Prepare a Live PDB Move

Relocation moves a pluggable database (PDB) into another container database (CDB) while much of the copying happens with the source still serving its application. This part explains the online copy, the destination's waiting state, and the decision required before opening the destination. The practical outcome is a runbook that identifies who is serving the application at each stage and where to stop if the evidence is incomplete.

Oracle DBA Lesson 51A — Prepare a Live PDB Move

Understand the two stages

CREATE PLUGGABLE DATABASE ... FROM ... RELOCATE starts an online block-level copy. Oracle transfers data blocks, redo, and undo through a database link. During this stage, existing sessions and new connections continue using the source PDB. Redo records changes; undo helps produce transactionally consistent data. Oracle's relocation process uses these records while preparing the destination copy.

Successful creation leaves the destination mounted, with catalog status RELOCATING. This is the waiting phase before the planned handoff. The source remains the application database during this phase.

Opening the destination initiates the consequential cutover. Oracle completes recovery to its final change boundary, starts draining source sessions, closes the source PDB, and opens the destination read/write. Applications need a rehearsed drain, reconnect, and transaction-error procedure. Measure the actual application interruption in that rehearsal; online copying alone supplies no fixed outage duration.

Stage	Source application database	Destination PDB	Decision
Before copying	Source serves normally	Target name is unused	Verify prerequisites and recovery
Online copy	Existing sessions and new connections use source	Files and change records are copied	Monitor copy and retain required logs
Successful CREATE ... RELOCATE	Source continues serving	MOUNTED / RELOCATING	Review both databases before opening
Planned target opening	Source sessions drain and source closes	Recovery completes; target opens read/write	Follow the approved cutover and reconnect plan

These are expected stages under the stated Oracle 19c baseline. Record the actual states and errors in the lab. See Relocating a PDB for the copy and opening stages.

Conditions for the worked example

Use an instructor-designated disposable lab with two Oracle Database 19c single-instance CDBs. Record the actual Release Update, edition, platform, and applicable feature entitlement. This example concerns an ordinary PDB, rather than an application PDB, RAC, Data Guard, or an upgrade. The source PDB is named LABPDB_RELOC and is disposable. The same name is unused in the destination CDB. Verify service names are unique in any shared listener network.

The instructor must establish these conditions before permitting the mutating example:

• Both lab CDBs are open read/write and run in ARCHIVELOG mode. Required archived logs remain available throughout copying, cutover, and the agreed recovery retention period.
• The source CDB uses local undo. Its LABPDB_RELOC is open READ WRITE so the example can illustrate online copying.
• The documented source service/open-state preparation has been completed and recorded. The relocation guide specifies ALTER PLUGGABLE DATABASE ALL SAVE STATE INSTANCES=ALL from the source root. This has broad scope across source PDBs and instances; the instructor reviews the initial saved states and owns this setup. Its purpose is to allow relocation to start the PDB services in the destination. These notes do not claim that the command was executed.
• The destination-root common administrator has CREATE PLUGGABLE DATABASE in that root. The opening administrator for the subsequent cutover needs the separately documented administrative authority for ALTER PLUGGABLE DATABASE ... OPEN; the creation privilege alone is insufficient for that action.
• An existing private COURSE_MOVE_SRC link is owned by the destination-root identity executing the example. It connects from the destination CDB root to the source CDB root. Its source common account has the documented CREATE PLUGGABLE DATABASE system privilege or SYSOPER administrative privilege, with the required login/authentication setup. Dictionary queries require their own delegated read access.
• The platforms have matching endianness. Source installed options are present at the destination. Release/RU and character-set compatibility are reviewed. Oracle's relocation guide gives the specific prerequisites and the applicable character-set rule, including the destination AL32UTF8 case.
• The simple example uses unencrypted files and no set TDE master key/keystore requirement. Encryption, Database Vault, or other special configurations require their exact additional procedure before proceeding.
• Oracle Managed Files is configured at the destination, with a verified suitable DB_CREATE_FILE_DEST, available storage, and tempfile/name conditions. Allow capacity for the copy, growth during copying, and recovery requirements. A configured directory alone supplies no capacity evidence.
• The instructor has rehearsed source restoration, retained backups and required logs, and documented the recovery target and service ownership. The application team has specified the stop/drain, retry, destination-service routing, acceptance, and post-cutover recovery plan.

See Overview of PDB Creation for general creation prerequisites, file placement, names, and services. See ALTER PLUGGABLE DATABASE for opening authority and saved-state syntax.

The both-ARCHIVELOG requirement defines this online lab baseline. It should not be generalized to every relocation variant. See CREATE PLUGGABLE DATABASE for the FROM rules that distinguish a read/write hot copy from source conditions requiring read-only access.

Record identity before starting

In separately labeled source-root and destination-root administrative sessions, capture:

SHOW USER
SHOW CON_NAME

SELECT name, db_unique_name, cdb, open_mode, log_mode
FROM v$database;

SELECT pdb_name, RAWTOHEX(guid) AS pdb_guid, status
FROM dba_pdbs
WHERE pdb_name = 'LABPDB_RELOC';

SELECT name, open_mode, restricted
FROM v$pdbs
WHERE name = 'LABPDB_RELOC';

SHOW is a SQL*Plus command; the SELECT statements run in Oracle. Confirm CDB$ROOT and each actual DB_UNIQUE_NAME against the instructor's approved source/destination record. Before copying, the source query should identify the intended source PDB. The destination query should find no existing PDB with that name. A wrong identity, an unexpected row, or an unavailable observation stops the exercise.

Read the source CDB's undo mode from its root:

SELECT property_name, property_value
FROM database_properties
WHERE property_name = 'LOCAL_UNDO_ENABLED';

TRUE indicates local undo. This query observes the configuration; changing undo mode requires a separate CDB procedure and restart. See Administering a CDB for current-container scope and the root undo-mode query.

As the destination-root link owner, inspect the existing private link:

SELECT db_link, username, host
FROM user_db_links
WHERE db_link = 'COURSE_MOVE_SRC'
   OR db_link LIKE 'COURSE_MOVE_SRC.%';

DB_LINK identifies the link, including any domain suffix. USERNAME identifies its source account; HOST holds the Oracle Net connect string. Resolve the exact returned link name and source-root service, and compare them with the approved configuration. Link metadata alone is configuration evidence. The instructor must also prove connectivity, remote root scope, account authority, and source identity through separately recorded lab checks. This example reuses that verified link; it contains no credential-provisioning command. See USER_DB_LINKS and ALL_DB_LINKS for the view and columns.

Start the online copy

After all prerequisites pass, use the destination root, as the authorized owner of the private link:

CREATE PLUGGABLE DATABASE labpdb_reloc
  FROM labpdb_reloc@course_move_src RELOCATE;

The first name is the destination PDB name. FROM labpdb_reloc@course_move_src selects the source PDB through the verified link. RELOCATE prepares the database ownership move. Oracle Managed Files supplies the previously reviewed destination locations, which is why the example omits a path-conversion clause.

Omitting AVAILABILITY uses its NORMAL default. This lab uses an explicitly reviewed destination application service at cutover. Its service-routing acceptance test is required separately from SQL creation. It does not assume that an unchanged application connection string works across independent listeners. See CREATE PLUGGABLE DATABASE for FROM, RELOCATE, the availability default, and additional file and key clauses.

DDL changes require their own cleanup/recovery procedure. A transaction ROLLBACK is not the reversal plan for relocation.

Interpret the waiting target

In the same verified destination root:

SELECT name, open_mode
FROM v$pdbs
WHERE name = 'LABPDB_RELOC';

SELECT pdb_name, status, RAWTOHEX(guid) AS target_guid
FROM dba_pdbs
WHERE pdb_name = 'LABPDB_RELOC';

Expected observations after successful creation, before target opening, are:

Query evidence	Expected observation	Meaning
V$PDBS.OPEN_MODE	MOUNTED	Destination has reached its pre-opening state
DBA_PDBS.STATUS	RELOCATING	Relocation is awaiting completion through target opening
DBA_PDBS.GUID	Actual recorded target GUID	Identifies the staged target for subsequent checks

These are documented expectations, not captured execution output. Record the actual target GUID with the destination CDB identity. Subsequent checks compare it with this staged target record; do not infer a source/target GUID relationship from the PDB name alone.

Use separate source-root and source-application evidence to confirm that the intended source continues serving. Review copying errors and the alert log, log availability, target capacity, application drain readiness, destination-service routing, and recovery readiness. If any item fails, hold target OPEN and identify the stage reached in both databases.

The open mode and catalog status are different observations. See V$PDBS for the current instance's open mode and DBA_PDBS for the catalog state and GUID.

Decide whether to cross the cutover boundary

Target opening completes the relocation. During that operation, source sessions are drained or terminated under the relocation procedure, the source closes, and the target opens read/write. Preserve committed application evidence, finish the planned drain, and establish the reconnect route before this stage. Active transactions require the application's tested error/retry handling and any separately configured continuity features.

Record copy start/end, planned drain start, target-opening start/end, disconnect/retry events, and the first accepted destination application transaction as separate observations. These times answer different questions. The observed application interruption is the interval defined by the application's acceptance criterion, not automatically the copy duration.

This part ends at the reviewed decision gate. The complete opening command, final committed marker, fresh destination-client identity/data/transaction checks, and new target backup belong to the cutover exercise.

Failure, recovery, and cleanup depend on the phase

Observed phase	Required action
Preflight fails before creation	Correct the named prerequisite or stop. Preserve the source and its recorded recovery point.
CREATE ... RELOCATE returns an error	Capture the exact error, both CDB identities/states, source availability, and target alert-log findings. Establish whether copying is still active before cleanup or retry.
Target remains UNUSABLE after failed creation	Oracle documents that a persistent unusable target can only be dropped before the name can be reused. The instructor first confirms the failed operation has ended, the source/recovery evidence, and the exact exercise-owned destination object/files. Use the reviewed cleanup procedure; avoid guessed-stage deletion.
Target waits MOUNTED / RELOCATING	Keep source service and recovery dependencies available. Proceed only after the cutover gate passes, or use the instructor's verified cancellation/reset plan.
Target opening has begun, or ownership is uncertain	Stop further state-changing attempts. Establish actual source/target state and routing before applying the rehearsed recovery procedure.
Cutover completes but application acceptance fails	Follow the rehearsed restore or reverse-migration plan, preserving the chosen recovery target and single authoritative writer. Reopening leftover source files is not an established reversal procedure.

During preparation, retain the staged destination and the existing private link for the planned cutover. After full relocation, destination acceptance, and a verified target backup, the instructor removes exercise-only temporary access and resets the disposable lab according to the actual state. An existing shared course link/account is retained unless its owner explicitly schedules its retirement. Preserve backups, required logs, and recovery evidence until the agreed retention/acceptance conditions pass. Record any source saved-state changes and have their owner restore the approved settings where needed.

Relocation uses its own source/destination lifecycle. The offline descriptor-transfer procedure from unplugging lessons is not a recovery recipe for an online relocation. See Relocating a PDB for failure handling.

Conditional listener-forwarding branch

AVAILABILITY MAX is a separate design for independent listener networks without cross-registration. Oracle describes temporary forwarding at the old listener and a source tombstone retaining namespace/forwarding information while connection strings or directory naming are updated. An authorized team must verify that exact listener topology, routing, service names, and client behavior before choosing the branch. It supplies no blanket guarantee for every active transaction.

The guide allows dropping the tombstone after applications use direct destination connections. Verify the actual source catalog state and routing evidence before that conditional cleanup. A generic manual source DROP is absent from this part's NORMAL exercise. RAC SCAN multiple-redirect settings are outside this single-instance example and require their own documented review. See Relocating a PDB, in the isolated listener networks section, for listener variants and the branch conditions.

Independent practice

First write the runbook without changing a database. Identify the exact source/destination DB_UNIQUE_NAME, source PDB name/GUID, proposed target name, private-link owner/source user/root service, archive-retention and storage requirements, drain/reconnect owner, stop conditions, recovery target, and cleanup ownership.

In the designated disposable lab, collect preflight evidence and run the copy only after instructor approval. Record actual target MOUNTED / RELOCATING and its GUID, then independently verify source availability. Stop at the pre-opening gate for this practice. State what evidence is still required for the full cutover exercise.

Pass criterion: you correctly explain who serves during copying, identify target OPEN as the ownership boundary, hold the handoff when a prerequisite fails, and describe a tested restore-based recovery path for a failed post-cutover handoff. Capture commands, actual outputs/errors, interpretations, and cleanup/reset outcome. A documentation-only exercise is recorded as such.

Recap

During the online copy, existing sessions and new connections continue on the source PDB. Successful CREATE ... RELOCATE leaves the destination mounted, with catalog status RELOCATING. Opening the destination is the ownership boundary: recovery completes, source sessions drain, the source closes, and the target opens read/write. Hold that opening when the evidence is incomplete. If application acceptance fails after cutover, follow the rehearsed restore or reverse-migration plan and keep a single authoritative writer.

Quiz

1. Does successful CREATE ... RELOCATE mean the source application has already been handed over?

Yes, the destination immediately serves writes No; inspect MOUNTED / RELOCATING, then plan the consequential target opening Yes, provided the two PDB names match No; an XML unplug descriptor must be plugged in first

2. Which link matches this ordinary-PDB relocation baseline?

A private link in the source PDB pointing at the target PDB A link in the destination root pointing at a source local application user A private destination-root link to the source CDB root using a qualified common source account A public link whose service identity has not been checked

3. Which preparation supports this live read/write source copy?

Source shared undo and deletion of archived logs Source local undo and ARCHIVELOG, an open READ WRITE PDB, and the documented service/open-state preparation A closed source PDB and an arbitrary destination directory A matching PDB name without recovery evidence

4. Which observation pairs establish the expected waiting target after successful creation?

V$PDBS.OPEN_MODE = MOUNTED and DBA_PDBS.STATUS = RELOCATING V$PDBS.OPEN_MODE = READ WRITE and DBA_PDBS.STATUS = UNPLUGGED A client hostname and an unchanged connect string The copy command text without querying either CDB

5. Target opening has started and application checks fail. What is the sound next action?

Repeat CREATE immediately with the same name Open any remaining source files for writes Drop the source because every relocation leaves the same tombstone Establish actual state/routing and follow the rehearsed phase-specific recovery plan

All commands and observations here are teaching examples reviewed against Oracle documentation. No database connection or lab execution is claimed.

AIOps Pro

https://www.apps-dba.com/ https://x.com/AIOpsPro https://www.youtube.com/@AIOpsPro