Re: LOB Operation and SQL*Net Message From Client and cursor #0

  • From: Kevin Jernigan <kevin.jernigan@xxxxxxxxxx>
  • To: yong321@xxxxxxxxx
  • Date: Wed, 01 May 2013 09:23:35 -0700

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?


*Kevin Jernigan*        (650) 607-0392 (o)
*Senior Director Product Management*    (415) 710-8828 (m)
kevin.jernigan@xxxxxxxxxx <mailto:kevin.jernigan@xxxxxxxxxx>
*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
> --
> //


Other related posts: