The symptom

datapatch -verbose stopped with:

Unsupported named object type for bind parameter at $ORACLE_HOME/sqlpatch/sqlpatch.pm line 6153.

That message says very little. The useful clue was in the database alert log at the same time:

Read of datafile '/u01/oradata/CDB1/pdbseed/temp01<timestamp>.dbf' (fno 202) header failed with ORA-01206 ORA-01122: database file 202 failed verification check ORA-01206: file is not part of this database - wrong database id PDB$SEED(2): Cannot re-create tempfile /u01/oradata/CDB1/pdbseed/temp01<timestamp>.dbf, the same name file exists

What the alert log is telling you

  • ORA-01206 (wrong database id): the header of the PDB$SEED tempfile belongs to a different database.
  • "Cannot re-create tempfile... the same name file exists": when PDB$SEED opened, Oracle tried to rebuild the bad tempfile on its own. It couldn't, because a file with that name was already on disk.
  • The datapatch error: datapatch needs a working temporary tablespace in every container, including the seed. With none available, it hit an unhandled exception in sqlpatch.pm.

Likely cause

The tempfile name carries a timestamp from 2024, but PDB$SEED had already been patched successfully in an earlier cycle, so the header problem probably appeared after that, for example following a storage-level copy or a refresh of the database files between patch cycles. I can't prove when or how it happened, so treat this as the most likely explanation, not a confirmed one.

This is a useful lesson in itself: a seed that patched fine once can still break later.

The fix

I replaced the bad tempfile in PDB$SEED with a new one. This uses a hidden parameter, so read the cautions below first.

sqlplus / as sysdba -- allow changes to the seed (session level only) ALTER SESSION SET "_oracle_script" = TRUE; ALTER PLUGGABLE DATABASE PDB$SEED CLOSE IMMEDIATE; ALTER PLUGGABLE DATABASE PDB$SEED OPEN READ WRITE; ALTER SESSION SET CONTAINER = PDB$SEED; -- remove the corrupted tempfile ALTER DATABASE TEMPFILE '/u01/oradata/CDB1/pdbseed/temp01<timestamp>.dbf' DROP INCLUDING DATAFILES; -- add a clean one ALTER TABLESPACE TEMP ADD TEMPFILE '/u01/oradata/CDB1/pdbseed/temp01.dbf' SIZE 100M AUTOEXTEND ON NEXT 10M MAXSIZE 2G; -- put the seed back as it was ALTER SESSION SET CONTAINER = CDB$ROOT; ALTER PLUGGABLE DATABASE PDB$SEED CLOSE IMMEDIATE; ALTER PLUGGABLE DATABASE PDB$SEED OPEN READ ONLY; EXIT;

Then rerun datapatch:

$ORACLE_HOME/OPatch/datapatch -verbose

Verify

After the fix, the rerun patched all three containers, including the seed:

$ORACLE_HOME/OPatch/datapatch -verbose SQL Patching tool version 19.32.0.0.0 Production Installation queue: For the following PDBs: CDB$ROOT PDB$SEED <PDB_NAME> The following interim patches will be rolled back: 37847857 (OJVM RELEASE UPDATE: 19.28.0.0.250715) Patch 39472050 (Database Release Update : 19.32.0.0.260721): Apply from 19.28.0.0.0 to 19.32.0.0.0 The following interim patches will be applied: 39222882 (OJVM RELEASE UPDATE: 19.32.0.0.260721) Patch installation complete. Total patches installed: 9 Patch 37847857 rollback (pdb CDB$ROOT): SUCCESS Patch 39472050 apply (pdb CDB$ROOT): SUCCESS Patch 39222882 apply (pdb CDB$ROOT): SUCCESS Patch 37847857 rollback (pdb PDB$SEED): SUCCESS Patch 39472050 apply (pdb PDB$SEED): SUCCESS Patch 39222882 apply (pdb PDB$SEED): SUCCESS Patch 37847857 rollback (pdb <PDB_NAME>): SUCCESS Patch 39472050 apply (pdb <PDB_NAME>): SUCCESS Patch 39222882 apply (pdb <PDB_NAME>): SUCCESS

Then check the tempfiles across all containers:

SELECT con_id, file_id, file_name, tablespace_name, status FROM cdb_temp_files ORDER BY con_id;

CON_ID 2 (the seed) should show the new temp01.dbf. Confirm the seed is back in its normal state:

SELECT name, open_mode, restricted FROM v$pdbs;

Finally, check that the patch was recorded:

SELECT patch_id, action, status, description FROM dba_registry_sqlpatch ORDER BY action_time;

Cautions

  • _oracle_script is an underscore parameter. Oracle's own scripts use it, but using it by hand to change the seed is not something I'd do without a backup and a check of the relevant My Oracle Support note. In production, I'd raise a Service Request first.
  • I set it at session level only. ALTER SESSION means it was gone when I exited and never touched the spfile.
  • Take a backup first and try this in a non-production database.
  • Read-only afterwards. Always put PDB$SEED back in READ ONLY once you're done.

What I learned

  • A Perl-level error can hide a storage problem. When datapatch fails inside sqlpatch.pm, read the alert log at the same moment.
  • Check the seed's tempfile, not just the root. A bad tempfile in PDB$SEED can block patching even when everything else looks healthy.
  • Open your PDBs before running datapatch. It only patches PDBs that are open, and it skips closed ones.
  • Files can change between patch cycles. A seed that patched fine before can still break after copies or refreshes, so it's worth checking tempfile headers before a patching window.

Have you seen this error after patching a cloned or refreshed CDB? I'd like to hear whether the cause matched.

Kumaran Murugan is an Oracle Apps DBA and OCI Cloud Administrator with 5+ years of experience in Oracle E-Business Suite, database migrations, and OCI infrastructure. Connect on LinkedIn.