long raw risk

Group,

I have just been given a project / database where a vendor will implement a table
with a LONG RAW field in it.

Oracle manuals state clearly that this datatype is outdated and should be replaced by BLOB, I quoted the manuals to vendor-support, but they will not move on this.

>From the looks of it, the table with the LR field
will become the largest table in the system, with well over a billion records in it after the 1st yr.

My main worry is inefficiency in retrieving records from the table, and most importantly, I cannot partition a table with long/longraw columns in it.

On first tests, the LRs are >1K, whereas the record-without-LR is avg 66 bytes.
In real-life, the LR is probably bigger still.

Quesions:

• Is there a real performance-risk ? Up to now, I always managed to offload LONG/BLOBs into separate tables or into LOB-storage clauses, but I see now way to do that here.
• Given the LongRaw datatype, what are my best defences against (potential) performance problems.

Anyone been-there-done-that ?

Regards,

PdV

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Piet de Visser
  INET: piet.de.visser_at_logicacmg.com

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