RE: 8i CLOB data needs a lobotomy

From: Steve Orr <sorr_at_arzoo.com>
Date: Fri, 30 Jun 2000 09:07:32 -0700
Message-Id: <10544.110947@fatcity.com>

This is a multi-part message in MIME format.

------=_NextPart_000_0029_01BFE272.9FCD1530 Content-Type: text/plain;

charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

John,

Hmmm, there must be something weird with that perl load stuff. The DBA manuals are somewhat deficient regarding LOB management but the "Application Developer's Guide - Large Objects" documentation actually has some good stuff for DBA's. There's a section about loading data into LOB's which may help. Definitely a strange phenomenon. Good luck and let us know what you discover.

Steve Orr
-----Original Message-----
From: root_at_fatcity.com [mailto:root_at_fatcity.com]On Behalf Of John Barron Sent: Thursday, June 29, 2000 11:09 AM To: Multiple recipients of list ORACLE-L Subject: RE: 8i CLOB data needs a lobotomy

Steve

We created the database from scratch and this was our first data load into a new database. Just to recap the initial datafiles was 245M and it ended up consuming 900M in the CLOB tablespace.

Ive just looked at our table create for the CLOB tables and noticed that there is no storage clause in the LOB parameters section. When we created this we set the table PCTFREE to 0 and I also asked the devlopers to do the same with LOBS. Anyway it has not been done. At present we use the defaults CHUNK=8K (our db block size) and PCTVERSION=10. I also assume that PCTFREE is set to default of 50 which could account for some of the space used. Im still not quite sure how the PCTVERSION would affect the data storage (the manual is not all that clear).

Our process for uploading the data (all done through a perl program) is:

  1 rename the HOLD table to TEMP
  2 rename the PREV table (which has been truncated as it holds the previous load data) to HOLD
  3 rename TEMP table to PREV table

The data is then uploaded from the perl program. The perl program dynamically constructs sql statements to do the upload and has some specific sub routines to handle CLOB cols so you cant actually see the sql. When I get round to it I may modify the program to show the SQL. There is one perl program which does the whole shabang and from a high level design perspective Im not 100% convinced it is the best method. These HOLD tables are just holding data prior to a data transformation that runs.

BTW Im juts the DBA the design of all this is by our perl/oracle developers. I just run the uploads and sort out the problems plus do some perl debugging.

Going back to the LOB storage parameters I will try setting them to CHUNK=8K (our db block size) and PCTVERSION=0 as we never change the data and set PCTFREE=0.

Do you have any suggestions on these parameter settings?

Below is the largest of one of our HOLD tables.

Thanks for any help you can give.

John Barron

ps we have a small bug in the above process of renaming tables. because we explicitly name the PK it travels with the table renames which can be a bit confusing. We intend to go back to system generated ones.

CREATE TABLE CR_HLD_QISI_calls

         pkey                 Integer NOT NULL,
         defectcall           Integer NULL,
         callcalldup          INTEGER NULL,
         agentcall            Integer NULL,
         customercall         Integer NULL,
         workgroupcall        INTEGER NULL,
         ownercall            Integer NULL,
         solutioncall         Integer NULL,
         CALLSTATUS           VARCHAR2(20) NOT NULL,
         ORIGIN               VARCHAR2(20) NULL,
         PRIORITY             VARCHAR2(20) NULL,
         problem              VARCHAR2(240) NOT NULL,
         action               VARCHAR2(240) NULL,
         datereported         DATE NULL,
         dateassigned         DATE NULL,
         dateowned            DATE NULL,
         dateresolved         DATE NULL,
         datemodified         DATE NULL,
         modifiedby           VARCHAR2(20) NULL,
         nextcontactdate      DATE NULL,
         datepending          DATE NULL,
         WHYPENDING           VARCHAR2(30),
         problemtext          CLOB NULL,
         analysistext         CLOB NULL,
         history              CLOB NULL,
         rdproductcall        INTEGER NULL,
         TECHNICAL_IMPACT     VARCHAR2(20) NOT NULL,
         PSOS_CLASS           VARCHAR2(30) NULL,
         MX_CLASS             VARCHAR2(30) NULL,
         target               VARCHAR2(80) NULL,
         prod_ver             VARCHAR2(80) NULL,
         comp_ver             VARCHAR2(80) NULL,
         tools_ver            VARCHAR2(80) NULL,
         host                 VARCHAR2(80) NULL,
         host_os_ver          VARCHAR2(80) NULL,
         PRODUCT_LINE         VARCHAR2(35) NOT NULL,
         external_id          VARCHAR2(80) NULL,
         esc_status           INTEGER NULL,
         esc_summary          CLOB NULL,
         WHYCLOSED            VARCHAR2(30) NULL,
         board                VARCHAR2(80) NULL,
         TOOLS                VARCHAR2(20) NULL,
         datedefectlink       DATE NULL,
         DATE_EXTRACTED       DATE NULL,
         DATE_UPLOADED        DATE NULL,
         SOURCE_DATA_FILE     VARCHAR2(50) NULL,
         SOURCE_PARTITION     VARCHAR2(30) NULL,
         XFORM_PROCESSED_FLAG VARCHAR2(10) NULL,
         Changed_Flag         Varchar2(10) NULL,
         CONSTRAINT CR_HLD_QISI_calls_PK
         PRIMARY KEY (pkey)
         USING INDEX
                TABLESPACE &&idxsp

) TABLESPACE &&tblsp

  LOB (analysistext) store as (tablespace &&lobsp)
  LOB (esc_summary) store as (tablespace &&lobsp)
  LOB (history) store as (tablespace &&lobsp)
  LOB (problemtext) store as (tablespace &&lobsp)

storage(initial 128m next 128m pctincrease 0) PCTFREE 0 ; At 09:56 AM 6/28/00 -0800, you wrote:
>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-----
>Sent: Tuesday, June 27, 2000 5:26 PM
>To: Multiple recipients of list ORACLE-L
>
>
>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-----
>Sent: Tuesday, June 27, 2000 2:28 PM
>To: Multiple recipients of list ORACLE-L
>
>
>Hi
>
>
>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.
>
>
>
>
>Table altered.
>
>
>
>
>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
>CR_HLD_QISI_CALLS ESC_SUMMARY 532,480
>CR_HLD_QISI_CALLS Total 41,533,440
>
>--
>Author: Steve Orr
> INET: sorr_at_arzoo.com
>
>Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
>San Diego, California -- Public Internet access / Mailing Lists
>--------------------------------------------------------------------
>To REMOVE yourself from this mailing list, send an E-Mail message
>to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
>the message BODY, include a line containing: UNSUB ORACLE-L
>(or the name of mailing list you want to be removed from). You may
>also send the HELP command for other information (like subscribing).

------=_NextPart_000_0029_01BFE272.9FCD1530 Content-Type: text/html;

charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =

http-equiv=3DContent-Type>

<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20

class=3D222345215-30062000>John,</DIV> <DIV><SPAN=20 class=3D222345215-30062000> </DIV> <DIV>Hmmm,=20
there must be something weird with that perl load stuff. The DBA = manuals=20
are somewhat deficient regarding LOB management but the "Application = Developer's=20
Guide - Large Objects" documentation actually has some good stuff for = DBA's.=20
There's a section about loading data into LOB's which may help. = Definitely a=20
strange phenomenon. Good luck and let us know what you=20 discover.</DIV>
<DIV><SPAN=20 class=3D222345215-30062000> </DIV> <DIV><SPAN=20 class=3D222345215-30062000> </DIV> <DIV>Steve=20
Orr</DIV>
<BLOCKQUOTE>
 <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr>-----Original Message----- From: root_at_fatcity.com=20 [mailto:root_at_fatcity.com]On Behalf Of John = Barron Sent:=20
 Thursday, June 29, 2000 11:09 AM To: Multiple recipients of = list=20
 ORACLE-L Subject: RE: 8i CLOB data needs a=20 lobotomy </DIV>Steve We created the database from = scratch=20
 and this was our first data load into a new database. Just to recap = the=20
 initial datafiles was 245M and it ended up consuming 900M in the CLOB=20 tablespace. Ive just looked at our table create for the CLOB = tables and=20
 noticed that there is no storage clause in the LOB parameters section. = When we=20
 created this we set the table PCTFREE to 0 and I also asked the = devlopers to=20
 do the same with LOBS. Anyway it has not been done. At present we use = the=20
 defaults CHUNK=3D8K (our db block size) and PCTVERSION=3D10. I also = assume that=20
 PCTFREE is set to default of 50 which could account for some of the = space=20
 used. Im still not quite sure how the PCTVERSION would affect the data = storage=20
 (the manual is not all that clear). Our process for uploading = the data=20
 (all done through a perl program) is: 1 rename the HOLD table = to=20
 TEMP 2 rename the PREV table (which has been truncated as it holds = the=20
 previous load data) to HOLD 3 rename TEMP table to PREV = table The=20
 data is then uploaded from the perl program. The perl program = dynamically=20
 constructs sql statements to do the upload and has some specific sub = routines=20
 to handle CLOB cols so you cant actually see the sql. When I get round = to it I=20
 may modify the program to show the SQL. There is one perl program = which does=20
 the whole shabang and from a high level design perspective Im not 100% =

convinced it is the best method. These HOLD tables are just holding = data prior=20
 to a data transformation that runs. BTW Im juts the DBA the = design of=20
 all this is by our perl/oracle developers. I just run the uploads and = sort out=20
 the problems plus do some perl debugging. Going back to the LOB = storage=20
 parameters I will try setting them to CHUNK=3D8K (our db block size) = and=20
 PCTVERSION=3D0 as we never change the data and set = PCTFREE=3D0. Do you have=20
 any suggestions on these parameter settings? Below is the = largest of=20
 one of our HOLD tables. Thanks for any help you can = give. John=20
 Barron ps we have a small bug in the above process of renaming = tables.=20
 because we explicitly name the PK it travels with the table renames = which can=20
 be a bit confusing. We intend to go back to system generated ones.=20 CREATE TABLE CR_HLD_QISI_calls (=20       =20 =
pkey           &nb= sp;    =20
 Integer NOT NULL,       =20 defectcall           = Integer=20
 NULL,       =20 callcalldup          = INTEGER=20
 NULL,       =20 =
agentcall          &nbs= p;=20
 Integer NULL,       =20 customercall         Integer = NULL,=20
       =20 workgroupcall        INTEGER NULL,=20       =20 =
ownercall          &nbs= p;=20
 Integer NULL,       =20 solutioncall         Integer = NULL,=20
       =20 CALLSTATUS           =

VARCHAR2(20) NOT NULL,       =20 =
ORIGIN           &= nbsp;  =20
 VARCHAR2(20) NULL,       =20 =
PRIORITY          &nbsp= ; =20
 VARCHAR2(20) NULL,       =20 =
problem           =   =20
 VARCHAR2(240) NOT NULL,       =20 =
action           &= nbsp;  =20
 VARCHAR2(240) NULL,       =20 datereported         DATE = NULL,=20
       =20 dateassigned         DATE = NULL,=20
       =20 =
dateowned          &nbs= p;=20
 DATE NULL,       =20 dateresolved         DATE = NULL,=20
       =20 datemodified         DATE = NULL,=20
       =20 modifiedby           =

VARCHAR2(20) NULL,       =20 nextcontactdate      DATE NULL,=20       =20 datepending          DATE = NULL,=20
       =20 WHYPENDING           =

VARCHAR2(30),       =20 problemtext          CLOB = NULL,=20
       =20 analysistext         CLOB = NULL,=20
       =20 =
history           =   =20
 CLOB NULL,       =20 rdproductcall        INTEGER NULL,=20

  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  TECHNICAL_IMPACT&nbsp;&nbsp;&nbsp;&nbsp; VARCHAR2(20) NOT NULL,=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  PSOS_CLASS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =

VARCHAR2(30) NULL,       =20 =
MX_CLASS          &nbsp= ; =20
 VARCHAR2(30) NULL,       =20 =
target           &= nbsp;  =20
 VARCHAR2(80) NULL,       =20 =
prod_ver          &nbsp= ; =20
 VARCHAR2(80) NULL,       =20 =
comp_ver          &nbsp= ; =20
 VARCHAR2(80) NULL,       =20 =
tools_ver          &nbs= p;=20
 VARCHAR2(80) NULL,       =20 =
host           &nb= sp;    =20
 VARCHAR2(80) NULL,       =20 host_os_ver          = VARCHAR2(80)=20
 NULL,       =20 PRODUCT_LINE         = VARCHAR2(35) NOT=20
 NULL,       =20 external_id          = VARCHAR2(80)=20
 NULL,       =20 esc_status           = INTEGER=20
 NULL,       =20 esc_summary          CLOB = NULL,=20
       =20 =
WHYCLOSED          &nbs= p;=20
 VARCHAR2(30) NULL,       =20 =
board           &n= bsp;   =20
 VARCHAR2(80) NULL,       =20 =
TOOLS           &n= bsp;   =20
 VARCHAR2(20) NULL,       =20 datedefectlink       DATE NULL,=20       =20 DATE_EXTRACTED       DATE NULL,=20       =20 DATE_UPLOADED        DATE NULL,=20

  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  SOURCE_DATA_FILE&nbsp;&nbsp;&nbsp;&nbsp; VARCHAR2(50) NULL,=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  SOURCE_PARTITION&nbsp;&nbsp;&nbsp;&nbsp; VARCHAR2(30) NULL,=20
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; XFORM_PROCESSED_FLAG =

VARCHAR2(10)=20
 NULL,       =20 Changed_Flag         = Varchar2(10)=20
 NULL,        CONSTRAINT=20 CR_HLD_QISI_calls_PK        PRIMARY = KEY=20
 (pkey)        USING INDEX=20 =
            &nb= sp; =20
 TABLESPACE &&idxsp  ) TABLESPACE &&tblsp = LOB=20
 (analysistext) store as (tablespace &&lobsp) LOB = (esc_summary)=20
 store as (tablespace &&lobsp) LOB (history) store as = (tablespace=20
 &&lobsp) LOB (problemtext) store as (tablespace=20 &&lobsp) storage(initial 128m next 128m pctincrease = 0) PCTFREE 0=20
 ; At 09:56 AM 6/28/00 -0800, you wrote: >Can = you=20
 check the before and after storage definitions for the=20 tables/CLOBS? >Maybe the tables were created one way but the = move=20
 altered the way things >are stored. Inline to out-of-line, = shouldn't=20
 matter. Pctversion defaults to >10, what's the before/after. = Chunksize?=20
 I know the storage definitions for >LOBS are important as = someone here=20
 managed to "CLOBber" the system >tablespace which was on = autoextend.=20
 Fragmentation maximo! (This was on a >development=20 database.) > >Can you share the query that produced the=20 before/after storage results? I'm >just getting started in the = LOB=20
 scene. I'm anticipating increased LOB usage >so I need to nail = down all=20
 the storage and operational issues. > >We'll be curious as = to what=20
 you discover on this one. Please keep us=20 posted. > > >Thanks, >Steve=20 Orr > > >-----Original Message----- >Sent: = Tuesday,=20
 June 27, 2000 5:26 PM >To: Multiple recipients of list=20 ORACLE-L > > >Thanks for the ideas steve. The = tablespace was=20
 empty before the load. This >is our first test run so we = re-creted the=20
 whole schema from scratch. This >happens on all our perl data = loads=20
 where we are importing into CLOB columns. >I have about 12 = tables where=20
 this is happening and in each case I shrink the >data down to = about 5%=20
 or less than the orginal space it was taking. Ive also >checked = the=20
 index storage and its not the problem. I have to rebuild = the >indexes=20
 after this as the move table command renders them=20 invalid. > >anyway its not a major problem just some = weirdness=20
 either in the perl DBD >loads or the way oracle stores CLOBS = from an=20
 insert. > >John Barron > >At 02:54 PM 6/27/00 = -0800,=20
 you wrote: > >What about the CRTS_QISI_LOB tablespace? = What's the=20
 before/after on it? Did >the clobs start out in the CRTS_DATA=20 tablespace? No lobs in the system >tablespace, right? Check the=20 tablespace_name in dba_segments where >segment_type=20 in('LOBSEGMENT','LOBINDEX'). Just some ideas... happy=20 lob >hunting. >HTH, >Steve Orr >-----Original=20 Message----- >Sent: Tuesday, June 27, 2000 2:28 PM >To: = Multiple=20
 recipients of list =
ORACLE-L > > >Hi > > >I=20 think my 8i CLOB data needs a labotomy. This is my problem and my=20 work >around. We use perl DBD::Oracle to load our database from = flat=20
 files. Part >of it is to load embedded  text data into CLOB = columns=20
 in our table >CR_HLD_QISI_CALLS. The CLOB cols are PROBLEMTEXT,=20 ANALYSISTEXT, etc. When we >run the perl script the 100M text = file=20
 mushrooms out to 900M in the >tablespace. Using the tablespace = coalesce=20
 command has no affect on the >tablespaces. If we  MOVE the = tables=20
 and CLOB data to another tablespace (or >even in the same = tablespace)=20
 and compress to one extent it shrinks the 800M >down to=20 40M. > > >Why does it take so much tablespace? Is it = the way=20
 perl loads data? We have >set default storage on the tablespace = and=20
 tables to PCTFREE=3D0 as there will >be no updates to this = table. The=20
 database is UTF8 with NLSLANG=3Dja16euc and >we do have some = indexes on=20
 the tables but none of this accounts for the huge >space = requirements=20
 for the initial upload. > > >Any comments, pointers = would be=20
 appreciated. Ive added our move sql and the >space used before = and after=20
 the table move and=20
 coalesce. > > >tia > > >John=20 Barron > > > > >The SQL for moving the = CLOBS and=20
 =

tables<BR>&gt;------------------------------------------------------<BR>&=

gt;alter=20
 table CRTS.CR_HLD_QISI_CALLS move tablespace CRTS_DATA >lob=20 (PROBLEMTEXT) store as (tablespace =
CRTS_QISI_LOB >storage(minextents=20 1)); >alter table CRTS.CR_HLD_QISI_CALLS move >lob = (ANALYSISTEXT)=20
 store as (tablespace CRTS_QISI_LOB >storage(minextents = 1)); >alter=20
 table CRTS.CR_HLD_QISI_CALLS move >lob (HISTORY) store as = (tablespace=20
 CRTS_QISI_LOB >storage(minextents = 1)); > > >alter=20
 tablespace CRTS_QISI_DATA coalesce; > > >alter table =

CRTS.CR_HLD_QISI_CALLS move tablespace CRTS_QISI_DATA >lob = (ESC_SUMMARY)=20
store as (tablespace CRTS_QISI_LOB >storage(minextents=20 1)); > > > > >The BEFORE and AFTER space =

output<BR>&gt;-------------------------------------------------<BR>&gt;Or=

acle8i=20
Enterprise Edition Release 8.1.6.0.0 - Production >With the = Partitioning=20
option >JServer Release 8.1.6.0.0 =20 =

Production<BR>&gt;<BR>&gt;<BR>&gt;Table&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  CLOB Col<BR>&gt;CR_HLD_QISI_CALLS&nbsp;&nbsp;&nbsp;=20

=
PROBLEMTEXT          &n= bsp;    =20
 64,430,080 >CR_HLD_QISI_CALLS   =20 =
ANALYSISTEXT          &= nbsp;  =20
 469,114,880 >CR_HLD_QISI_CALLS   =20 =
HISTORY           =        =20 279,552,000 >CR_HLD_QISI_CALLS   =20 =
ESC_SUMMARY          &n= bsp;     =20
 1,597,440 >CR_HLD_QISI_CALLS   =20 =
Total           &n= bsp;        =20 814,694,400 > > >Table=20

  altered.<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;Table=20
  altered.<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;Table=20
  altered.<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;Tablespace=20
  altered.<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;Table=20
  altered.<BR>&gt;<BR>&gt;<BR>&gt;CR_HLD_QISI_CALLS&nbsp;&nbsp;&nbsp;=20

=
PROBLEMTEXT          &n= bsp;    =20
 39,936,000 >CR_HLD_QISI_CALLS   =20 =
ANALYSISTEXT          &= nbsp;      =20 532,480 >CR_HLD_QISI_CALLS   =20 =
HISTORY           =            =20 532,480 >CR_HLD_QISI_CALLS   =20 =
ESC_SUMMARY          &n= bsp;       =20 532,480 >CR_HLD_QISI_CALLS   =20 =
Total           &n= bsp;         =20 41,533,440 > >-- >Author: Steve Orr >  = INET:=20
 sorr_at_arzoo.com > >Fat City Network = Services    --=20 Received on Fri Jun 30 2000 - 11:07:32 CDT