On the Sixth Day of 26ai, Viscosity Gave To Me…

Oracle AI Database 26ai – PDB Now!

If you have not heard the news, Oracle AI Database 26ai will be available for Linux x86-64 on-premises starting in January 2026! This is great news, as I know a lot of customers have been waiting for this opportunity to start testing their non-production systems for the next major long-term support release. Many of my customers have also been putting off the migration to pluggable database, which is a requirement of the new version, as Oracle has been telling us for many years now (since 21c).

Why have people been putting this off? I would say mostly due to comfortability with the status quo, not wanting to introduce change to their 19c environments until necessary. Here, I will try and convince you that now is the time to convert before you upgrade to 26ai. First, this is probably the most dramatic reason. If you have an existing NON-CDB database, say on 19c, and you plug that into a 26ai instance (changing it into a PDB), this is a non-reversible operation.

What does that mean? The database files on disk are changed in a one-way fashion to become a pluggable database in 26ai and cannot be “unplugged”. Now there are ways to provide protection by cloning the database before plugging in or restoring a previous backup. Note that a Guaranteed Restore Point / GRP or Flashback database will not work to revert a plug-in operation. Finding issues right away here would be critical since any data changes made after the upgrade would be lost when going back to a previous incarnation of the database.

This leads to my first suggestion/point. If you move from NON-CDB to PDB in the current version you are running, the chances of running into an issue is much less. You would not be changing the version of the Optimizer or possibly even the binaries of the database software. This reduces possible issues that would come up during an upgrade. By separating the migration to PDB from the upgrade provides this reduction of risk.

Second, most environments rely on a good deal of scripts or automation to manage their databases. This could be anything from backup scripts to routine maintenance, like managing table partitions, or even critical monitoring. Moving from NON-CDB to PDB will require some changes to your scripts. At minimum, you will need to add some logic to check if a database is NON-CDB or PDB and set the environment correctly based on what the script is trying to do. Putting these changes ahead of a technical upgrade to Oracle 26ai is just asking for more effort that could be started or even completed now.

This blog would not be long enough to cover all the options, but here are a few tips and suggestions.

• Use connection wallets – connecting to a PDB using a username with a password, and a connection string helps maintain connections properly even if moved between containers (assuming the same listener).
• For OS authentication, use ORACLE_PDB_SID environment variable. This can be set to the PDB name while ORACLE_SID is set to the CDB SID. If the PDB is open and everything is correct, your script will connect directly to the PDB with a “/ AS SYSDBA”. The issue is, the connection will still work if you provide an invalid PDB, or if the PDB is closed. Make sure you check in the script that you have connected to the PDB:
  SELECT SYS_CONTEXT('USERENV','CON_NAME') FROM DUAL;

Here is an example in BASH:

export ORACLE_SID=CDB1
export ORAENV_ASK=NO
source /usr/local/bin/oraenv -s

export ORACLE_PDB_SID=PDB01

set -o pipefail; connect_db=$("${ORACLE_HOME}/bin/sqlplus" -s /nolog  <<!EOF
    WHENEVER sqlerror EXIT sql.sqlcode;
    CONNECT / AS SYSDBA
    set pagesize 0
    set linesize 32767
    SELECT SYS_CONTEXT('USERENV','CON_NAME') FROM DUAL;
    exit
!EOF
)

if (( $? == 1 )) || [ "${ORACLE_PDB_SID}" != "${connect_db}" ]; then
  echo "could not determine connection to Oracle database ${ORACLE_SID}"
  echo " OR connection to PDB ${ORACLE_PDB_SID} failed, actual connection ${connect_db}"
  exit 1
fi

echo "Connection to ${ORACLE_PDB_SID} successful"

• Some commands will not work at the PDB level. For example:
  ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
  This must be run at the CDB level. If your automation performs some of these commands, make sure your scripts are authored to be in the correct context.
• Consider moving to common users (C##) for maintenance tasks like backup. These users will exist in all your PDBs and make automation easier for consistency across all your databases. Making a C##BACKUP user in all your CDBs and then creating a connection wallet for that user will greatly simplify operations in clustered environments and separate scripts from most OS connectivity requirements.
  CREATE USER C##BACKUP;
  GRANT CONNECT TO C##BACKUP;
  GRANT SYSBACKUP TO C##BACKUP;

When using common users, be sure to be consistent. When moving PDBs between containers, it’s important not to have collisions of common users or roles that may not be for the same use.

Third, you should be using custom service names for all connections. This is important for using any advanced features, such as cloneable PDB or even PDB migration. Service names can easily be cross-registered with multiple listeners during migration and allow for the ability to disable access during such operations. Using the default service name (matching the database name) makes this difficult, if not impossible. If you are not using custom service names, this is another change that you can start incorporating prior to the 26ai upgrade. Here is a quick example of creating a service:

BEGIN
  DBMS_SERVICE.CREATE_SERVICE( 
        service_name => 'myapp_dev', 
        network_name => 'myapp_dev');
END;
/

BEGIN
  DBMS_SERVICE.START_SERVICE( service_name => 'myapp_dev');
END;
/

Finally, the last major change will be you. Your mindset and how you do your daily operations will have some changes. Everything from making sure you are looking at the right views when querying the database to understanding where to change some settings will be a little different. The sooner you start working in the new pluggable world, the sooner you will get used to this. Here is a simple first tip. If you are in a container and you want to verify if a setting has been changed or not at the container level, set your session to the container:

ALTER SESSION SET CONTAINER=PDB01;

SHOW PARAMETER ldap_directory_access;

Now, to go back to the CDB (root container) and check the same parameter:

ALTER SESSION SET CONTAINER=CDB$ROOT;

SHOW PARAMETER ldap_directory_access;

Moving to PDB should not wait for a major database upgrade. You should be moving your existing systems to CDB/PDB architecture right away on the 12c or 19c version you are running today. This allows you to adjust not just your scripts but how you operate daily, and provides familiarity. This also reduces the risk of troubleshooting PDB changes to your environment while also taking on the risk of the Optimizer and binary changes at the same time. Start using features like connection wallets and custom service names now. All of this will make your upgrade to 26ai go smoother. Plus, you can start utilizing the benefits of consolidation since you can have up to three PDBs in a CDB even if you don’t have the multi-tenant license! Be sure to set the following parameter to protect yourself:

ALTER SYSTEM SET MAX_PDBS=3 SCOPE=BOTH SID='*';

Don’t wait for the 26ai upgrade to adopt PDBs. Converting now reduces risk, simplifies future upgrades, and gives you a head start on the architecture that will define Oracle’s next decade.

Happy Holidays! 🎄

Ready to Take Your Oracle Skills to the Next Level?

Join OraPub, Viscosity’s training hub for Oracle professionals, packed with expert-led courses and exclusive paid member benefits.

Ready for a deeper dive from Gary on this topic? Join our FREE webinar on December 16, 2025, at 11:00 AM CT, where Gary Gordhamer breaks down the essential PDB skills you need before moving to Oracle 23ai and 26ai.