Introduction

During an Oracle Release Update (RU) installation, you may encounter the following error while running datapatch:

DBD::Oracle::st bind_param failed:
ORA-01652: unable to extend temp segment by 128 in tablespace TEMP
(DBD ERROR: OCILobWrite in dbd_rebind_ph_lob)

At first glance, the error appears to indicate a problem with the Perl DBD::Oracle module. However, the real cause is usually much simpler—Oracle is unable to allocate sufficient temporary space in the TEMP tablespace while executing SQL patch scripts.

In one of our production patching activities, the issue was resolved by:

• Running datapatch -sanity_checks
• Identifying insufficient TEMP space
• Adding additional TEMP files to both the CDB and PDB$SEED
• Rerunning datapatch

The patch then completed successfully.

---

Symptoms

During datapatch execution, you may see errors such as:

DBD::Oracle::st bind_param failed:
ORA-01652: unable to extend temp segment by 128 in tablespace TEMP
(DBD ERROR: OCILobWrite in dbd_rebind_ph_lob)

or

ORA-01652: unable to extend temp segment

The failure typically occurs while executing:

$ORACLE_HOME/OPatch/datapatch -verbose

Datapatch terminates before completing SQL patch application.

---

Root Cause

ORA-01652 indicates that Oracle could not allocate enough temporary space for an operation.

During datapatch, Oracle performs numerous resource-intensive tasks, including:

• Applying SQL patches
• Updating the data dictionary
• Recompiling invalid objects
• Executing package upgrades
• Processing LOB data
• Performing large sort and hash operations

These operations require significant TEMP space.

If the TEMP tablespace becomes full or cannot autoextend, datapatch fails with the DBD::Oracle::st bind_param error.

In multitenant environments, the issue may exist in:

• CDB$ROOT
• PDB$SEED
• Individual PDBs

---

Step 1 – Run Datapatch Sanity Checks

Before making any changes, run Oracle’s built-in validation.

$ORACLE_HOME/OPatch/datapatch -sanity_checks

The sanity check validates several prerequisites, including:

• TEMP tablespace capacity
• Invalid database configuration
• SQL patch prerequisites
• Component status
• General environment health

This command often identifies the root cause before datapatch starts.

---

Step 2 – Check TEMP Tablespace in the CDB

Verify the available TEMP files.

SELECT
    tablespace_name,
    file_name,
    bytes/1024/1024/1024 AS size_gb,
    autoextensible
FROM dba_temp_files;

Check TEMP usage.

SELECT
    tablespace_name,
    SUM(blocks)*8192/1024/1024 AS used_mb
FROM v$tempseg_usage
GROUP BY tablespace_name;

---

Step 3 – Add Additional TEMP Files to the CDB

If the TEMP tablespace is too small, add another tempfile.

Example:

ALTER TABLESPACE TEMP
ADD TEMPFILE
'/u02/oradata/DBNAME/temp02.dbf'
SIZE 20G
AUTOEXTEND ON
NEXT 1G
MAXSIZE UNLIMITED;

If Oracle Managed Files (OMF) is enabled:

ALTER TABLESPACE TEMP
ADD TEMPFILE
SIZE 20G
AUTOEXTEND ON
NEXT 1G
MAXSIZE UNLIMITED;

---

Step 4 – Check TEMP Tablespace in PDB$SEED

Many DBAs overlook PDB$SEED during patching.

Since datapatch applies SQL changes to PDB$SEED, insufficient TEMP space in the seed database can also cause ORA-01652.

Switch to the seed container:

ALTER SESSION SET CONTAINER=PDB$SEED;

Check TEMP files.

SELECT
    tablespace_name,
    file_name,
    bytes/1024/1024/1024 AS size_gb,
    autoextensible
FROM dba_temp_files;

---

Step 5 – Add TEMP Files to PDB$SEED

If the seed database requires more TEMP space, add another tempfile.

ALTER TABLESPACE TEMP
ADD TEMPFILE
'/u02/oradata/DBNAME/pdbseed_temp02.dbf'
SIZE 10G
AUTOEXTEND ON
NEXT 1G
MAXSIZE UNLIMITED;

If using Oracle Managed Files:

ALTER TABLESPACE TEMP
ADD TEMPFILE
SIZE 10G
AUTOEXTEND ON
NEXT 1G
MAXSIZE UNLIMITED;

Verify the new tempfile.

SELECT
    file_name,
    bytes/1024/1024/1024 AS size_gb,
    autoextensible
FROM dba_temp_files;

Switch back to the root container.

ALTER SESSION SET CONTAINER=CDB$ROOT;

---

Step 6 – Verify TEMP Configuration

Confirm all TEMP files.

SELECT
    tablespace_name,
    file_name,
    bytes/1024/1024/1024 size_gb,
    autoextensible
FROM dba_temp_files
ORDER BY file_name;

---

Step 7 – Rerun Datapatch

Once sufficient TEMP space has been allocated, rerun datapatch.

$ORACLE_HOME/OPatch/datapatch -verbose

The patch should complete successfully.

---

Why Does Datapatch Consume So Much TEMP?

Datapatch executes thousands of SQL statements that may:

• Recompile PL/SQL packages
• Update Oracle dictionary objects
• Modify metadata
• Process XML and LOB data
• Execute complex sorting operations
• Rebuild internal objects

On databases with many schemas or PDBs, TEMP usage can increase significantly.

---

Best Practices Before Every Oracle Patch

To minimize patch failures:

• Run datapatch -sanity_checks before applying SQL patches.
• Verify that the TEMP tablespace has sufficient free space.
• Ensure TEMP files are configured with AUTOEXTEND ON.
• Check TEMP configuration in CDB$ROOT, PDB$SEED, and critical PDBs.
• Monitor TEMP usage during large patching operations.
• Review datapatch logs immediately if errors occur.

---

Useful SQL Commands

Check TEMP Files

SELECT
    tablespace_name,
    file_name,
    bytes/1024/1024/1024 size_gb,
    autoextensible
FROM dba_temp_files;

Monitor Current TEMP Usage

SELECT
    username,
    tablespace,
    blocks
FROM v$tempseg_usage;

View TEMP Free Space

SELECT
    tablespace_name,
    SUM(free_space)/1024/1024 AS free_mb
FROM dba_temp_free_space
GROUP BY tablespace_name;

Check Database Container

SHOW CON_NAME;

---

Resolution Summary

Problem	Solution
DBD::Oracle::st bind_param failed	Usually caused by insufficient TEMP space
ORA-01652 during datapatch	Run datapatch -sanity_checks
TEMP tablespace exhausted	Add additional TEMP files
PDB$SEED patch failure	Add TEMP files to PDB$SEED
Datapatch still failing	Verify TEMP space in CDB, PDB$SEED, and all PDBs
Successful patching	Rerun datapatch -verbose

---

Conclusion

Although the error references DBD::Oracle and OCILobWrite, the underlying issue is typically an exhausted TEMP tablespace, not a problem with the Perl module itself.

Oracle’s datapatch -sanity_checks is an excellent first step for diagnosing environment issues before applying SQL patches. In multitenant databases, don’t forget to verify TEMP space not only in the CDB root, but also in PDB$SEED, as datapatch applies updates there as well.

Adding sufficient TEMP files and ensuring they are configured to autoextend can quickly resolve ORA-01652 and allow datapatch to complete successfully.

Making these checks part of your standard patching procedure can significantly reduce downtime and prevent unexpected failures during Oracle Release Updates.