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

From: Yong Huang <yong321_at_yahoo.com>
Date: Wed, 1 May 2013 11:46:50 -0700 (PDT)
Message-ID: <1367434010.61353.YahooMailClassic_at_web184802.mail.gq1.yahoo.com>



You're absolutely right. I just read the statements about license at http://docs.oracle.com/cd/E11882_01/appdev.112/e18294/adlob_smart.htm Thanks for this clarification.
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: "Yong Huang" <yong321_at_yahoo.com>
Cc: elkinsl_at_verizon.net, oracle-l_at_freelists.org Date: Wednesday, May 1, 2013, 11:40 AM              

    SecureFiles is part of Oracle Database

      11g, and does not require you to license any options. If you want
      to compress and/or deduplicate your SecureFiles LOBs, then you
      need to license ACO, and if you want to encrypt your SecureFiles
      LOBs, then you need to license ASO.

      

      So, you can go forward in production with SecureFiles LOBs without
      having to license anything more than the database itself.

      

      -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 9:30 AM, Yong Huang wrote: 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 - 20:46:50 CEST

Original text of this message