The Legacy Obituaries

Notices of desupport & departureOracle Database → AzureTuesday, 29 September 2026The Coroner’s ReportsAbout this paper

Case q06 · version-scope

We still run a non-CDB 19c database. Does that matter for the Azure move?

Expected: Non-CDB architecture is desupported in 21c (deprecated 12.1); any lift to 21c/23ai on Azure VMs or Oracle Database@Azure requires converting to a PDB first; irrelevant for SQL MI/PostgreSQL targets except as an upgrade prerequisite.

No tools

The model alone, answering from memory.
larger model · 1 turn · 26 s · 16.4k in / 2.5k out

✓ verdict ✗ grounded ✓ cited

Grader: Correct verdict; unsupported licensing, ZDM flag, and 26ai claims

Answer

Yes, it matters, though it won't block the move. Non-CDB 19c runs fine on Azure VMs and can be migrated to Oracle Database@Azure. The catch is that 19c is the last release that supports non-CDB. You will have to convert to a pluggable database (PDB) at some point, so decide now whether to do it before, during or after the migration.

Key facts

  • Oracle is ending non-CDB. It was deprecated in 12.1.0.2 and removed in 21c. 23ai, now renamed 26ai, only supports the multitenant architecture (a container database holding PDBs). Any upgrade past 19c means converting to a PDB. Check your 19c support end dates in Oracle's Lifetime Support Policy or My Oracle Support Doc ID 742060.1, because Oracle has extended them more than once.
  • By Azure target:
    • Oracle on Azure VMs: You can keep non-CDB as-is. A Data Guard or RMAN lift-and-shift preserves the architecture and gives the lowest risk and downtime.
    • Oracle Database@Azure (Exadata Database Service): Tooling assumes a container database. Zero Downtime Migration (ZDM) can convert to a PDB during a physical migration with NONCDBTOPDB_CONVERSION=TRUE. You can also convert on-premises first.
    • Autonomous Database: This is a logical migration (Data Pump or GoldenGate) into a PDB, so non-CDB mostly stops mattering.
  • How to convert: Run DBMS_PDB.DESCRIBE, then CREATE PLUGGABLE DATABASE ... USING xml, then noncdb_to_pdb.sql. AutoUpgrade can also do it with the target_cdb parameter, and can upgrade to 26ai in the same run.
  • Conversion is one-way. Once you convert, you can't fall back to the old non-CDB primary with Data Guard. Take a full backup or keep the source intact until you're past go-live.
  • Licensing: 19c+ allows up to 3 user PDBs per container database without the Multitenant option, so converting to a single PDB costs nothing extra. On Azure VMs under BYOL, 2 vCPUs count as 1 processor license when hyperthreading is on.
  • App impact is usually small, but check:
    • Connections must use a service name, not a SID.
    • Scripts that use CONNECT / AS SYSDBA land in the root container (CDB$ROOT), not your PDB.
    • Common users need the C## prefix.
    • Monitoring and backup tools need to be aware of containers.

My recommendation: Don't stack changes. Pick one of these:

  1. Lift-and-shift the non-CDB to an Azure VM with Data Guard, which keeps a clean fallback, and convert or upgrade later.
  2. If you're going to Database@Azure, convert on-premises first, test it, then migrate.

Only combine conversion with the move (ZDM conversion or AutoUpgrade) if you've rehearsed it and can live without a Data Guard fallback.

Keyword search

BM25 over the same 446 documents: top 8 passages pasted in, one pass, references not followed.
larger model · 1 turn · 9 s · 18.8k in / 0.9k out

✓ verdict ✓ grounded ✓ cited

Grader: Correct 12.1/21c facts; handles targets and SQL/PG properly

8 keyword-search passages
  1. mapping_non-cdb-architecture--oracle-db-at-azure score 22.611
  2. mapping_non-cdb-architecture--oracle-on-azure-vm score 16.326
  3. source_oracle-glossary-non-cdb-desupported score 14.435
  4. mapping_dbms-job--elastic-jobs score 13.949
  5. glossary_desupported score 13.866
  6. glossary_cdb-pdb-non-cdb score 13.531
  7. dispute_ssma-autonomous-transaction-emulation-on-mi score 13.118
  8. feature_non-cdb-architecture score 12.612
Answer

Yes, it matters. The non-CDB layout is desupported from 21c onward, so if you move to Oracle Database@Azure you'll have to convert it to a pluggable database (PDB). On an Azure VM you can keep it for now, but that only puts the conversion off.

Why it matters

  • Oracle deprecated the non-CDB architecture in 12.1 and desupported it in 21c. From 21c the installer can't create a non-CDB, and upgrading to 21c or later means converting it into a PDB. [3][6][8]
  • Every current Oracle target is a container database (CDB), so a migrated non-CDB has to become a PDB. [6]

If the target is Oracle Database@Azure (Exadata Database Service)

  • The console and APIs only create CDBs with an initial PDB. You can create a non-CDB only through the dbaascli command line, and only for 19.x and earlier. [1]
  • Recommendation: create a target CDB on the Exadata VM cluster, then use AutoUpgrade or Data Pump to upgrade and plug each non-CDB in as a PDB. Use dbaascli to create a non-CDB only if you need temporary 19c compatibility. [1]
  • Some CDB and PDB management tasks are done in the OCI console rather than the Azure portal. [6]

If the target is a self-managed Azure VM

  • You can install any release there, so you can move the 19c non-CDB as it is. Later releases are multitenant-only, though, so you'll still have to convert eventually. [2]
  • If you're moving to a newer release on the VM, the recommended route is:
    1. Create an empty CDB on the VM.
    2. Run AutoUpgrade with the non-CDB as the source and the CDB as the target. It upgrades and plugs in the database in one operation.
    3. Change connection strings to the PDB service name. [2]

Also plan for: the non-CDB layout changes what assessment tools see (no PDB scoping) and how users and services are set up (no common users or per-PDB services). [8]

Source: Oracle Database 21c Upgrade Guide, non-CDB to multitenant upgrades: https://docs.oracle.com/en/database/oracle/oracle-database/21/upgrd/upgrade-scenarios-non-cdb-oracle-databases.html

Passages [4] and [7] are about Azure SQL targets and aren't relevant to this question.

Sanity Context · GROQ

The agent with the GROQ endpoint: schema, joins, Portable Text.
smaller model · 5 turns · 28 s · 44.6k in / 2.2k out

✓ verdict ✓ grounded ✓ cited

Grader: Correct 12.1/21c facts; treats SQL/PG as gap, not irrelevant

4 tool calls
  1. initial_context on groq · 4,126 chars back
  2. groq_query on groq · 858 chars back
    *[_type=="oracleFeature" && (name match "*CDB*" || name match "*container database*" || name match "*non-CDB*" || name match "*pluggable*")]{_id, name, "slug": slug.current, category, introducedIn, deprecatedIn, desupportedIn, oracleReplacement, reviewStatus}
  3. groq_query on groq · 5,451 chars back
    *[_type=="oracleFeature" && slug.current=="non-cdb-architecture"][0]{
  _id, name, category, introducedIn, deprecatedIn, desupportedIn, oracleReplacement,
  "sources": sources[]->{title, url, publisher},
  "mappings": *[_type=="mapping" && oracleFeature._ref==^._id]{
    _id, fidelity, effort, rationale, appliesToOracleVersions,
    "azureTarget": azureTarget->{name, service},
    "sources": sources[]->{title,url},
    "caveats": *[_type=="caveat" && mapping._ref==^._id]{
      severity, statement, appliesTo, firsthand,
      "evidence": evidence->{title,url}
    }
  }
}
  4. groq_query on groq · 549 chars back
    *[_type=="dispute" && (claimA._ref in ["caveat_exadata-cloud-cdb-only-console","caveat_autoupgrade-noncdb-to-pdb"] || claimB._ref in ["caveat_exadata-cloud-cdb-only-console","caveat_autoupgrade-noncdb-to-pdb"])]{title, whatDisagrees, resolution, "resolvedBy": resolvedBy->{title,url}}
Answer

No disputes recorded on this. Here's what the dataset shows.

Verdict: Yes, it matters. Non-CDB is deprecated (not yet desupported) for Oracle 19c, but neither major Azure target lets you keep it as-is without a plan to convert to a pluggable database (PDB).

Scoped facts

  • Feature status: Non-CDB architecture was deprecated in Oracle 12.1 and desupported in 21c, with Oracle's replacement being the Multitenant architecture (CDB with pluggable databases). Since you're on 19c, it's still deprecated-but-supported, not desupported — but the clock is ticking toward 21c-class desupport. Deprecated and Desupported Features for Oracle Database 12c (12.1), Oracle Database Changes, Desupports, and Deprecations (Upgrade Guide 21c)

  • Oracle Database@Azure (Exadata Database Service on Dedicated Infrastructure) — fidelity: workaround, effort: M, applies to 19c: On this service, the console and OCI APIs create only container databases with an initial PDB. A non-CDB can be created only via the dbaascli command line, and only for release 19.x and earlier — so this door is closing for you already. TDE encryption is also mandatory for all cloud databases here. Oracle's guidance implied by the rationale: convert your non-CDB estate to PDBs (AutoUpgrade can do this in one step) before or during the move rather than trying to preserve it. Severity: major. Exadata Database Service on Dedicated Infrastructure: Manage databases, Oracle Database@Azure: Exadata services

  • Oracle Database on Azure Virtual Machines — fidelity: workaround, effort: M, applies to 19c: On a self-managed VM, any Oracle release (including your 19c non-CDB) can be lifted as-is — but this only postpones the issue, since later Oracle releases are multitenant-only. AutoUpgrade can upgrade a non-CDB and convert it into a PDB (new or existing CDB) in a single operation, or perform unplug-plug upgrades between CDBs of different releases. This is the recommended step if/when you move to a newer release on the VM. Severity: minor. Oracle Database 23ai Upgrade Guide: Using AutoUpgrade, Overview of Oracle applications and solutions on Azure

Gaps: No dispute is recorded on this topic in the dataset. No mapping/caveat exists for other Azure targets (e.g., Azure SQL, Azure PostgreSQL Flexible) regarding non-CDB — the dataset only covers Oracle Database@Azure and Oracle on Azure VM for this feature.

GROQ + Knowledge Base

The agent with both endpoints.
smaller model · 6 turns · 25 s · 50.2k in / 2.0k out

✓ verdict ✓ grounded ✓ cited

Grader: Correct 12.1/21c facts; handles targets and SQL/PG properly

5 tool calls
  1. initial_context on groq · 4,126 chars back
  2. initial_context on kb · 7,679 chars back
  3. knowledge_base_read on kb · 6,720 chars back
    {
 "knowledgeBase": "kb6MdvV3ZA3Q",
 "paths": [
  "oracle_concepts/architecture",
  "oracle_concepts/terminology"
 ]
}
  4. groq_query on groq · 1,540 chars back
    *[_type=="oracleFeature" && (name match "*CDB*" || name match "*multitenant*" || name match "*non-CDB*" || slug.current match "*cdb*" || slug.current match "*multitenant*")]{_id, name, slug, category, introducedIn, deprecatedIn, desupportedIn, oracleReplacement, reviewStatus, "sources": sources[]->{title,url}}
  5. groq_query on groq · 4,164 chars back
    *[_type=="mapping" && oracleFeature->slug.current=="non-cdb-architecture"]{fidelity, effort, rationale, appliesToOracleVersions, "azureTarget": azureTarget->{name, service}, "sources": sources[]->{title,url}, "caveats": *[_type=="caveat" && references(^._id)]{severity, statement, appliesTo, firsthand, "evidence": evidence->{title,url}}}
Answer

Yes — non-CDB architecture matters, on two fronts: Oracle's own lifecycle status, and how each Azure Oracle target creates databases.

Oracle lifecycle status (applies regardless of target): Non-CDB architecture was deprecated in Oracle 12.1 and desupported in Oracle 21c; the Oracle-side replacement is the multitenant architecture (CDB with pluggable databases) Deprecated and Desupported Features for Oracle Database 12c (12.1), Oracle Database Changes, Desupports, and Deprecations (Upgrade Guide 21c). Since it's desupported (not merely deprecated) as of 21c, your 19c non-CDB source is on borrowed time even before you touch Azure — a functional equivalent (PDB conversion) is required for any onward Oracle-to-Oracle path, per the dataset's terminology convention: "any desupported feature must be replaced before or during the migration, because the target release may not contain it at all" ([oracle_concepts/terminology], Dataset knowledge base).

On Oracle Database@Azure (Exadata-based): fidelity is workaround, effort M, scoped to 11.2–19c source. The console and OCI APIs on Exadata Database Service (which underpins Oracle Database@Azure) create only CDBs with an initial PDB. A non-CDB can be created only via the dbaascli command line, and only for release 19.x and earlier — so your specific 19c non-CDB is right at the edge of that window. TDE encryption is also mandatory for all cloud databases there (severity: major). Recommended approach: convert to PDB before or during the move — AutoUpgrade does this in one step. Exadata Database Service on Dedicated Infrastructure: Manage databases, Oracle Database@Azure: Exadata services.

On Oracle Database on Azure VMs: fidelity is also workaround, effort M, same version scope (11.2–19c). Here you can lift the 19c non-CDB as-is since a self-managed VM allows any Oracle release, but this only postpones conversion, since later releases are multitenant-only. AutoUpgrade can upgrade and convert the non-CDB into a PDB in a new or existing CDB in a single operation — this is the recommended step (caveat severity: minor). Oracle Database 23ai Upgrade Guide: Using AutoUpgrade, Overview of Oracle applications and solutions on Azure.

Practical implication: every current Oracle database target is effectively a CDB, so your source non-CDB must land as a PDB after migration — whether you convert before (VM path, more flexible) or are forced to at creation time (Oracle Database@Azure, given the 19.x cutoff) ([oracle_concepts/architecture], Dataset knowledge base).

No dispute in the dataset touches this topic, and no mapping exists for non-CDB against Azure SQL DB/MI or PostgreSQL Flexible Server — expected, since those aren't Oracle-engine targets and the CDB/non-CDB distinction is Oracle-internal.

← q05All casesq07 →