Thin mode fails with ORA-24964 when trying to open a PDB migrated from Oracle 19c to 26ai

[ytyapkin]

1. What versions are you using?

Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.28.0.0.0

Oracle AI Database 26ai Enterprise Edition Release 23.26.1.0.0 - Production
Version 23.26.1.0.0

platform.platform: Linux-5.15.0-319.201.4.2.el8uek.x86_64-x86_64-with-glibc2.28
sys.maxsize > 2**32: True
platform.python_version: 3.12.13
oracledb.__version__: 4.0.1

2. Is it an error or a hang or a crash?

Command ALTER PLUGGABLE DATABASE test OPEN READ WRITE fails with ORA-24964: ALTER SESSION SET CONTAINER error when run in oracledb thin mode

3. What error(s) or behavior you are seeing?

First, I detach a PDB from 19c with commands:
ALTER PLUGGABLE DATABASE test UNPLUG INTO '/tmp/test.pdb';

Then I attach it to 26ai:
create pluggable database test as clone using '/tmp/test.pdb';

Finally, I'm trying to open it:
ALTER PLUGGABLE DATABASE test OPEN READ WRITE;

If I run last command using sqlplus or oracledb in thick mode, PDB gets automatically upgraded and open after 20 minutes.

If I run last command using oracledb in thin mode, last command fails with error ORA-24964 after fer seconds.

4. Does your application call init_oracle_client()?

Failing application does not call init_oracle_client(), it runs in thin mode.

I tried same command with calling init_oracle_client() and using thick mode and it worked fine.

5. Include a runnable Python script that shows the problem.

This fails:

import oracledb

# Thin mode is default
print("Running in Thin mode:", oracledb.is_thin_mode())

dsn = "hostname:1521/CDB"

connection = oracledb.connect(
    user="sys",
    password="password",
    dsn=dsn,
    mode=oracledb.SYSDBA
)

cursor = connection.cursor()

try:
    cursor.execute(
        "ALTER PLUGGABLE DATABASE test OPEN READ WRITE"
    )
    connection.commit()
    print("PDB opened successfully in Thin mode")

except Exception as e:
    print("Thin mode error:")
    print(e)

finally:
    cursor.close()
    connection.close()

$ python3.12 test_thin.py
Running in Thin mode: True
Thin mode error:
ORA-24964: ALTER SESSION SET CONTAINER error
Help: https://docs.oracle.com/error-help/db/ora-24964/

This succeeds:

import oracledb

# Enable Thick mode
oracledb.init_oracle_client(
    lib_dir="/u01/app/oracle/product/23/dbhome_1/lib"
)

print("Running in Thin mode:", oracledb.is_thin_mode())

dsn = "hostname:1521/CDB"

connection = oracledb.connect(
    user="sys",
    password="password",
    dsn=dsn,
    mode=oracledb.SYSDBA
)

cursor = connection.cursor()

try:
    cursor.execute(
        "ALTER PLUGGABLE DATABASE test OPEN READ WRITE"
    )
    connection.commit()
    print("PDB opened successfully in Thick mode")

except Exception as e:
    print("Thick mode error:")
    print(e)

finally:
    cursor.close()
    connection.close()

$ python3.12 test_thick.py
Running in Thin mode: False
PDB opened successfully in Thick mode

[cjbj]

A side comment: You have

oracledb.init_oracle_client(
    lib_dir="/u01/app/oracle/product/23/dbhome_1/lib"
)

From the path, it looks like you're passing lib_dir on Linux. Don't do this if you do need to use Thick mode. From the doc:

On Linux and related platforms, enable Thick mode by calling init_oracle_client() without passing a lib_dir parameter.

And from this doc:

On Windows and macOS, pass the lib_dir library directory parameter in your oracledb.init_oracle_client() call. The parameter should be the location of your Oracle Client libraries. Do not pass this parameter on Linux.

Passing lib_dir on Linux can lead to unexpected/incorrect behavior.

[anthony-tuininga]

This looks intriguing. The error reported is as follows:

24964, 00000, "ALTER SESSION SET CONTAINER error"
// *Cause: An attempt to switch to a PDB with different settings
//         such as character set, time zone or time zone file version 
//         on an Oracle 12c Release 1 (12.1) or earlier client failed.
// *Action: Upgrade client to Oracle 12 Release 2 (or later) to support such 
//          operations. 

The cause is inaccurate, clearly! I will ask internally what might be causing this and get back to you.

[anthony-tuininga]

I asked a couple of our testers to attempt to replicate the scenario you provided but they were unable to replicate it. Can you provide details about the source database (19.28) and the target database (23.26.1)? Are there any differences in configuration between the two? I presume they are running on the same machine as Python itself?

[ytyapkin]

In my setup I have actually 2 different servers with identical configuration, except for Oracle version installed. I move pdb archive using scp between them.

Here is the list of patches I have on my source DB:
opatch lspatches
37847857;OJVM RELEASE UPDATE: 19.28.0.0.250715 (37847857)
37962946;OCW RELEASE UPDATE 19.28.0.0.0 (37962946)
37960098;Database Release Update : 19.28.0.0.250715 (37960098)

Here's what I have on the destination:
opatch lspatches
38743688;OCW RELEASE UPDATE 23.26.1.0.0 (GOLD IMAGE) (38743688) Gold Image
38743669;Database Release Update : 23.26.1.0.0 (38743669) Gold Image

I run python on machine with Oracle 26 installed

[anthony-tuininga]

How do you get the PDB archive for transport? What commands do you use for that? I presume that is run on the machine with Oracle 19.28 installed on it? Once I get that information I'll see if that can help replicate the situation. Thanks for your patience!