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

  • From: Yong Huang <yong321@xxxxxxxxx>
  • To: Kevin Jernigan <kevin.jernigan@xxxxxxxxxx>
  • Date: Wed, 1 May 2013 09:30:35 -0700 (PDT)

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@xxxxxxxxxx> wrote:

From: Kevin Jernigan <kevin.jernigan@xxxxxxxxxx>
Subject: Re: LOB Operation and SQL*Net Message From Client and cursor #0
To: yong321@xxxxxxxxx
Cc: elkinsl@xxxxxxxxxxx, oracle-l@xxxxxxxxxxxxx
Date: Wednesday, May 1, 2013, 11:23 AM




      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)
              Advanced Compression - ACO:
              Information Lifecycle Management - ILM
                Advanced Row Compression
              Temporal database (Total Recall etc)
                Advanced LOB Compression
                Advanced LOB Deduplication
              Database File System - DBFS
                RMAN Backup Compression
              Direct NFS Client - dNFS
                Data Pump Export Compression
                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
      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: