Oracle-L: RE: Conversion from CLOB to RAW

From: Burke, William F (Bill) <wbburke_at_avaya.com>
Date: Sat, 11 Jan 2003 10:33:37 -0800
Message-ID: <F001.0052D23E.20030111103337@fatcity.com>

The amount of data being stored is fairly significant @60G of xml transaction data. The developers want to apply a compression routine to the xml string which will save about 70% of the space currently in use. BLOB was my original recommendation, they were pushing to go RAW instead. We've only got a couple of CLOB's out there, but they are taking up huge amounts of storage. On the overkill note, most all of the XML has been parsed to less than 2K in length so one of my thoughts was we had introduced LOB functionality without really needing it.

The other aside to this is we will definately need to partition the data when we do the conversion as it currently resides in a traditional table as a CLOB.

Regards,

Bill Burke
"The Kinder and Gentler DBA"
IOUG University Master Class Faculty 2001-2002 "iDBA Management, High Performance Infrastructure and HA" IOUG Board of Directors 2000-2002
ODTUG Board of Directors 1996-2000
www.OracleGuru.com
www.KBMotorsports.biz

-----Original Message-----
[mailto:JApplewhite_at_austin.isd.tenet.edu] Sent: Friday, January 10, 2003 4:24 PM
To: Multiple recipients of list ORACLE-L

Bill,

I agree with Michael. You've already got the data in a "suitable datatype". Why move it to a cumbersome, soon-to-be-obsolete datatype? You can use DBMS_LOB functionality on LOBs, not on Raw.

I'd be so happy if the couple dozen tables in our 3rd party Student Information system that have Long or Long Raw columns had CLOB or BLOB columns instead. It would make converting them to partitioned tables much easier.

I definitely vote to keep your CLOBs.

Jack C. Applewhite
Database Administrator
Austin Independent School District
Austin, Texas
512.414.9715 (wk)
512.935.5929 (pager)
JApplewhite_at_austin.isd.tenet.edu

                      Michael Fontana

                      <mfontana_at_verio.n        To:       Multiple recipients
of list ORACLE-L              
                      et>                       <ORACLE-L_at_fatcity.com>

                      Sent by:                 cc:

                      root_at_fatcity.com         Subject:  Re: Conversion from
CLOB to RAW                   
 

 

                      01/10/2003 02:15

                      PM

                      Please respond to

                      ORACLE-L

 

 





At 11:30 AM 1/10/2003 -0800, Burke, William F (Bill) wrote:
      Here's where I get to ask the most likely simple question.

      I've inherited a database where it was built using a CLOB to hold XML
      data
      but we have now determined that was total overkill and want to move
      it to a
      RAW column or other suitable datatype.

      Looking for conversion issues or other alternatives.

Since Oracle is moving us away from LONG and RAW datatypes, I assume you want to convert from CLOB to BLOB? BLOB is probably more storage-efficient,
but since XML is made up of character data, I don't really understand the issue with
keeping it a CLOB.

What do you mean by overkill?

--

Please see the official ORACLE-L FAQ: http://www.orafaq.net
--

Author:
INET: JApplewhite_at_austin.isd.tenet.edu

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------

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).
--

Please see the official ORACLE-L FAQ: http://www.orafaq.net
--

Author: Burke, William F (Bill)
INET: wbburke_at_avaya.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------