CLOB Performance Issues


I have a table with one CLOB column and currently the table has 80 records.We are expecting the table to have around 30000 records.For now we do not have any CLOB value more than 4500 bytes,the maximum value we are expecting for this CLOB is 50000 bytes.95% of the CLOB usage is read only. What kind of performance problems we might have in future as the table grows.

When specifying the CHUNK size for the CLOB what block size does it refer to, is it the Oracle block size,filesystem block size or operating system block size.

I have seen some doccumentation about the LOB SUBSYSTEM BUFFERING which says 'LOB SUBSYSTEM BUFFERING enables the web server and client side applications to buffer the contents of one or more LOBs in the client's address space' will this help in my case, because 95% of the CLOB usage is read only.

we are using this in an internet application, each time the page is refreshed the CLOB values are accessed, so i am concerned about the performance issues i might have in future.

Are there any additional parameters which i need to consider in matters of performance.

Thanks in advance.
Who is Participating?
Here are a few things that might help you


Mentioning 'Cache' option while creating the Lobs might help you cache the Large objects for faster query response.


Similar to that specifying NOLOGGING will also prevent redo generation against ur LOBS, but sice ur LOBS are read only i doubt that this parameter will effect much.


Set CHUNK to the number of blocks of LOB data that will be accessed at one time i.e. the number of blocks that will be read or written via OCILobRead(), OCILobWrite(), DBMS_LOB.READ(), or DBMS_LOB.WRITE() during one access of the LOB value.

The default value for CHUNK is one 'Oracle block' and does not vary across platforms.

If only one block of LOB data is accessed at a time, set CHUNK to the size of one block. For example, if the database block size is 2K, then set CHUNK to 2K.


If you explicitly specify storage characteristics for the LOB, make sure that INITIAL and NEXT for the LOB data segment storage are set to a size that is larger than the CHUNK size. For example, if the database block size is 2K and you specify a CHUNK of 8K, make sure that INITIAL and NEXT are bigger than 8K and preferably considerably bigger (for example, at least 16K).

Put another way: If you specify a value for INITIAL, NEXT or the LOB CHUNK size, make sure that:



When Possible, Read/Write Large Data Chunks at a Time

Since LOBs are big, you can obtain the best performance by reading and writing large chunks of a LOB value at a time. This helps in several respects:

If accessing the LOB from the client side and the client is at a different node than the server, large reads/writes reduce network overhead.

If using the 'NOCACHE' option, each small read/write incurs an I/O. Reading/writing large quantities of data reduces the I/O.

Writing to the LOB creates a new version of the LOB CHUNK. Therefore, writing small amounts at a time will incur the cost of a new version for each small write. If logging is on, the CHUNK is also stored in the redo log.

Use LOB Buffering to Read/Write Small Chunks of Data

If you need to read/write small pieces of LOB data on the client, use LOB buffering -- see OCILobEnableBuffering(), OCILobDisableBuffering(), OCILobFlushBuffer(), OCILobWrite(), OCILobRead(). Basically, turn on LOB buffering before reading/writing small pieces of LOB data.

Use OCILobRead() and OCILobWrite() with Callback: So that data is streamed to and from the LOB. Ensure the length of the entire write is set in the 'amount' parameter on input. Whenever possible, read and write in multiples of the LOB chunk size.

Use a Checkout/Checkin Model for LOBs:

LOBs are optimized for the following operations:

SQL UPDATE which replaces the entire LOB value

Copy the entire LOB data to the client, modify the LOB data on the client side, copy the entire LOB data back to the database. This can be done using OCILobRead() and OCILobWrite() with streaming.


The advantages of buffering, especially for client applications that perform a series of small reads and writes (often repeatedly) to specific regions of the LOB, are:

Buffering enables deferred writes to the server. You can buffer up several writes in the LOB's buffer in the client's address space and eventually flush the buffer to the server. This reduces the number of network roundtrips from your client application to the server, and hence, makes for better overall performance for LOB updates.

Buffering reduces the overall number of LOB updates on the server, thereby reducing the number of LOB versions and amount of logging. This results in better overall LOB performance and disk space usage.
Please update and finalize this old, open question. Please:

1) Award points ... if you need Moderator assistance to split points, comment here with details please or advise us in Community Support with a zero point question and this question link.
2) Ask us to delete it if it has no value to you or others
3) Ask for a refund so that we can move it to our PAQ at zero points if it did not help you but may help others.



** Mindphaser - Community Support Moderator **

P.S.  Click your Member Profile, choose View Question History to go through all your open and locked questions to update them.
Recommended disposition:

    Accept UsamaMunir's comment(s) as an answer.

DanRollins -- EE database cleanup volunteer
Thanks, Dan.
I finalized this today and will monitor it in the event an adjustment is needed.
Moondancer - EE Moderator
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.