EXADATA Developer - 7

EXADATA Developer - 7
> Classic Database I/O and SQL Processing Model
  - WHERE 조건에 맞는 데이터들을 읽기 위해서 Block 단위의 I/O를 한다.
  - 읽은 데이터의 양이 10GB이고, 네트워크를 통해서 DB로 보내줌.
  - DB 서버에서는 Filtering 작업을 통해서 2MB만 returned.
> Exadata Smart Scan Model (Cell Offloading)
  - iDB command (SQL 정보들 포함)
  - Cell Server 프로세스가 iDB Commend 안에 있는 SQL Processing.
  - Filtering 되어, 2MB만 DB Server로 return.
  - 그럼 DB가 하는 일은, Cordinator (작업을 모으는 것)
    - Cell Server가 여러개이니, 마치 Parral procesing처럼 여러 Cell Server의 데이터들을 모으는 작업이 필요.
      - Parral Process는 DOP (Degree of prallelism) 개수가 중요.
      - resource를 많이 써서 빨리 처리해야 하는 작업인지의 판단이 중요.
      - Parral process는 load balancing이 필요함. 처리 결과들을 모두 모으는 작업이 필요.
> Exadata Smart Storage Capabilities
  1. Predicate filtering
  2. Column filtering : 꼭 원하는 columm만 지정해라!
  3. Function offloading
  - SELECT * FROM v$sqlfn_metadata WHERE offloading = 'YES';인 경우만 지원.
> Exadata Smart Storage Capabilities
  - DW 환경에서, 여러 곳에 흩어져 있는 데이터들을 모은, 분석의 대상이 되는 것을 Fact라고 함.
  - 그리고 분석의 대상이 되는 여러 조근들을 dimension이라고 함.
  - 이런 DW 환경의 Fact, dimension의 관계를 Star Schema라고 함.
  - 또한 Fact와 dimension 간의 Join을 Start join이라고 함.
  - 예를 들어,
    SELECT
    FROM cust  c,
         sales s,
    WHERE c.cust_id
        = s.cust_id
    AND c.cust_id > 300
    원래는 Join하고 filtering했는데,
    먼저 선 Filtering하고 Join하겠다. (Bloom Filter)
  - 이 Bloom Filter를 Cell Server에서 진행해줌.
  - DB에서 처리된 암호화된 데이터를 복호화하는 작업을 Cell Server가 함.
  - 압축을 하는 이유는 Storage를 덜 쓰고, 압축된 데이터를 읽으면 I/O 성능을 높이기 위해서.
    압축 해제 작업을 Cell Server가 대신하겠다.
  - Data Mining 관련된 내장 함수 (Scoring)가 있음. (예를 들어 prediction_probability()) 이 작업도 Cell Server가 해주겠다.
  - 테이블 스페이스를 만들 때, 포맷 작업이 필요한데, Cell Server가 DB 대신 해줌
  - incremental backup이란 변경된 블럭만 백업하는 작업인데, 그럼 변경됐는지 알려면 블럭 변경에 되한 추적 작업 (Block Change Tracking)이 필요. 이 작업을 Cell Server가 Offloading해서 알아서 함.
  - RMAN(Recovery MANager) : 시스템이 데이터 깨지면 Recovery해줌.
    어제 backup했는데, 오늘 깨진 경우를 예로 생각해보자.
    먼저 어제 시점으로 restore함. (이때 이 작업을 Cell Server가 대신)
    그리고 오늘까지 redo log를 통해서 재실행.
> Exadata Smart Scan Scale-Out: Example
  - Dual Active/Active이니, 80Gb/s (10GB/s) (네트워크는 bit 단위)
  - HC Type의 경우 : 초당 디스크에서 읽을 수 있는 데이터의 양은 1.8GB/s로, 14개의 Cell이 있으면 20GB/s
  - Flash Cache인 경우 : 263 GB/s
> Exadata Smart Scan Scale-Out: Example (다음 페이지, Without Smart Scan)
  - 4800GB를 읽는 경우, 8분 걸린다. 14개의 셀 노드에 고르게 분포 되어 있는 전제.
    (4800GB / (10GB/s) / 60 = 약 8분)
> Exadata Smart Scan Scale-Out: Example (다음 페이지, With Smart Scan)
  - 빠르다.
> Smart Scan 동작 전제 조건
  1. Multi Block I/O
  2. direct path read
  3. cell_offload_processing 파라미터가 TRUE
  - 실행 계획을 확인해서 Smart Scan이 될 지 여부 판단은 못함. -> 통계를 통해서 확인해야 함. (V$SQL)
> Full Scan하는 경우, DB Buffer에 올리면 메모리가 많으니, direct path read하려고 함.
> Hybrid Columnar Compression: Overview
  1. DW Compression의 쿼리 성능을 높이기 위한 경우
  2. Archival Compression : 오래된 데이터 압축
  - ILM(Information Lifeccle Management)를 하기 위해서, 쓰지는 않지만 DB 內 필요한 경우 有. 그래서 이런 경우 압축 기술 사용하면 좋다.
  - HCC를 하는 이유는, row보다 column level의 압축이 같은 데이터가 나올 확률이 많으니, 이 부분에 대해서 같은 symbol로 대체하여 압축.
  - unique하면 압축할 이유가 없지.
> Hybrid Columnar Compression: Data Organization
> 압축 / OLTP (row 단위의 압축 방법)
  - PCTFREE Reached되면 압축
    - 8K짜리 블럭이 있다고 하자. 그 블럭에는 블럭 정보가 있는 Header가 있고, 아래부터 데이터가 쌓임.
    - 테이블의 전체 로우가 1000이라고 가정 하자. Full table scan한다고 하면, 블럭에 넣을 수 있는 데이터가 100개면 10번 블럭 읽어야 하고, 200개면 5번 블럭 읽어야 함.
    - 그래서 하나의 블럭 안에 넣을 수 있는 데이터의 양을 설정해야 하므로, PCTFREE, PCTUSED라는 옵션이 필요. (PCTUSED는 이제 사라짐)
    - 테이블 Create할 때, PCTFREE와 PCTUSED 옵션을 줌.
    - PTCTFREE는 10으로 주고, PCTUSED는 40을 기본적으로 주는데, 그 의미는
      1. PCTFREE는 블럭의 위에서부터 10 퍼센트는 사용하지 않음. Update 시 row가 늘어갈 때를 대비해서.
      만약 이 옵션이 없어서 블럭이 차게 되면 다른 블럭으로 이동하는 row migration 작업이 일어남. row migration이 일어나면 I/O 작업이 늘어남.
      2. PCTUSED는 밑에서 40퍼센트인데, 블럭에 Insert 조건으로 40퍼센트 아래인 경우에만 insert 허가해줌.
  - PCTUSED는 사라졌고, 요즘에는 블럭을 4등분함.
    - PCTFREE가 40%인 경우, PCTFREE는 위에서 내려오는 거니 50% 아래인 경우에만 Insert됨.
    이런 것들을 10g에서 나온 ASSM이라고 함 (Automatic Segment Storage Management) => Buffer Busy Waits.
> 테이블 압축 고려 사항
  - OLTP 업무 성격의 테이블에는 OLTP 압축을 사용
  - HCC는 Query, Archival의 경우 이용.
    - QUERYLOW, QUERYHIGH, ARCHIVELOW, ARCHIVEHIGH
  - Partitioned Table 별로 압축 방법을 달리 할 수 있음.
> HCC된 상태에서 DML 작업하는 경우 오버헤드
  - Archive High로 Compress되어 있는 경우, Direct path insert시에는 신규 CU를 생성해서 append.
  - 근데 보편적인 Insert하면, OLTP 압축해서 Append.
  - UPDATE는 심지어 기존 HCC된 CU에서 해당 부분을 삭제하고, OLTP로 압축해서 다시 넣어줌.
> Oracle 12c에서부터 HCC Row Level Locking 지원.
  - 테이블 생성시 명시적으로 지정
> 12.1.0.2 : in-memory option들 추가.
  - column store를 지정하게 되면
    : IMCS(In Memory Column Store) 메모리에 Physical Read할 때 IMCS로 Column 데이터를 올림.
  - 속도가 더 빠름