A migration choice starts with the required application result, source and target compatibility, the allowable interruption, and the evidence for accepting the target. This lesson uses an existing Oracle Database 19c non-CDB and a planned 19c target CDB. The goal is to select an approach for moving the application into a PDB and to explain the conditions that support that choice.
Oracle DBA Lesson 53A — Choosing a Non-CDB Migration Approach
A non-CDB is a legacy database architecture in this exercise. It is the source being migrated. The course's ordinary lab remains multitenant. Earlier-release sources require a separately reviewed, supported upgrade or migration path. The procedures for generating a descriptor, copying files, and converting the dictionary belong to the physical execution runbook.
Compare three approaches
| Approach | What moves | Useful reason to consider it | Planning work |
|---|---|---|---|
| Physical adoption or supported non-CDB clone | A compatible database file set. Dictionary integration makes it usable in the target container. | The required result is the existing application database with compatible files. | Verify compatibility, copied-file capacity, source consistency, conversion, service cutover, and recovery. |
| Logical Data Pump | Selected data and object metadata, imported into an existing target PDB. | Select schemas or objects, or make supported logical remapping changes. | Define the export and import scope, the consistency point, account and tablespace mapping, external dependencies, and measured duration. |
| Engineered replication, such as a supported Oracle GoldenGate topology | Initial data plus ongoing changes applied to the target. | A justified interruption requirement warrants a synchronization system. | Verify supported objects and types, row identification, logging, licensing, operational ownership, convergence, and cutover correctness. |
See non-CDB adoption and cloning options, Data Pump movement from a non-CDB into a PDB, and replication followed by switchover when the target is current.
Data Pump connects to the intended target PDB for the import. Its database-level operations have that PDB's scope. Plan services and account and grant changes explicitly. Full transportable export and import is a separate assessed variant with its own eligibility and platform requirements. This comparison teaches ordinary logical Data Pump rather than a full transportable procedure.
Replication can reduce the final transfer interval when the engineered system keeps up with the workload. The cutover interval must be measured for the actual topology and workload. See GoldenGate preparation and supported objects and data types for requirements that affect correctness. Confirm the actual entitlement using the applicable agreements and Oracle's licensing information.
Read three inventory reports
Run these read-only queries only against the designated source, using the instructor-provisioned administrative identity with access to the views. Confirm database identity and the source context first. The exercise also needs the corresponding target inventory. SELECT reads existing information. None of the queries changes the open mode, logging mode, character sets, or components.
Database identity and current state
SELECT name, cdb, open_mode, log_mode
FROM v$database;For an authored example, suppose the report contains:
| NAME | CDB | OPEN_MODE | LOG_MODE |
|---|---|---|---|
| LEGACY | NO | READ WRITE | ARCHIVELOG |
NAME identifies the database. CDB=NO identifies a non-CDB in this baseline. OPEN_MODE=READ WRITE describes its current open state. LOG_MODE=ARCHIVELOG describes its configured archive logging mode. Record the actual source state, then plan the state changes required by the selected migration procedure. See V$DATABASE for each field.
Database and national character sets
SELECT parameter, value
FROM nls_database_parameters
WHERE parameter IN ('NLS_CHARACTERSET','NLS_NCHAR_CHARACTERSET');The filter selects the database character set and the national character set. A supplied inventory might report AL32UTF8 and AL16UTF16. Compare both source values with the target and apply the rules for the exact migration method. Character-set compatibility can depend on the target CDB character set and on whether the target is an application container. The rules include special provisions for an AL32UTF8 CDB. A blanket requirement that every source and target character set be identical would be too broad. See NLS_DATABASE_PARAMETERS and plug-in prerequisites.
Installed components
SELECT comp_id, version, status
FROM dba_registry
ORDER BY comp_id;COMP_ID identifies a registered component, VERSION reports its version, and STATUS reports its component state. ORDER BY makes the inventory easier to compare across databases. Investigate an invalid component status and verify target support for the required components. See DBA_REGISTRY for the component registry.
Complete this inventory with the exact release and RU, the binary patch inventory, SQL patch status, time zone file versions, platform and endian format, installed options, encryption-key access, and target capacity. Data Pump's time zone and version conditions also affect a logical plan. Storage and memory must support the migrated workload and the space used during migration. See multitenant prerequisites.
Record what the application needs
Every dependency needs a named owner, a target test, and a fallback action. The following is an example planning worksheet. Assign the actual people and tests for the designated application.
| Dependency | Suggested owner | Evidence to obtain before accepting the target |
|---|---|---|
| Services and client routing | Application and network owner | Client connects through the intended application service to the intended PDB. Reconnect behavior works. |
| Scheduled jobs | Batch owner | Intended jobs run once, with the right schedule, credentials, and external destinations. |
| Directory objects and paths | Integration and OS owner | Required files exist on the target host. Directory grants and OS access allow the intended read and write operations. |
| Database links | Integration owner | Remote destination, authentication, and the required operation succeed from the target. |
| Accounts, roles, and grants | Security owner | Application access and administrative privileges have the intended container scope. |
| Application container assumptions | Application owner | Startup, SQL, transaction processing, and scripts use the intended PDB and service rather than an assumed instance or root scope. |
A service's PDB property controls the connected container. Oracle recommends user-defined services for applications. See PDB services. A directory object names a path separately from OS filesystem access. Verify both. See directory grants and host access. Database links and Scheduler administration require their own target checks. See database links and Scheduler administration. Review local and common privilege scope. See local and common privilege scope.
Worked planning example
Assume a 19c non-CDB with 300 GB of database files, a compatible 19c destination under assessment, and 90 minutes of allowable application interruption. File size is an input. It supplies no measured transfer duration. The example has no executed rehearsal or passed acceptance tests.
Physical adoption is the candidate when the complete compatibility assessment passes, an independent source recovery path is verified, and a representative rehearsal demonstrates that the complete outage work fits the window. Include source shutdown and consistency work, file handling, conversion, normal opening, plug-in checks, service switching, application validation, and the decision interval. Include storage and workload headroom and the time needed for fallback.
For illustration, the service owner proposes this policy allocation, pending rehearsal:
| Planning limit | Proposed allocation | Status |
|---|---|---|
| Final target acceptance decision | By 60 minutes after interruption starts | To verify against full migration and test timings |
| Fallback service restoration | Up to 20 minutes after the decision | To verify in a recovery and service rehearsal |
| Headroom | 10 minutes | Policy reserve |
| Maximum application interruption | 60 + 20 + 10 = 90 minutes | Stated requirement |
These are planning limits, not measured stage durations. If the rehearsal cannot support them, revise the method or agree a different window before execution. The target's technical opening and the application's acceptance are separate checks within the same decision budget.
For this whole-database, same-release scenario, a logical Data Pump rebuild adds scope, mapping, and import work that must earn its place through requirements or measured results. Replication becomes justified if the required interruption cannot be met by the simpler candidate and its coverage, licensing, and operational work are supportable. State the reason for rejecting an alternative using the actual application's evidence.
Acceptance, backups, and fallback
Agree acceptance before the outage. Useful targets include a recorded object or key total, or a business total, at a defined consistency point. They also include successful key business transactions, correct service routing and accounts, job behavior, resolved material plug-in and component findings, and workload-specific performance thresholds. Have the relevant owners sign off actual evidence. A replication plan also needs a controlled source-write stop, confirmation of applied changes, and checks at the agreed consistency boundary.
Protect source backups, the necessary redo, the database configuration, and encryption keys in the recovery plan. Verify backup readability and integrity, and rehearse restoration and service recovery in the designated disposable environment. See RMAN validation for checking backups. A service-restoration rehearsal supplies the broader operational evidence.
Before target application writes, fallback can return service to the preserved source at the planned data boundary. Once target writes begin, the databases can diverge. The runbook must state how new transactions are retained or reconciled. Any reverse-replication option needs a supported, tested design. Returning a service name alone cannot retain target-only changes. Include a new target backup in acceptance, and preserve the source according to the agreed retention and recovery policy.
Video quick check: No. Choosing replication changes the transfer method. Data correctness, application behavior, and recovery still need cutover evidence.
Independent practice and conditions
Use an instructor-supplied 19c inventory, or the instructor-designated disposable non-CDB, with delegated read-only access to these views. Record the exact release and RU, edition, platform, account, source identity, report time, and actual output. The course starter-schema script is intended for its ordinary LABPDB setup. This inventory exercise creates no source schema and needs no conversion commands.
Write a one-page choice that includes the source and target comparison, the chosen candidate, the reason one alternative was rejected, the interruption evidence, every dependency's owner and test, the acceptance deadline, the protected backup and recovery evidence, and fallback before and after target writes. If a needed feature or topology is unavailable, complete the supplied planning alternative and mark the execution evidence pending.
Pass when the choice is supported by the stated inventory and requirements, all dependencies have accountable owners and fallback points, the whole interruption budget includes validation and recovery headroom, and the distinction between planned limits and measured results is clear. These queries and the planning exercise change no database objects or files, so no database cleanup is required. Actual migration, replication setup, restoration, and service changes require their own reviewed execution runbook and designated lab window.
Recap
Choose the migration approach from the required application result, source and target compatibility, the allowable interruption, and the evidence needed to accept the target. Inventory the source and the target first. Physical adoption is the candidate when the compatibility assessment passes, an independent source recovery path is verified, and a rehearsal shows that the complete outage fits the window. Logical Data Pump earns its place when the plan must select schemas or objects or make supported remapping changes. Replication is justified when the simpler candidate cannot meet the interruption and its coverage, licensing, and operations are supportable. Name an owner, a test, and a fallback for every dependency. Agree acceptance before the outage, and plan how target-only transactions are retained or reconciled after writes begin.
Quiz
1. Which evidence best supports choosing same-release physical adoption?
2. What does CDB=NO in the supplied V$DATABASE report identify?
3. Which requirement is a useful reason to consider logical Data Pump?
4. Does selecting replication eliminate data validation at cutover?
5. Target-only transactions have committed after service cutover. What must fallback account for?
All values and report rows in these notes are authored planning examples. No database connection or execution was performed in preparing the lesson. Preserve actual observations separately from supplied assumptions during practice.
No comments:
Post a Comment