LEARN. PRACTICE. GROW.Concept and mechanism
An application PDB can consume an application managed in an application root. Installing or upgrading that root does not mean every application PDB has synchronized; plan the intended version and inspect each state. Cloning a PDB also requires consistency, capacity, and access prerequisites. In documented hot cloning, ARCHIVELOG and local undo allow the source to remain operational in READ WRITE; required logs must remain available during the operation. Do not generalize this workflow to every undo mode or older installation. Transport between environments requires compatibility, component, file, and encryption checks before users connect. A copied file is only one part of a usable destination.
Guided application
In a fictional migration project, create a matrix of source, destination, version, encryption mode, owners, and validation criteria. A copy with warnings should not be accepted merely because it opened. Investigate incompatibilities and test representative operations. Keys and keystores need protection and a recovery path separate from data; a new empty keystore does not decrypt an earlier backup. Lockdown profiles can restrict capabilities in configured scope but do not supply missing privileges. Finally, compare a local intervention with a CDB root change: the latter may affect other services and require broader coordination. Record impact, acceptance evidence, and the return path in the change decision.
Fictional migration: application PDB version, synchronization state, grants, and service require separate validation.
Common pitfalls
Assumed SYNC; hot cloning without prerequisites; files without keys; root as default destination.
Related topics: Containers, services, and resources · Backup and recovery evidence · Selective recovery and isolated rehearsals
Accept a PDB through demonstrated compatibility and operation.
Reference: Hot PDB cloning · 1Z0-183 public objectives inspected 2026-09-30; revision date not published