Oracle DBA Lesson 50B — Check Whether a CDB Can Accept a PDB

A transfer needs a clear compatibility decision before target creation. Start with the exact preserved descriptor, the source file inventory, and the intended destination. Use DBMS_PDB.CHECK_PLUG_COMPATIBILITY to compare the described PDB with that destination, then read its detailed findings. A useful decision records the blocking fact, its remedy, and the checks that remain.

Oracle DBA Lesson 50B — Check Whether a CDB Can Accept a PDB

This lesson covers the pre-creation decision. Preserve and unplug work precedes it. The approved source metadata retirement, target creation, first opening, and application validation are separate stages. The examples here create no target and move no database files. The function can write diagnostic rows in the destination dictionary, so the optional exercise needs authorization even though it leaves the preserved source files in place.

Set the example conditions

Use an instructor-designated disposable Oracle Database 19c, single-instance primary CDB on Linux. The ordinary example concerns a previously unplugged, normal PDB named LABPDB_MOVE, with its descriptor at the fictional server-side path /lab/transfer/labpdb_move.xml. This path belongs on the designated database host; it is not the course workspace. The destination Oracle software owner must be able to read the descriptor and the preserved files. Resolve every path against the actual lab before execution.

The main case assumes matching source and destination 19c Release Updates, compatible installed options, the same platform endianness, an approved character-set combination, and no encrypted data or PDB keystore. It uses a protected XML plus a separately preserved permanent-file set. Retain the approved pre-change recovery evidence, source identifiers, descriptor, and post-unplug file checksums. XML describes the PDB; recovery also depends on the retained files, backups, and any required keys.

Use the authorized destination-root administrator. The documented package requirement is EXECUTE on SYS.DBMS_PDB. The account also needs narrowly delegated read access to PDB_PLUG_IN_VIOLATIONS and each inventory view it uses. A common account's current container must be the destination CDB$ROOT. This function check alone does not require creating a PDB; target-creation and open privileges belong to those later procedures. Ask the instructor to provision the required permissions rather than granting broad roles as part of this exercise. See DBMS_PDB for the package security model and function parameters.

Confirm identity before running the function:

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','SESSION_USER') AS session_user
FROM dual;

SHOW is a SQL*Plus command. Match the returned database identity and CDB$ROOT with the approved destination. An incorrect destination changes the meaning of the compatibility decision. Confirm that the proposed name is unused in that destination and in the relevant listener namespace; retain the actual result:

SELECT name, con_id, guid, open_mode
FROM v$pdbs
WHERE name = 'LABPDB_MOVE';

An empty result here supports the destination-CDB name check under the account's documented view access. The instructor must separately verify the listener naming scope. See CREATE PLUGGABLE DATABASE for target-name uniqueness.

Compare the requirements

Prepare a short source and destination inventory before interpreting the function:

Item	Decision to record
Database release and Release Update	Record the exact source and destination software versions and SQL patch state; identify a same-release patch procedure or a separately approved release-upgrade plan.
Installed database options and components	Source installed options must be present in the destination; verify component and entitlement requirements for the actual environment.
Platform and endian format	The ordinary plug route requires matching endianness. Select a separately documented transport or conversion procedure for a different format.
Database and national character sets	Verify the documented combination. A non-AL32UTF8 destination has character-set compatibility requirements; the general plug guide provides an AL32UTF8 destination exception. Application-container rules are separate.
Encryption and keys	For encrypted material, select the exact united, isolated, or external-keystore procedure and establish key availability. The unencrypted example avoids that branch.
Descriptor and file locations	Match the protected descriptor with its permanent-file inventory; confirm destination software-owner access and planned source-path mapping.

See Plugging In an Unplugged PDB for these platform, option, and character-set conditions. Installed features alone are not evidence of license entitlement. Higher-release to lower-release automatic plugging is unsupported; stop that route and choose a supported destination or a different approved migration design. A release upgrade is different from applying a Release Update within 19c.

Inventory queries must run in the intended source or destination scope, with the corresponding authorized account:

SELECT banner_full FROM v$version;
SELECT patch_id, patch_type, action, status, action_time, description
FROM dba_registry_sqlpatch
ORDER BY action_time;
SELECT comp_id, comp_name, version, status
FROM dba_registry
ORDER BY comp_id;
SELECT parameter, value
FROM nls_database_parameters
WHERE parameter IN ('NLS_CHARACTERSET', 'NLS_NCHAR_CHARACTERSET');

The patch view reports SQL patch attempts and outcomes; retain successful and unsuccessful entries with their timestamps. Capture the relevant PDB's SQL patch and component state from the source evidence obtained before unplugging, and the target root's actual state. Inventory Oracle-home binaries separately through the instructor's patch procedure. The XML and pre-unplug records remain the source evidence while it is unplugged; do not attempt an ordinary OPEN to collect new rows from that state. See DBA_REGISTRY_SQLPATCH for patch status and DBA_REGISTRY for registered components.

Run the compatibility function

In the verified destination root, run the approved descriptor and name pair:

SET SERVEROUTPUT ON
BEGIN
  IF DBMS_PDB.CHECK_PLUG_COMPATIBILITY(
       pdb_descr_file => '/lab/transfer/labpdb_move.xml',
       pdb_name       => 'LABPDB_MOVE') THEN
    DBMS_OUTPUT.PUT_LINE('Compatible');
  ELSE
    DBMS_OUTPUT.PUT_LINE('Review plug-in violations');
  END IF;
END;
/

SET SERVEROUTPUT ON tells SQL*Plus to display the DBMS_OUTPUT messages. The slash executes the anonymous PL/SQL block. pdb_descr_file selects the server-side descriptor; pdb_name selects the intended new name. Omitting the latter uses the descriptor's name. The function returns a PL/SQL BOOLEAN, so this block converts it into a readable printed branch; it is not a SQL result column selected from DUAL.

Compatible means the function returned TRUE for this descriptor and current destination. Review plug-in violations means it returned FALSE. A raised exception is a failed or incomplete check, not either successful printed outcome. Preserve the full error and correct the descriptor access, permissions, or other reported issue before retrying.

The function records integration diagnostics. It neither issues target CREATE nor adopts, copies, or moves the preserved files. Review detailed findings with either boolean result. A report tagged with the PDB name and date keeps the conclusion tied to the exact destination and descriptor version.

Read the detailed findings

SET LINESIZE 200
SET PAGESIZE 100
COLUMN message FORMAT A65 WORD_WRAPPED
COLUMN action  FORMAT A65 WORD_WRAPPED
SELECT time, name, cause, type, status, message, action
FROM pdb_plug_in_violations
WHERE name = 'LABPDB_MOVE'
  AND (status <> 'RESOLVED' OR status IS NULL)
ORDER BY time, cause, line;

The extra IS NULL retains any row whose nullable status has not been assigned. The simpler status <> 'RESOLVED' filter retains both PENDING and IGNORE. Avoid converting IGNORE into a claim of repair. Preserve the complete message and action text when wrapping the report; short on-screen summaries can omit the fact that determines the remedy.

Field	How it helps the decision
TIME, NAME	Tie a finding to its reported time and intended PDB name. Retain earlier runs and identify which report belongs to the current check.
CAUSE, LINE	Identify the checked attribute and distinguish multiple findings with the same cause.
TYPE	Severity is ERROR or WARNING. An ordinary unresolved error is a stop condition. A warning still needs documented treatment.
STATUS	The documented values are PENDING, RESOLVED, and IGNORE; retain and explain any other or empty observed status.
MESSAGE	Read the actual mismatch and the source and target details.
ACTION	Use the corrective direction with the documentation for the exact release, RU, and transfer branch.

The view can contain findings for an intended PDB before it exists. See PDB_PLUG_IN_VIOLATIONS for these fields and the function's diagnostic use.

Remediate the cause, then repeat the check when the relevant environment or source descriptor changes. When source remediation changes its metadata, use a freshly and validly generated descriptor from the rehearsed source recovery or replug procedure; retain the earlier descriptor and report as evidence. Do not edit XML fields merely to hide a mismatch. If a documented warning requires a later controlled integration or patch step, record that exact dependency and approval in the transfer plan rather than treating it as already resolved. An ordinary transfer uses no generic conversion script. noncdb_to_pdb.sql belongs to non-CDB adoption, a different source architecture.

Interpret two saved cases

The following are authored reasoning examples, not database output. Message and action descriptions are paraphrases, not promised Oracle message text. In practice, use the instructor's protected descriptor and genuine saved report for each case. Names, versions, paths, and reported findings must match those records.

Saved case	Provided evidence	Decision
A — ordinary 19c match	Matching platform and approved 19c, RU, component, and character-set inventories; no TDE. The supplied completed check has TRUE and its report has no unresolved items. Files match the preserved inventory.	Record the database compatibility decision. Complete the source-file access and mapping and the planned application and recovery handoff checks before proceeding with the separately approved plug procedure.
B — unsupported release direction	The supplied descriptor is from a higher database release than the 19c target. A provided completed check and report identifies the version mismatch as an ERROR, PENDING; the action calls for a compatible destination.	Stop this ordinary plug route. Choose a supported destination and obtain a fresh destination check. Merely retrying the same incompatible pair leaves the blocking fact unchanged.

A descriptor from a newer architecture or release can also raise an exception rather than yield a completed check; preserve that actual outcome and stop. The lesson does not fabricate an executable incompatible descriptor or assume every release mismatch produces identical rows.

For a patch-related WARNING or ERROR, write down the precise source and target binary and SQL patch differences and follow the applicable RU readme and action. Datapatch and release-upgrade tools have different purposes and prerequisites; choose the documented stage. The approved ordinary exercise already uses matching 19c Release Updates and requires no speculative patch or upgrade execution.

Confirm paths independently

The compatibility signature has no source-path mapping argument. Match every XML-listed permanent file against its preserved inventory and confirm actual access. If files were staged at a new location, plan the source-location clause for the later creation statement. For example, this clause fragment identifies relocated input files:

SOURCE_FILE_NAME_CONVERT =
  ('/source/labpdb_move/', '/lab/transfer/files/')

The first pattern is the location in XML; the second is the actual staged source location. This clause belongs to CREATE PLUGGABLE DATABASE ... USING, not the compatibility function. File-name patterns cannot match files or directories managed by OMF. A documented alternative, when all input files are in one directory, is:

SOURCE_FILE_DIRECTORY = '/lab/transfer/files/'

These two source-location clauses are mutually exclusive. Resolve exact file identities and directory contents in the lab; use the appropriate OMF-supported branch instead of guessing a filename pattern. Destination output placement is a separate decision through OMF or its applicable file conversion clause. See CREATE PLUGGABLE DATABASE for these source-location semantics.

For encrypted files, stop the unencrypted example and prepare the matching key procedure. See Managing keystores and encryption keys in united mode for encrypted PDB unplug and plug. Isolated and external keystores have their own requirements. Required database encryption keys and application secrets need separate handling. Keep jobs, outbound routes, and client services contained until the application handoff is validated.

Independent practice and cleanup

1. Receive two protected saved descriptor and report pairs and their source and destination inventories: one compatible, one intentionally incompatible. Identify their exact release and RU, PDB name, GUID, destination identity, and report time.
2. Explain the completed boolean or exception. Read every unresolved finding. Record severity and status, the exact mismatch, the documented remedy, the responsible owner, and whether a new descriptor or destination check is required.
3. Match descriptor-listed permanent files to the protected inventory. Explain any source-location mapping and its separate destination placement decision. Preserve the original descriptor and file set.
4. Write a transfer decision: proceed to the approved plug stage, wait for a named remedial action, or choose a different supported workflow. List the remaining application job, service, and credential checks and the recovery evidence.
5. Optionally, with instructor authorization and the specified package and view permissions, run only the compatibility block and report in the disposable destination root. Record actual results and compare them with the supplied fixture. Do not create, open, or drop a PDB or mutate source files in this part.

Pass when the learner identifies the exact blocking fact in case B, gives a supported remedy, requests the appropriate new check, and separates database compatibility from file, application, and recovery readiness. Without actual authorized execution, record the exercise as saved-evidence interpretation.

Retain the non-secret report and exact protected descriptor. Stop SQL*Plus spooling when finished; close the session and release temporary privileges only through the instructor's account process. Diagnostic rows are dictionary evidence: leave them under Oracle's management; do not update or delete them to manufacture a clean report. No PDB removal is part of this exercise.

If the transfer is cancelled, retain or return staged copies to the agreed protected retention location using the instructor's inventory and ownership checks. Source data remains preserved. A source that is already unplugged needs its rehearsed replug or recovery procedure; retain the agreed outage and recovery responsibility until that procedure completes. Source metadata retirement must occur in the approved sequence before target plugging, with exact-source identity and permanent-file preservation controls. It is not an action taken by the compatibility check.

Recap

Compare requirements, check the exact descriptor and name, read and treat findings, then confirm file access and mapping before the approved plug procedure. Application jobs and services require their own validated handoff.

Quiz

1. Where does this check compare the preserved descriptor with the intended destination?

In the source application schema. In the intended destination CDB$ROOT. In an arbitrary opened PDB. In the SQL*Plus client filesystem only.

2. The block prints Compatible. What is the useful next step?

Skip all detailed findings. Drop all source files immediately. Review unresolved findings and the remaining transfer conditions. Declare application handoff complete.

3. Which finding fields connect the mismatch to its remedy?

MESSAGE and ACTION, interpreted with TYPE and STATUS. Only the proposed PDB name. Only the number of returned rows. The SQL*Plus page size.

4. What should happen when a source database release is higher than the intended destination release?

Rename the XML so it looks older. Retry unchanged until it succeeds. Run a generic conversion script. Stop the ordinary plug route and choose a supported destination or approved migration design.

5. The preserved input files are staged under a new directory. What distinguishes the planned source mapping from this function call?

The function automatically rewrites and moves them. A source-location clause in the later creation statement locates them; independently verify the inventory and access. Source mapping is the same as granting application access. XML contains every data block, so file locations are irrelevant.

These are documentation-reviewed teaching examples. No database was connected to, and no SQL or file transfer was executed while preparing this lesson. Actual lab results depend on the precise release and RU, platform, privileges, descriptor, and protected file set.

AIOps Pro

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