Full Temp Space Bug with CLOB Fields in Direct Mode

[mas]

I have already reported several issues with CLOB fields in Direct Mode, and I have run into another.

We have some tables with CLOB columns. During our performance testing, we inserted a large number of rows into these tables. Eventually, our application started erroring out with the message from Oracle:

ORA-01652: unable to extend temp segment by 128 in tablespace TEMP

With some analysis, we found that the temporary space was being filled and never released, until we shutdown our application.

This problem occurs only in Direct Mode. We tested with the Oracle Client and we didn't run into this problem.

In the change history (http://www.devart.com/History.aspx?prod ... ect/oracle), I found this entry for 6.00.69 16-Dec-10:

Fixed bug with freeing temporary tablespace when creating multiple LOBs

Could it be that this bug was fixed for the Oracle Client but not for Direct Mode? When will this bug be fixed?

We tested with Devart dotConnect for Oracle v6.10.135.0.

[Shalex]

Could it be that this bug was fixed for the Oracle Client but not for Direct Mode? When will this bug be fixed?

This is correct. We will post here when the problem is fixed for the Direct mode.

[mas]

Hi, is there a workaround that we can employ while we're waiting for the fix? We are currently running performance tests and we often run into this issue.

[Shalex]

As a workaround, please increase the size of your tablespace or set it to unlimited.

[mas]

According to the release notes for dotConnect for Oracle 6.30.165:

The bug with retrieving LOB values in Direct mode is fixed

Is this issue fixed?

[mas]

I have tested with dotConnect for Oracle 6.30.165, and the problem still occurs. A fix for this is quite urgent for us...

[Shalex]

The bug with retrieving LOB values in Direct mode is fixed

This fix corresponds to the different issue. We are investigating the problem that is described in this thread. We will notify you about the results as soon as possible.

[mas]

Hi, it has been a long time since I have reported this issue, and this issue still persists with the newest version (7.2.96).

Our current workaround is to set "Connection Lifetime=60" in the connection string. This ensures that all connections will be closed often, which forces the temp spaced to be cleaned up.

Is there a plan to fix this? If the plan is not to fix this bug, then it would be nice to know so we can search for other solutions.

[Pinturiccio]

We are planning to fix this issue. We will notify you about the results as soon as possible.

[StanislavK]

We have fixed the issue with freeing temporary tablespace when creating multiple LOBs in the Direct connection mode. The fix is available in the latest 7.4.146 version of dotConnect for Oracle.

The new build can be downloaded from
http://www.devart.com/dotconnect/oracle/download.html
(the trial version) or from Registered Users' Area (for users with an active subscription only).

[dcoracle600pro]

I am using the 9.4.299 version (in direct mode) but I still see my TEMP tablespace growing every day.

I have serveral applications and for one of them, the only one which insert a BLOC/CLOB, the consumption of TEMP tablespace is very high (2Go at this time) and growing.

Please, do you have any news on this topic?

[Shalex]

Please upgrade to the newest build v9.14.1180 (14-Jan-21) of dotConnect for Oracle. If the upgrade doesn't help, send us a small test project with the corresponding DDL/DML script for reproducing the issue and specify the version of your Oracle Server.

[dcoracle600pro]

Hi devart team,

Can you assert that this problem still exists on 9.4.299 version ?

I understand your proposal to update my version, but it is not so simple, because I have to qualify this new version on several applications and be sure that there are no new bugs, so that's why I would prefer to stay on 9.4.299.

I saw this issue on 11R2 and 12c Oracle version.

[DmitryGm]

Can you assert that this problem still exists on 9.4.299 version ?

Please  send us a small test project with the corresponding DDL/DML script for reproducing the issue and we will check.