Oracle DBA Lesson 51B — Cut Over and Prove Destination Clients

A live pluggable database (PDB) relocation has a planned handoff: application work moves from the source container database (CDB) to the destination. The online copy has already finished in this exercise. Your task is to control the final source transactions, open the exact staged target, and establish that fresh application connections use the intended destination and can complete committed work.

Oracle DBA Lesson 51B — Cut Over and Prove Destination Clients

Acceptance combines database state, client identity, data checks, transaction behavior, measured interruption, and recovery readiness. Keep each result pending until it is observed in the designated lab.

Conditions for the worked example

Use two instructor-designated disposable Oracle Database 19c single-instance CDBs. Record the release/RU, the edition, and the platform. Both are in ARCHIVELOG. The source uses local undo. The ordinary, unencrypted PDB is LABPDB_RELOC. Its online relocation has already been created through the private COURSE_MOVE_SRC database link. That link belongs to its approved creator in the destination root and connects to a common user in the source CDB root. Reviewed OMF placement, free capacity, a compatible platform, options, and character sets, archive retention, and tested recovery are prerequisites from the preparation part.

The instructor has completed the documented source service and open-state preparation. Oracle's example ALTER PLUGGABLE DATABASE ALL SAVE STATE INSTANCES=ALL affects all source PDBs and instances. It belongs in a reviewed instructor runbook, with the previous settings recorded, rather than an unrelated learner change. This preparation supports target service startup. The baseline uses AVAILABILITY NORMAL, the default, and an explicit destination application service. Availability through an old endpoint requires its separately verified listener configuration.

Use these instructor-provided client aliases. Resolve them to the approved lab endpoints before connecting.

Alias or account	Purpose
SRC_ROOT, common administrator	Source CDB root identity and inventory
DEST_ROOT, common administrator	Destination CDB root identity, target opening, and inventory
SRC_APP, COURSE_OWNER	Source LABPDB_RELOC application connection before cutover
DEST_APP, COURSE_OWNER	Explicit destination application service after cutover

The application services and their listener registration must be provisioned and rehearsed. The course starter schema is installed in this disposable PDB, including RECOVERY_MARKER(marker_id, marker_text, created_at), EMPLOYEES, and ORDERS. Reserve unused marker IDs 51001 and 51002 for this exercise. Use a different recorded pair if either is already owned by another exercise. No new schema or general dictionary grant to COURSE_OWNER is required.

Opening from a root requires authentication AS SYSBACKUP, AS SYSDBA, AS SYSDG, or AS SYSOPER, with the relevant privilege granted commonly or locally in both the root and the target PDB. The example assumes a separately authorized common administrator authenticated AS SYSDBA. The privilege to create a PDB, and the temporary link user's privileges, are separate from authorization to open it. See ALTER PLUGGABLE DATABASE for the prerequisites.

Agree the application drain, transaction reconciliation, retry policy, acceptance criteria, stop criteria, and rehearsed recovery and reset procedure before this exercise. Concept teaching does not authorize use of a production database. Commands and expected interpretations here were checked against documentation. No database execution or measured outage is claimed.

1. Establish a final source commit

Stop new application requests and let in-flight work complete according to the runbook. Include background writers and jobs in the drain. Resolve open transactions explicitly with their owners. Session draining and reconnect behavior depend on the application's actual service and client configuration. Do not assume automatic replay of an unfinished transaction.

Connect through the source application service:

sqlplus -L course_owner@SRC_APP

SQL*Plus prompts for the account password. Verify the answering session:

SHOW USER
SHOW CON_NAME

SELECT SYS_CONTEXT('USERENV','DB_NAME') AS db_name,
       SYS_CONTEXT('USERENV','DB_UNIQUE_NAME') AS db_unique_name,
       SYS_CONTEXT('USERENV','CON_NAME') AS container_name,
       SYS_CONTEXT('USERENV','SERVICE_NAME') AS service_name
FROM dual;

SELECT marker_id, marker_text
FROM recovery_marker
WHERE marker_id IN (51001,51002);

The identity must match the source record and LABPDB_RELOC. Both reserved IDs must be absent before you create them. Stop if either is present until ownership and a different unused ID pair are resolved. After the final application work has completed:

INSERT INTO recovery_marker(marker_id, marker_text)
VALUES (51001, 'SOURCE_FINAL');
COMMIT;

SELECT marker_id, marker_text, created_at
FROM recovery_marker
WHERE marker_id = 51001;

SELECT COUNT(*) AS employee_rows, SUM(salary) AS salary_total
FROM employees;

SELECT COUNT(*) AS order_rows, SUM(amount) AS order_total
FROM orders;

SELECT order_id, customer_id, status, amount
FROM orders
WHERE order_id IN (1001,1002,1003)
ORDER BY order_id;

Retain the actual final marker, keys, values, and aggregate results as the source baseline. These SQL statements read the course tables. Use the application's real validation queries in a real migration runbook. COMMIT ends the transaction and makes its changes visible to subsequent statements in other sessions. A marker seen only in the inserting session before commit is insufficient evidence for this handoff. See COMMIT.

Keep writers stopped while collecting and comparing the final baseline. A changing source workload would invalidate a direct before-and-after count comparison.

2. Select the exact staged destination

In a separate session, connect with the approved common administrator. Substitute its actual account for the example name:

sqlplus -L 'c##course_admin@DEST_ROOT as sysdba'

SHOW CON_NAME
SELECT name, db_unique_name, log_mode FROM v$database;

SELECT name, RAWTOHEX(guid) AS pdb_guid,
       open_mode, restricted
FROM v$pdbs
WHERE name = 'LABPDB_RELOC';

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

Require CDB$ROOT, the approved destination DB_UNIQUE_NAME, and the target name and GUID recorded after the online copy. Match the GUID to the staged target record. This example makes no assumption that a source GUID and a target GUID are interchangeable.

The expected state before the first opening is MOUNTED from V$PDBS.OPEN_MODE and RELOCATING from DBA_PDBS.STATUS. A missing row, a wrong identity, an unexpected state, or an unresolved error stops the planned opening. V$PDBS reports the current instance's open state. DBA_PDBS reports catalog status. Keep them as separate observations. See V$PDBS, DBA_PDBS, and V$DATABASE.

3. Complete the approved cutover

After the final source commit, the application drain, and the identity and state gate are accepted, issue this statement once from the verified destination root:

ALTER PLUGGABLE DATABASE labpdb_reloc OPEN READ WRITE;

The opening performs the remaining recovery and handoff work, including source-session draining and closure, and destination opening. Capture the command result and inspect both database states if it returns an error or its outcome is uncertain. Persistent connections may terminate. The reconnect and retry policy must handle the actual client outcomes.

Repeat the destination inventory queries. Acceptance requires READ WRITE, catalog status NORMAL, the same recorded target GUID, and the intended access configuration. Inspect RESTRICTED, the opening result, alert-log errors, and unresolved plug-in findings where they are relevant. Resolve unexpected restrictions before the ordinary application test.

Through the independently identified source root, record the source inventory too:

SHOW CON_NAME
SELECT name, db_unique_name FROM v$database;

SELECT name, RAWTOHEX(guid) AS pdb_guid, open_mode, restricted
FROM v$pdbs
WHERE name = 'LABPDB_RELOC';

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

Record the actual rows, or the absence of a row, for the chosen release and configuration, and confirm that the original source has ceased serving writable application work. Interpret retained source artifacts through the documented relocation mode. Source metadata retirement is managed by relocation. This exercise gives no generic manual source DROP command. See relocating a PDB for the handoff stages and CREATE PLUGGABLE DATABASE for the RELOCATE clause.

4. Identify the database answering a fresh client

Start a new client process through the explicit destination application service. A pooled session already borrowed before cutover is a separate behavior to observe.

sqlplus -L course_owner@DEST_APP

SHOW USER
SELECT SYS_CONTEXT('USERENV','CON_NAME') AS container_name,
       SYS_CONTEXT('USERENV','DB_NAME') AS db_name,
       SYS_CONTEXT('USERENV','DB_UNIQUE_NAME') AS db_unique_name,
       SYS_CONTEXT('USERENV','SERVICE_NAME') AS service_name
FROM dual;

Expect the intended account, LABPDB_RELOC, the destination unique name, and the destination service. Compare these results with the independently captured destination-root V$DATABASE row and the target GUID inventory. DB_NAME can be shared by different databases. DB_UNIQUE_NAME distinguishes them. An alias or a hostname is routing information. The answering session's context establishes where this particular connection actually arrived. See SYS_CONTEXT for the USERENV attributes and DB_UNIQUE_NAME.

Inspect both listener and service registrations with the instructor's approved networking tools. Record the service name and the actual destination association. Never equate an unchanged connect string with successful client handoff.

5. Prove committed data and a new transaction

In that fresh destination session, repeat the source marker and application-baseline queries from step 1. Require the final 51001 / SOURCE_FINAL row and matching committed application values, with changes explained against the agreed drain boundary.

Test a small approved destination transaction using the unused second marker:

INSERT INTO recovery_marker(marker_id, marker_text)
VALUES (51002, 'TARGET_COMMIT');
COMMIT;

Start a second new COURSE_OWNER@DEST_APP client, repeat its identity query, then read both markers:

SELECT marker_id, marker_text, created_at
FROM recovery_marker
WHERE marker_id IN (51001,51002)
ORDER BY marker_id;

The final source marker tests committed data carried through the handoff. The second marker, read from another fresh session after commit, tests a new destination transaction and subsequent visibility. Complete the application's representative read, write, job, and outbound-dependency checks as appropriate. A scratch marker alone does not certify the whole application.

Record failed or uncertain commit outcomes before retrying. Use the application's idempotency or business keys, and its reconciliation procedure, to determine whether work committed. Blindly repeating DML can duplicate effects. These examples make no claim that arbitrary uncommitted source work survives, resumes, or is replayed automatically.

6. Measure interruption and establish recovery

Use actual application-level observations with synchronized clocks, or a single monotonic timing source:

T_source = last successful application operation against the source
T_target = first successful application operation against the verified target
Observed interruption = T_target − T_source

Record the planned request drain, probe cadence, connection errors, retry attempts, commit results, and the return to normal request processing. This measurement includes the controlled handoff interval and its probe resolution. It is not a promise of zero downtime. Record the command's duration separately from application availability.

After a successful handoff, take a new destination backup through the instructor's reviewed RMAN configuration. From the destination CDB root, an authorized common user with SYSBACKUP or SYSDBA can back up this PDB:

BACKUP PLUGGABLE DATABASE labpdb_reloc;
BACKUP ARCHIVELOG ALL;
LIST BACKUP OF PLUGGABLE DATABASE labpdb_reloc;

The root archive-log backup covers its archived logs and needs capacity and scope approval. With the database open and no UNTIL or SEQUENCE restriction, BACKUP ARCHIVELOG ALL also archives the current redo. A PDB data-file backup by itself does not include archived redo logs. Preserve the logs required for recovery, the destination root and control-file metadata, the approved parameter and control-file backup strategy, accessible backup pieces, and tested recovery instructions. Verify completed backup records and piece availability. Apply the rehearsed restore and recovery check to the new backup before releasing recovery dependencies. A LIST result is inventory evidence, with restore testing recorded separately. See backing up a database for PDB backups and archive-log requirements, and BACKUP for archive-log semantics.

Keep the temporary relocation link and the required source and archive recovery resources through understood relocation completion. Release them only through the approved completion and acceptance procedure.

Failure decisions depend on the handoff phase

Observed phase	Useful decision
Before target OPEN, the source still owns application writes	Inspect both inventories and diagnostics. Keep the application drained while resolving the staged target. Resume source service only after the runbook establishes its identity, consistency, and exclusive ownership.
OPEN failed, or its result is uncertain	Treat the outcome as unresolved. Capture destination and source open mode and catalog status, command and alert errors, client outcomes, and transaction evidence before any repeat, deletion, or resume.
Destination owns writes or has accepted new commits	Preserve newly committed work and use the rehearsed restore or supported reverse-migration plan, with its recovery point and data-loss decision. Gate every step on both actual database states and exclusive write ownership.
Destination is UNUSABLE after a creation or relocation error	Inspect its alert log and exact identity. Oracle documents UNUSABLE as a state that permits only dropping that PDB. Any target cleanup needs the state-specific runbook and preserved recovery. This does not authorize dropping the source.

Remaining source files are not an ordinary reopen-and-rollback path after relocation. An old source copy can be behind new destination commits, and its metadata and state have changed. Preserve recovery material and reconcile transaction ownership. Do not improvise two writable copies. Offline unplug and replug steps from the previous transfer lesson do not apply as a generic relocation reversal.

Conditional forwarding branch

The baseline explicitly connects to the destination. Oracle documents AVAILABILITY NORMAL with a shared listener, or with cross-registration in a common listener network, and with unique PDB service definitions. For isolated networks, AVAILABILITY MAX temporarily establishes forwarding while directory and client routes are changed. The MAX opening workflow can include an intermediate read-only period. Write attempts wait for a consistent read/write target.

In the documented MAX case, a source tombstone preserves the namespace and the forwarding configuration. Inspect its identity and catalog status with the appropriate views. Once all clients use verified direct destination routes and the forwarding transition is complete, an authorized and separately reviewed runbook may retire that exact tombstone. Do not assume a tombstone exists for every relocation, and do not drop a source PDB by name alone.

RAC and SCAN multi-redirect settings, Application Continuity and FAN, listener networks, and client support require their own exact conditions and rehearsal. Oracle's relocation chapter restricts the multiple-redirect setting to the relevant SCAN listeners and warns against setting it on node listeners. Those settings are outside this single-instance exercise. See relocating a PDB for the isolated and common listener stages.

Practice, pass criterion, and cleanup

Run this whole handoff once in the designated disposable pair after the preparation part is accepted. Keep separate, clearly identified root sessions and fresh application sessions. Record the source marker and baseline, the target identity and initial state, the command outcome, both post-states, the destination client identities, the final marker, the destination commit and readback, the functional checks, the actual interruption, and the new-backup recovery evidence.

Pass when all agreed evidence is observed and the learner can explain which database owns application writes, what each marker proves, and how a failure before opening differs from a failure after destination commits. Mark unperformed client, backup, or restore checks as pending. Viewing the video alone does not complete this practical.

After acceptance and evidence capture, clean up only the two marker rows created by this exercise, through the verified destination application connection:

DELETE FROM recovery_marker
WHERE (marker_id = 51001 AND marker_text = 'SOURCE_FINAL')
   OR (marker_id = 51002 AND marker_text = 'TARGET_COMMIT');
COMMIT;

First confirm their recorded ownership. Inspect the affected row count and retain the evidence. Leave starter rows and unrelated exercises intact.

After relocation completion and release approval, the original private-link owner can remove only its temporary destination-root link:

DROP DATABASE LINK course_move_src;

The instructor separately retires only the temporary source access and grants it created, restores any exercise-owned service and settings changes as the runbook requires, and resets disposable lab assets through the rehearsed recovery and reset procedure. Keep archive logs, backup pieces, and source recovery assets until their retention gate is satisfied. Do not delete OMF files or issue a generic source DROP as cleanup.

Recap

Finish the source drain and record the final committed marker before opening. Open the staged destination only when its name and GUID match the recorded target, then require READ WRITE, catalog status NORMAL, and a source that has stopped writable application work. A fresh destination client must show the destination unique name and service, the carried SOURCE_FINAL row, and a TARGET_COMMIT row read from another session after commit. Measure the actual interruption, then back up the destination PDB and the archived logs. Before opening, the source still owns application writes. After the destination has accepted commits, preserve that work and use the rehearsed restore or reverse-migration plan.

Quiz

1. Can an unchanged connection string alone prove that relocation preserved application availability?

Yes, because the text of the route stayed the same Yes, if the target opening command returned No; verify fresh connection identity, committed data and client/transaction behavior Yes, if a listener process is running

2. What does successful target OPEN READ WRITE complete in relocation?

The remaining recovery and source-to-destination handoff Creation of an XML unplug descriptor A promise that every unfinished source transaction is replayed A backup of the new target

3. Why compare a fresh client's DB_UNIQUE_NAME with independently captured destination-root evidence?

It changes the client's service It distinguishes the intended database even when DB_NAME is shared It gives the application account SYSDBA It restarts the source listener

4. Which check establishes visibility of a new destination commit?

Read the inserted row in the inserting session before commit Compare only the source hostname Insert an approved marker, commit it, then read it through another fresh destination session Count listener processes

5. The destination has accepted writes and a later validation fails. What is the appropriate recovery decision?

Reopen whichever old source files remain Drop the source PDB immediately Repeat the failed client write until it succeeds Preserve new work, inspect both states, and use the rehearsed restore or reverse-migration plan

Commands and expected interpretations here were checked against documentation. No database execution or measured outage is claimed. Run this handoff in the designated disposable Oracle Database 19c pair and record the actual observations.

AIOps Pro

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