- 4280096 - HIGH BUFFER GETS FOR INSERT INTO LOB (fixed 184.108.40.206, 10.1.0.5 and 10.2)
- 3315549 - POOR PERFORMANCE WITH USING DBMS_LOB.WRITEAPPEND IN PLSQL LOOP
- 2602264 - DBMS_LOB.WRITEAPPEND() POOR PERFORMANCE WITH LARGE LOB AND SMALL CHUNK SIZE
- 2420525 - DBMS_LOB.WRITEAPPEND() PERFORMANCE ISSUES
- 2595083 - (description not published, although it's a base bug for some of the previous
But I'd never sat down and actually measured how much difference it can make - until today. My test appended a short string (around 35 characters) 10,000 times, using each of DBMS_LOB.append, DBMS_LOB.WriteAppend, and TEST.LOB_APPEND - a procedure that buffers the appended strings, and only flushes to the CLOB when the buffer is full:
for i in 1..:loopcount loop
Here are the results from tkprof, for 10000 iterations, 30 chars of padding:
Repeating 1,000,000 times, timing from SQL*Plus, and trying to help by wrapping the whole lot in
dbms_lob.append without open/close: 00:03:38.07
dbms_lob.append with open/close: 00:03:40.07
Simple dbms_lob.writeappend: 00:01:12.02
Append with buffering: 00:00:10.08
APPENDfor lazy reasons (no need to keep working out the length of the buffer, which
WRITEAPPENDneeds) - but the subsequent cast from VARCHAR2 to CLOB clearly contributes substantially to the problem.
In our case these LOBs are also being manipulated by many concurrent sessions on a RAC environment - so we've seen evidence of (space management) contention for the LOB segments. Reducing lio's seems to help more than a little... at least while we wait for our client to upgrade to the latest patch - which doesn't look likely any time soon!