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

From: Yong Huang <yong321_at_yahoo.com>
Date: Wed, 1 May 2013 09:30:35 -0700 (PDT)
Message-ID: <1367425835.76306.YahooMailClassic_at_web184803.mail.gq1.yahoo.com>



Hi Kevin,
Thanks for this info. We tested SecureFiles LOBs and are happy with its performance. But since our shop didn't purchase required licences (I believe it requires both Advanced Security and Advanced Compression), so far we haven't used it.

Yong Huang

  • On Wed, 5/1/13, Kevin Jernigan <kevin.jernigan_at_oracle.com> wrote:

From: Kevin Jernigan <kevin.jernigan_at_oracle.com> Subject: Re: LOB Operation and SQL*Net Message From Client and cursor #0 To: yong321_at_yahoo.com
Cc: elkinsl_at_verizon.net, oracle-l_at_freelists.org Date: Wednesday, May 1, 2013, 11:23 AM              

    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
            
            
              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-l
Received on Wed May 01 2013 - 18:30:35 CEST

Original text of this message