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
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@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
> --
> //www.freelists.org/webpage/oracle-l
>
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
