Re: LOB Operation and SQL*Net Message From Client and cursor #0
Date: Wed, 01 May 2013 09:23:35 -0700
Message-ID: <51814187.7000608_at_oracle.com>
Yong,
It might be true that you should avoid LOBs for smaller-than-~4K character strings prior to 11g, but SecureFiles LOBs in 11g is designed to solve those performance issues. Have you seen similar issues with SecureFiles LOBs in 11g?
-KJ
*Kevin Jernigan* (650) 607-0392 (o) *Senior Director Product Management* (415) 710-8828 (m) kevin.jernigan_at_oracle.com <mailto:kevin.jernigan_at_oracle.com> *Advanced Compression - ACO*: *Information Lifecycle Management* - ILM Advanced Row Compression *Temporal database* (Total Recall etc) Advanced LOB Compression *SecureFiles* Advanced LOB Deduplication *Database File System* - DBFS RMAN Backup Compression *Direct NFS Client* - dNFS Data Pump Export Compression *CloneDB* Data Guard Redo Network Transport Compression *Database Resource Manager* - DBRM Flashback Data Archive History Table Optimization *Continuous Query Notification* - CQN *Hybrid Columnar Compression* - HCC *Index Organized Tables* - IOT *Database Smart Flash Cache* *OISP*
On 5/1/2013 8:43 AM, Yong Huang wrote:
>> Doing a test, converting the column to a char compared to an SQL
>> statement leaving it as a LOB, it completes very quickly as all the
>> special handling for a LOB, fetching it, etc, is no longer needed.
> I always tell the developers to avoid CLOB unless they know for sure the text will exceed 4000 characters. Most of them simply consider LOB to be longer varchar2, not knowing that there's quite a bit of difference between the mechanism to handle varchar2 and that to handle LOB (which is generally less efficient, and possibly over-engineered).
>
>> the front end limits the [LOB comments] field to 255 characters
> That's even worse in the design.
>
> Yong Huang
> --
> http://www.freelists.org/webpage/oracle-l
>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Wed May 01 2013 - 18:23:35 CEST