By edapteam on

Hi,
My current setup is Drupal v10.6.10, Mariadb v10.11.18, oci8 v3.3.0, php v8.2.28.
My system currently pulls and push data to oracle 19c and there are plans to upgrade to Oracle 26ai.
Can I check if my system is compatible with Oracle 26ai?
 

⋅ Categories: Drupal 10.x

Comments

jaypan’s picture

jaypan
Location Victoria, BC
commented

How is it pushing/pulling the data? Is it doing it through an API, or direct connection? 

Contact me to contract me for D7 -> D10/11 migrations.
Or anything really. I'm friendly, and open to work or conversation.
dixit patel’s picture

dixit patel commented

If you are upgrading from Oracle 19c to 26ai, I'd first verify the Oracle driver/client compatibility with your PHP OCI8 version. Since Drupal is connecting through OCI8, the Oracle client and PHP extension versions are important. I'd test the connection in a staging environment before upgrading production.

sajibsaha334’s picture

sajibsaha334 commented

Hi  edapteam,

Worth noting that Drupal core itself isn't the compatibility gate here. Since your primary DB driver is MariaDB, Oracle is only in the picture through OCI8, which isn't part of Drupal's core database layer at all. So this really comes down to whether your Oracle Instant Client + OCI8 stack can talk to a 26ai server, not whether "Drupal 10" supports it.

A few things I'd check before the upgrade:

  • Oracle's cross-version connectivity rules: Oracle client libraries generally support N-2/N+2 version ranges against the server, but you'll want to confirm 26ai specifically against your Instant Client version in Oracle's official interoperability matrix (MOS note 207303.1). This changes with every major Oracle release.
  • OCI8 3.3.0: that build targets PHP 8.2/8.3 and links against Instant Client 19+ libraries. It should be fine talking to a 26ai server thanks to cross-version compatibility, but you may still want to bump your Instant Client to a version Oracle has explicitly certified against 26ai, even if you keep OCI8 at 3.3.0.
  • How the data pull/push is implemented: Echoing jaypan's question above: if it's raw OCI8 calls vs. something wrapped in a contrib module (e.g. a custom ETL script or a Migrate/Feeds source plugin), the blast radius of any breaking change is very different.

I'd stand up a staging environment pointed at a 26ai instance (or Oracle's free cloud trial tier if you don't have one yet) and run your actual queries/PL-SQL calls against it before touching production. New Oracle major versions sometimes deprecate specific data types or optimizer behaviors that surface as OCI8-level errors rather than anything Drupal-side.