RE: 8i CLOB data needs a lobotomy

From: Steve Orr <sorr_at_arzoo.com>
Date: Wed, 28 Jun 2000 09:32:55 -0700
Message-Id: <10542.110680@fatcity.com>

Can you check the before and after storage definitions for the tables/CLOBS? Maybe the tables were created one way but the move altered the way things are stored. Inline to out-of-line, shouldn't matter. Pctversion defaults to 10, what's the before/after. Chunksize? I know the storage definitions for LOBS are important as someone here managed to "CLOBber" the system tablespace which was on autoextend. Fragmentation maximo! (This was on a development database.)

Can you share the query that produced the before/after storage results? I'm just getting started in the LOB scene. I'm anticipating increased LOB usage so I need to nail down all the storage and operational issues.

We'll be curious as to what you discover on this one. Please keep us posted.

Thanks,
Steve Orr

-----Original Message-----

From: root_at_fatcity.com [mailto:root_at_fatcity.com]On Behalf Of John Barron Sent: Tuesday, June 27, 2000 5:26 PM
To: Multiple recipients of list ORACLE-L Subject: RE: 8i CLOB data needs a lobotomy

Thanks for the ideas steve. The tablespace was empty before the load. This is our first test run so we re-creted the whole schema from scratch. This happens on all our perl data loads where we are importing into CLOB columns. I have about 12 tables where this is happening and in each case I shrink the data down to about 5% or less than the orginal space it was taking. Ive also checked the index storage and its not the problem. I have to rebuild the indexes after this as the move table command renders them invalid.

anyway its not a major problem just some weirdness either in the perl DBD loads or the way oracle stores CLOBS from an insert.

John Barron

At 02:54 PM 6/27/00 -0800, you wrote:

What about the CRTS_QISI_LOB tablespace? What's the before/after on it? Did the clobs start out in the CRTS_DATA tablespace? No lobs in the system tablespace, right? Check the tablespace_name in dba_segments where segment_type in('LOBSEGMENT','LOBINDEX'). Just some ideas... happy lob hunting.
HTH,
Steve Orr
-----Original Message-----

From: root_at_fatcity.com [mailto:root_at_fatcity.com]On Behalf Of John Barron Sent: Tuesday, June 27, 2000 2:28 PM
To: Multiple recipients of list ORACLE-L Subject: 8i CLOB data needs a labotomy

I think my 8i CLOB data needs a labotomy. This is my problem and my work around. We use perl DBD::Oracle to load our database from flat files. Part of it is to load embedded text data into CLOB columns in our table CR_HLD_QISI_CALLS. The CLOB cols are PROBLEMTEXT, ANALYSISTEXT, etc. When we run the perl script the 100M text file mushrooms out to 900M in the tablespace. Using the tablespace coalesce command has no affect on the tablespaces. If we MOVE the tables and CLOB data to another tablespace (or even in the same tablespace) and compress to one extent it shrinks the 800M down to 40M.

Why does it take so much tablespace? Is it the way perl loads data? We have set default storage on the tablespace and tables to PCTFREE=0 as there will be no updates to this table. The database is UTF8 with NLSLANG=ja16euc and we do have some indexes on the tables but none of this accounts for the huge space requirements for the initial upload.

Any comments, pointers would be appreciated. Ive added our move sql and the space used before and after the table move and coalesce.

tia

John Barron

The SQL for moving the CLOBS and tables

alter table CRTS.CR_HLD_QISI_CALLS move tablespace CRTS_DATA lob (PROBLEMTEXT) store as (tablespace CRTS_QISI_LOB storage(minextents 1));
alter table CRTS.CR_HLD_QISI_CALLS move
lob (ANALYSISTEXT) store as (tablespace CRTS_QISI_LOB storage(minextents 1));
alter table CRTS.CR_HLD_QISI_CALLS move
lob (HISTORY) store as (tablespace CRTS_QISI_LOB storage(minextents 1));

alter tablespace CRTS_QISI_DATA coalesce;

alter table CRTS.CR_HLD_QISI_CALLS move tablespace CRTS_QISI_DATA lob (ESC_SUMMARY) store as (tablespace CRTS_QISI_LOB storage(minextents 1));

The BEFORE and AFTER space output

Oracle8i Enterprise Edition Release 8.1.6.0.0 - Production With the Partitioning option
JServer Release 8.1.6.0.0 Production

Table                CLOB Col
CR_HLD_QISI_CALLS    PROBLEMTEXT                64,430,080
CR_HLD_QISI_CALLS    ANALYSISTEXT              469,114,880
CR_HLD_QISI_CALLS    HISTORY                   279,552,000
CR_HLD_QISI_CALLS    ESC_SUMMARY                 1,597,440
CR_HLD_QISI_CALLS    Total                     814,694,400

Table altered.

Tablespace altered.

Table altered.

CR_HLD_QISI_CALLS    PROBLEMTEXT                39,936,000
CR_HLD_QISI_CALLS    ANALYSISTEXT                  532,480
CR_HLD_QISI_CALLS    HISTORY                       532,480

Received on Wed Jun 28 2000 - 11:32:55 CDT