오라클 - VARCHAR 열 대 4 K 행 미만의 행을 포함하는 CLOB 열의 성능이 저하 되었습니까?

Question

VARCHAR2 데이터 유형보다 CLOB 데이터 유형을 사용하는 것이 부정적입니까? 4KB 미만인 대부분의 문자열을 저장해야하는 경우?

here A부터 CLOB 테이블의 나머지 데이터와 상기 데이터 블록에 저장된 LOB 세그먼트에 대한 포인터, 별도 LOB 세그먼트에 저장 될 수있다. CREATE TABLE 문이있는 경우 LOB 저장 영역 절을 사용하여 LOB 세그먼트가 저장되는 위치를 제어 할 수 있습니다. 기본적으로 약 4000 바이트 미만의 LOB는 VARCHAR2와 동일한 방식으로 저장됩니다. 즉, 나머지 데이터와 인라인됩니다. here에서

는 :

당신이 CLOB 열이있는 테이블을 만듭니다 CLOB에 대한 '행 스토리지를 사용'이라는 옵션이 있습니다. 이것은 CLOB가 테이블과 같은 세그먼트에 저장되었는지, 따라서 테이블 행의 나머지 부분과 함께 저장되는지 또는 별도의 세그먼트에 저장되는지 여부를 지정합니다. 두 번째 경우에는 테이블 행에 CLOB 데이터의 위치에 대한 포인터가 포함됩니다. 일반적으로 테이블 행과 함께 CLOB를 저장하는 것이 더 효율적이지만 CLOB가 약 4000 자보다 긴 경우 더 이상 행에 저장 될 수 없으며 행의 저장 영역이 사용 가능한지 여부에 관계없이 CLOB 세그먼트에 저장됩니다 아닙니다.

이 문장에서 모든 행에 4K 행 미만이 포함되어 있어도 열을 CLOB로 선언 할 경우 패널티가 전혀없는 것처럼 들립니다. 정확합니까? 당신은 예를 들어, LOB 데이터 유형을 사용할 때

Answer 1

상당한 영향을 있습니다 : 데이터 행에 저장되는 경우에도

• 당신이 데이터를 읽을 방법에 따라 달라집니다
  는, 각 행의 LOB 액세스를 추가 네트워크 왕복을 의미 할 수
• Optimizer는 VARCHAR 열, 히스토그램, 훨씬 더 정확한 길이, 바인드 엿보기 등에 대해 더 많은 통계를 사용할 수 있습니다.
• LOB 열에서 일부 실행 계획 최적화를 사용할 수 없습니다. 예를 들어, 하위 서브 쿼리의 구체화
• 많은 SQL 기능 on은 LOB와 함께 사용할 수 없습니다. 추가적인 왕복의

예 오라클 각 왕복으로 또 다시 LOB 데이터를 포함하는 동일한 블록 프로세싱으로

HUSQVIK@hq_pdb_tcp> CREATE TABLE t_varchar AS SELECT CAST('data' AS VARCHAR2(4)) c1 FROM DUAL CONNECT BY LEVEL <= 10; 

Table created. 

HUSQVIK@hq_pdb_tcp> CREATE TABLE t_clob AS SELECT to_clob('data') c1 FROM DUAL CONNECT BY LEVEL <= 10; 

Table created. 

HUSQVIK@hq_pdb_tcp> SET AUTOT TRACE 
HUSQVIK@hq_pdb_tcp> SELECT * FROM t_varchar; 

10 rows selected. 


Execution Plan 
---------------------------------------------------------- 
Plan hash value: 4100862799 

------------------------------------------------------------------------------- 
| Id | Operation   | Name  | Rows | Bytes | Cost (%CPU)| Time  | 
------------------------------------------------------------------------------- 
| 0 | SELECT STATEMENT |   | 10 | 50 |  3 (0)| 00:00:01 | 
| 1 | TABLE ACCESS FULL| T_VARCHAR | 10 | 50 |  3 (0)| 00:00:01 | 
------------------------------------------------------------------------------- 


Statistics 
---------------------------------------------------------- 
      5 recursive calls 
      0 db block gets 
      5 consistent gets 
      5 physical reads 
      0 redo size 
     682 bytes sent via SQL*Net to client 
     551 bytes received via SQL*Net from client 
      2 SQL*Net roundtrips to/from client 
      0 sorts (memory) 
      0 sorts (disk) 
     10 rows processed 

HUSQVIK@hq_pdb_tcp> SELECT * FROM t_clob; 

10 rows selected. 


Execution Plan 
---------------------------------------------------------- 
Plan hash value: 3459655851 

---------------------------------------------------------------------------- 
| Id | Operation   | Name | Rows | Bytes | Cost (%CPU)| Time  | 
---------------------------------------------------------------------------- 
| 0 | SELECT STATEMENT |  | 10 | 410 |  3 (0)| 00:00:01 | 
| 1 | TABLE ACCESS FULL| T_CLOB | 10 | 410 |  3 (0)| 00:00:01 | 
---------------------------------------------------------------------------- 


Statistics 
---------------------------------------------------------- 
      2 recursive calls 
      0 db block gets 
     23 consistent gets 
      5 physical reads 
      0 redo size 
     3433 bytes sent via SQL*Net to client 
     3231 bytes received via SQL*Net from client 
     12 SQL*Net roundtrips to/from client 
      0 sorts (memory) 
      0 sorts (disk) 
     10 rows processed 

참고도 일관된 수의 증가는 얻는다.