ORA-24369: Required callbacks are not registered

 🚨 ORA-24369: required callbacks are not registered

At first glance, it can look like a database problem.

But in many cases, the real issue is somewhere between the application, OCI/client layer, and the way bind variables or callbacks are being handled.

🔍 What does ORA-24369 actually mean?

Oracle is essentially saying:

“The application is expecting a callback mechanism, but the required callback has not been registered.”

This can happen when an application uses OCI-related functionality and the expected callback isn't properly registered.

🤔 What about broken binds?

This is where troubleshooting can get interesting.

If the error appears around a particular SQL statement, don't immediately assume that the SQL itself is wrong.

Check:

🔹 Bind variable definitions
🔹 Bind datatype vs. database column datatype
🔹 Number and order of bind variables
🔹 NULL handling
🔹 OCI/client library version
🔹 Application connection pool behavior
🔹 Callback registration in the application code
🔹 Differences between working and failing application nodes

Sometimes the SQL works perfectly when executed manually, while the application continues to fail.

That's a big clue.

🛠️ My troubleshooting approach

I normally break the problem into three layers:

1️⃣ Database

Check:

• SQL and execution details

• Object validity

• Database/client compatibility

• Alert log and relevant database errors

2️⃣ Client / OCI

Check:

• Oracle Client version

• OCI libraries

• ORACLE_HOME / library path

• 32-bit vs 64-bit compatibility

• Client/server version combinations

3️⃣ Application

This is often the most important layer.

Check:

• How binds are created

• Bind datatypes

• Callback registration

• Connection pooling

• Application framework/driver version

• Whether the problem occurs only on a specific application server

💡 A useful DBA lesson

When you see an Oracle error, don't automatically assume:

“The database is broken.”

For errors involving OCI, callbacks, binds, drivers or application interfaces, the database may simply be reporting a problem that originated in the application/client layer.

The fastest way to troubleshoot is to identify:

SQL → Bind → Driver → OCI → Database

and determine exactly where the behavior changes.

Have you encountered ORA-24369 in a production environment?

What was the actual root cause — OCI/client issue, callback registration, bind problem, or application code?

#Oracle #OracleDatabase #OracleDBA #ORA24369 #OCI #SQL #BindVariables #DatabaseTroubleshooting #ProductionSupport #DBA

How to Create an OCI PDB with a Specific Time Zone File Version in OCI

 While working on a recent migration, I came across an interesting requirement.

We needed to create a new PDB in Oracle Cloud Infrastructure (OCI), but not with the latest timezone file. We needed a specific timezone file version to match the source environment.

At first, this looked simple. But OCI provisioning doesn't give you an option to select the timezone file version.

So I had to look for another approach.

Why OCI Provisioning Doesn't Help

When you create a database using the OCI tooling, Oracle generally provisions it using a template.

That template already contains the timezone file version associated with the Oracle Release Update.

So, if your OCI database is running a newer RU, you'll normally get the newer timezone file as well.

Things that might normally work in an on-prem environment, such as removing timezone files from the Oracle Home or setting:

ORA_TZFILE

don't really help here.

So the question becomes:

How can we get a PDB with an older or specific timezone file version into OCI?

The Approach

The workaround is actually quite straightforward:

Create the PDB somewhere that already has the required timezone file version, unplug it, move it to OCI, and plug it into the OCI CDB.

For example, I had an existing CDB with timezone file version 44:

SELECT version
FROM v$timezone_file;

VERSION
-------
44

I then created an empty PDB:

CREATE PLUGGABLE DATABASE PDBTEMPLATE
ADMIN USER ADMIN IDENTIFIED BY "mys3cr3tpassw0rd!";

After that, I closed and unplugged the PDB:

ALTER PLUGGABLE DATABASE PDBTEMPLATE CLOSE;

ALTER PLUGGABLE DATABASE PDBTEMPLATE
UNPLUG INTO '/home/oracle/pdbtemplate.pdb';

DROP PLUGGABLE DATABASE PDBTEMPLATE INCLUDING DATAFILES;

The resulting PDB archive was relatively small in my test environment, around 600 MB, so transferring it to the OCI host was easy.

Create the PDB in OCI

Once the archive was available on the OCI host, I created the new PDB from it:

CREATE PLUGGABLE DATABASE PDBNEW
USING '/home/oracle/pdbtemplate.pdb';

ALTER PLUGGABLE DATABASE PDBNEW OPEN READ WRITE;

At this point, you may see some plug-in violations.

Don't panic. Some of them are expected because the source and target environments aren't exactly the same.

Run Datapatch

The next step is to make sure the PDB has the required SQL patch changes for the OCI environment.

I used:

$ORACLE_HOME/OPatch/datapatch -pdbs PDBNEW

After the patching completed, I restarted the PDB and checked the plug-in violations again:

ALTER PLUGGABLE DATABASE PDBNEW CLOSE IMMEDIATE;

ALTER PLUGGABLE DATABASE PDBNEW OPEN;

Then:

SELECT TYPE,
       CAUSE,
       MESSAGE,
       ACTION
FROM   PDB_PLUG_IN_VIOLATIONS
WHERE  NAME = 'PDBNEW'
AND    STATUS != 'RESOLVED'
AND    NOT (
         CAUSE = 'OPTION'
         AND TYPE = 'WARNING'
         AND MESSAGE LIKE '%PDB installed version NULL%'
       );

In my case, the remaining warnings were related to encryption of the SYSTEM and SYSAUX tablespaces.

OCI expects tablespaces to be encrypted, so this needs to be handled according to the target environment's encryption requirements.

Set the Encryption Key

Finally, I created/rotated the encryption key for the PDB:

ALTER SESSION SET CONTAINER=PDBNEW;

ADMINISTER KEY MANAGEMENT SET KEY
   FORCE KEYSTORE IDENTIFIED BY <keystore-password>
   WITH BACKUP;

The Important Part — Check the Timezone Version

Now comes the part we actually wanted to achieve.

I checked the timezone versions from the CDB root:

ALTER SESSION SET CONTAINER=CDB$ROOT;

SELECT CON$NAME,
       VALUE$
FROM   CONTAINERS(SYS.PROPS$)
WHERE  NAME = 'DST_PRIMARY_TT_VERSION'
ORDER BY 1;

The result looked like this:

CON$NAME    VALUE$
---------   ------
CDB$ROOT    45
PDBNEW      44

And that's exactly what I wanted.

The OCI CDB is using timezone file version 45, while my newly created PDB is using version 44.

So the PDB retained the timezone file version from the source environment.

One More Option

If the source and target CDBs have network connectivity, you don't necessarily have to move the PDB archive manually.

You can also consider cloning the PDB over a database link.

That can make the process much easier when you're dealing with larger PDBs.

Final Thoughts

This is one of those Oracle migration requirements that looks difficult at first because OCI provisioning doesn't provide a simple option to select the timezone file version.

The workaround is to create the PDB from an environment that already has the timezone version you need and then plug that PDB into the OCI CDB.

The same basic approach can also be useful when you need a PDB with a specific set of components or configuration characteristics that aren't available through the standard OCI provisioning workflow.

For migration projects, small details like timezone file versions can become important, especially when the source and target environments are running different Oracle Release Updates.

Sometimes the easiest solution isn't changing the OCI database — it's bringing the right PDB to OCI.

#Oracle #OracleDatabase #OCI #OracleCloud #PDB #Multitenant #DatabaseMigration #OracleDBA #TimeZone #CloudMigration

ORA-02298 During Data Pump Import — Why It Happens and How to Handle It

 

ORA-02298 During Data Pump Import — Why It Happens and How to Handle It

Recently, I was working on a database migration where Data Pump failed to create a foreign key constraint during import.

The error looked like this:

01-JUN-26 03:12:18.148: W-8 Processing object type SCHEMA_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT
01-JUN-26 03:18:58.517: ORA-39083: Object type REF_CONSTRAINT:"APPUSER"."FK_CHILDTABLE_C001" failed to create with error:
ORA-02298: cannot validate (APPUSER.FK_CHILDTABLE_C001) - parent keys not found

ALTER TABLE "APPUSER"."CHILDTABLE" ADD CONSTRAINT "FK_CHILDTABLE_C001"
  FOREIGN KEY ("C001") REFERENCES "APPUSER"."PARENTTABLE" ("C001") ENABLE

At first glance, it looks like some data was lost during the migration.

But that wasn't actually the case.

The interesting part was that the foreign key was VALIDATED in the source database.

So the obvious question was:

If the constraint was valid on the source, how can the parent rows be missing on the target?

The reason is how Data Pump export works

A normal Data Pump export is not necessarily a single point-in-time export of the entire database.

Each table can be exported at a different SCN.

For example:

Object	Export SCN
Export starts	100
T1	110
PARENT1	120
CHILD1	130
Export finishes	140

Now imagine PARENT1 and CHILD1 have a foreign key relationship.

A user inserts a new parent row at SCN 125, and the corresponding child row at SCN 130.

The important thing is that:

• PARENT1 was exported at SCN 120, so the new parent row isn't included.
• CHILD1 was exported at SCN 130, so the child row is included.

When Data Pump imports the data, it now has a child row without its corresponding parent row.

And when Oracle tries to enable the foreign key, it quite correctly says:

ORA-02298: cannot validate - parent keys not found

So this doesn't necessarily mean that Data Pump lost data.

It's a consequence of exporting related tables at different points in time.

What about GoldenGate?

This is where things become interesting.

In our migration, we were using Data Pump + GoldenGate together, so this wasn't actually a data-loss problem.

Data Pump records the SCN associated with the exported objects, and GoldenGate can use those SCNs with Automatic Per Table Instantiation.

For example:

Table	Replication starts from
T1	SCN 110
PARENT1	SCN 120
CHILD1	SCN 130

GoldenGate then starts replicating changes from the appropriate point.

So the parent row created after SCN 120 will eventually be replicated to the target.

Once GoldenGate has caught up beyond that point, the parent row exists on the target and the foreign key can be created and validated successfully.

This is why, in an initial-load migration using Data Pump and GoldenGate, ORA-02298 doesn't automatically mean that something went wrong with the migration.

What about ZDM?

In our case, the migration was being performed using Zero Downtime Migration (ZDM).

We had to tell ZDM to ignore this particular Data Pump error:

IGNOREIMPORTERRORS=ORA-02298,...

The important part here is not simply to ignore the error and forget about it.

You need to understand why the error happened and make sure the missing parent rows will arrive through the replication process.

Once GoldenGate catches up, the constraint should be validated.

Another option — Fully consistent Data Pump export

If you don't want tables to be exported at different SCNs, Data Pump can perform a consistent export using:

FLASHBACK_TIME=SYSTIMESTAMP

For example:

expdp ... FLASHBACK_TIME=SYSTIMESTAMP

Now all the tables are exported as of the same point in time.

Using the previous example, it would look more like:

Object	Export SCN
T1	100
PARENT1	100
CHILD1	100
Export finishes	140

This avoids the parent/child mismatch caused by different export SCNs.

For ZDM, the equivalent response-file parameter is:

DATAPUMPSETTINGS_DATAPUMPPARAMETERS_FLASHBACKTIME=SYSTIMESTAMP

But there is a catch...

A consistent export means Oracle may need to maintain the required older read-consistent data for the entire duration of the export.

If your export takes four hours, you need enough UNDO to support that.

Otherwise, you may run into:

ORA-31693: Table data object failed to load/unload
ORA-02354: error in exporting/importing data
ORA-01555: snapshot too old

This is something I would definitely consider before blindly using FLASHBACK_TIME on a large and busy production database.

What about exporting from a standby?

Another option is to perform the Data Pump export from a standby database, especially when the primary is heavily loaded.

For suitable environments, a snapshot standby can be useful for this type of migration activity.

It can also help reduce the impact of a long-running Data Pump export on the primary database.

My takeaway

When I first saw ORA-02298 during the import, it looked like a serious data consistency problem.

And normally, it is something you should investigate carefully.

But in a migration where Data Pump is being used for the initial load and GoldenGate is handling ongoing replication, the situation can be different.

The key is understanding the SCNs involved.

Data Pump loads the initial data. GoldenGate catches up the changes. Once the missing parent rows arrive, the foreign key can be validated.

So before treating ORA-02298 as data loss, check:

• Was the source constraint valid?
• Were parent and child tables exported at different SCNs?
• Is GoldenGate configured for automatic table instantiation?
• Has GoldenGate caught up beyond the relevant SCN?
• Can the constraint be validated after replication catches up?

That little bit of SCN awareness can save a lot of unnecessary panic during a migration. 🙂

#Oracle #OracleDatabase #DataPump #GoldenGate #ZDM #DatabaseMigration #OracleDBA #ZeroDowntimeMigration #DataGuard #DBA

What’s new in Oracle APEX 26.1

 

Announcing Oracle APEX 26.1 General Availability

The general availability of Oracle APEX AI Application Generator 26.1, the latest release of the Oracle APEX platform. APEX 26.1 marks a significant milestone for the platform.

Open Application Specification Language (APEXlang)

The centerpiece of Oracle APEX 26.1 is APEXlang: an open, declarative, human-readable specification language for Oracle APEX applications. APEXlang represents an APEX application as a package of structured .apx text files that can be exported, imported, stored in source control, diffed, merged, validated, scanned, and reviewed using standard developer tooling. In the AI era, the application model becomes more than the metadata the platform executes. It becomes the artifact AI can generate. APEXlang gives developers and AI agents a supported way to express application intent in a form that APEX can validate, govern, and execute.

AI Interactive Reports: Talk to Your Data, Trust the Result

AI Interactive Reports let users interact with reports through natural language. A user can ask to show “European customers grouped by industry”, chart service requests by country for countries with more than 50 cases, highlight specific customer segments, or pivot industry by product. APEX can translate those requests directly into native Interactive Report settings: filters, highlights, sorting, control breaks, group bys, aggregations, pivots, and charts.

AI Agents and AI Tools: Governed Conversational Action at the Application Layer

APEX 26.1 makes it easier to add AI Agents that can reason over user requests and take action through approved AI Tools. Each tool exposes a specific application capability the agent is allowed to invoke, within the scope of the application.

The model is simple: an AI Agent handles the conversation, and AI Tools define what the agent is allowed to do. A tool can retrieve data, execute server-side PL/SQL or JavaScript, or request a client-side interaction such as a user confirmation or browser API call. Developers can also use the new Generative AI Tool plug-in type to build reusable custom tools.

Additional Platform Enhancements 

APEX 26.1 also delivers significant enhancements across the broader platform, with improvements to workflow automation, page and component development, data reporting, translation management, developer and end-user experience, security, governance, and more. 

Built on a foundation you can trust 

•      Database Security

•      Access control

•      Auditing

•      Data Isolation

•      Compliance

•      Identity Integration

 

Learn, build and connect

•      Hands-On labs

•      Documentation

•      Office hours

•      Certifications

•      Discussion forums

•      Conferences

•      Collateral

•      Ideas

•      Newsletters

How To Avoid ORA-39405 During a Data Pump Import

If you have worked on Oracle database migrations using Data Pump, you may have come across this error during an import:

ORA-39405: Oracle Data Pump does not support importing from a source database with TSTZ version <source_version> into a target database with TSTZ version <target_version>

I recently came across this issue while looking at Data Pump migration scenarios, and the important thing to understand is that this error is related to the Time Zone File version of the source and target databases.

It can be easy to miss because we normally check the Oracle Database version first. But having the same database version on both sides doesn't necessarily mean the Time Zone File versions are the same.

First thing I check

Before starting any Data Pump migration, I recommend checking the Time Zone File version on both databases.

Run this on the source:

SELECT version FROM v$timezone_file;

And run the same command on the target.

For example:

Source Database
TSTZ Version: 43

Target Database
TSTZ Version: 32

Here we have a mismatch.

The source is using Time Zone File version 43, while the target is still using version 32. If the dump contains data that requires the newer Time Zone File information, the import can fail with ORA-39405.

Why does this happen?

Oracle uses Time Zone File information for data types such as:

• TIMESTAMP WITH TIME ZONE

• TIMESTAMP WITH LOCAL TIME ZONE

During the Data Pump import, Oracle needs to make sure the target database can correctly understand the time zone information coming from the source.

If the target is running with an older Time Zone File version, Oracle can stop the import rather than risk incorrect time zone data.

That's why this check is important, especially for production migrations.

Don't confuse Data Pump VERSION with TSTZ version

This is another area where I have seen confusion.

You might be using:

expdp system/password \
directory=DP_DIR \
dumpfile=prod.dmp \
logfile=prod_exp.log \
schemas=APP \
version=19.0

The VERSION parameter in Data Pump is related to database and metadata compatibility.

It is not the same thing as the Time Zone File version.

So changing:

VERSION=19.0

doesn't automatically fix ORA-39405.

For this particular error, check:

SELECT version FROM v$timezone_file;

on both sides.

What should we do if the versions are different?

If the target database has an older Time Zone File version, the normal approach is to bring the target to the required Time Zone File version before performing the import.

Before making any change, I would strongly recommend checking the Oracle documentation and the supported procedure for the specific Oracle Database release and patch level.

Also check which Time Zone Files are available in the Oracle Home:

$ORACLE_HOME/oracore/zoneinfo/

You may find files such as:

timezlrg_32.dat
timezlrg_43.dat

The exact versions available will depend on your Oracle Home and patch level.

I would not recommend manually replacing Time Zone Files in a production Oracle Home just to get around the error. Treat the Time Zone File upgrade as a proper database maintenance activity and test it first.

My recommendation for migration projects

One small change in the migration checklist can save a lot of troubleshooting later.

Before starting expdp/impdp, I normally verify things like:

Oracle Database Version
Time Zone File Version
Character Set
NLS Settings
Tablespaces
Users and Roles
Storage Availability
Data Pump Version
Database Links

But the Time Zone File check is particularly easy to forget.

Just run:

SELECT version FROM v$timezone_file;

on both source and target.

If you find:

Source  : 43
Target  : 32

don't wait until the import fails.

Address it during the migration planning stage.

One more practical tip

If you are migrating a large production database, don't discover ORA-39405 after spending hours exporting the database, copying the dump files, and preparing the target.

Do the compatibility checks before the migration window.

I've always found that a few minutes spent on pre-checks can save hours during a migration.

So, whenever you're planning an Oracle Data Pump migration, add this simple command to your checklist:

SELECT version FROM v$timezone_file;

Check it on both sides.

It takes only a few seconds—and it can save you from a very frustrating Data Pump import failure.

#Oracle #OracleDatabase #OracleDBA #DataPump #EXPDP #IMPDP #ORA39405 #DatabaseMigration #Oracle19c #DBA #DatabaseAdministration

Why APEX 26.1?

 

Why APEX 26.1? 🚀

Oracle APEX 26.1 is all about building better applications faster—with less code and more intelligence.

In this session, we’ll take a quick look at what’s new in APEX 26.1 and, wherever possible, demonstrate these capabilities in action.

🔹 Build applications faster
Speed up application development with new capabilities designed to reduce development effort.

🤖 Leverage AI to accelerate development
Explore how AI can help developers move faster, generate solutions, and focus more on business value.

⚡ Increase productivity with App Builder enhancements
New improvements make the development experience smoother and more productive.

🤝 Simplify collaboration with APEXlang
Discover how APEXlang can make it easier for teams to work together and communicate around application development.

🧩 Write less code with declarative features
Do more through APEX’s low-code, declarative approach—reducing the need for custom code.

🌍 90+ community-driven improvements
APEX 26.1 also brings a wide range of improvements inspired by the Oracle APEX community and real-world developer feedback.

🎯 Why should you care?
Because APEX continues to evolve beyond just being a low-code platform—it is becoming a powerful environment for building modern, intelligent, and enterprise-ready applications faster.

Join us to explore “Why APEX 26.1?” with a practical look at the latest features and improvements.

#OracleAPEX #APEX261 #Oracle #LowCode #AI #ApplicationDevelopment #OracleDatabase #Cloud #Developers #APEXCommunity #EnterpriseApplications #LowCodeDevelopment

🚀 LIVE ONLINE WEBINAR | Enterprise Manager 24ai — Is It the BIG SHOT?

Oracle Enterprise Manager has been a trusted companion for DBAs for years. But with Enterprise Manager 24ai, things are getting even more interesting. 🤖🚀

So, the big question is:

🔥 Enterprise Manager 24ai — Is It Really the BIG SHOT?

Join me for an interactive session where we’ll go beyond the feature list and explore what EM 24ai actually brings to the table for DBAs, Cloud DBAs, and IT Operations teams.

🎯 What we’ll explore:

• What’s new in Enterprise Manager 24ai?
• AI-driven monitoring and intelligent insights
• Database monitoring & performance management
• Automation and day-to-day DBA operations
• Hybrid & Cloud database management
• Real-world use cases from 10+ years of OEM experience
• How EM can make a DBA’s life easier
• And the big question — Is EM 24ai really the BIG SHOT? 😎

🎙️ Speaker:
Shashi Ranjan Singh
Lead Cloud DBA | 10+ Years of Oracle Enterprise Manager Experience
🏆 Oracle ACE Pro Member
☁️ Lead Cloud DBA
💡 Oracle DBA & Automation Enthusiast

📅 Date: Friday, 18th September 2026
⏰ Time: 11:00 AM IST
💻 Mode: Online Webinar

📩 To Register:
shashidba1208@gmail.com

Whether you are an Oracle DBA, Cloud DBA, IT Operations professional, or simply curious about where Enterprise Manager is heading — this session is for you!

👉 Come with your questions. Leave with practical insights.

Enterprise Manager 24ai — Is it the BIG SHOT?
Let’s find out together! 🚀

#Oracle #OracleEnterpriseManager #OEM24ai #EnterpriseManager #OracleDBA #CloudDBA #DatabaseAdministration #OracleACE #OracleACEPro #DBACommunity #AIOUG #Webinar #OracleDatabase #Automation #AI #CloudComputing