EXADATA Developer - 9

EXADATA Developer - 9
> HCC
  - Query 위주의 작업이 많이 발생하는 테이블에 대한 압축.
  - 테이블을 파티셔닝해서, Query 위주의 작업이 발생하는 파티션 테이블은 HCC, DML 작업이 많이 발생하는 파티션 테이블은 OLTP 압축 기법을 사용하는 것이 효율적.
> Caching Heuristics
  - DBA는 Object의 CELL_FLASH_CACHE라는 속성의 값을 정해주는 방식으로 Cache할 것인지 여부를 정할 수 있음.
> Exadata Storage Index: Overview
  - Cell 서버가 DB 서버가 하는 일들을 많이 하니, 바쁘다. 그래서 어떻게 하면 효율적으로 할 수 있을 지?
  - Storage Index는 Cell 서버 안에서 Pysical I/O의 총량을 줄이기 위한 메모리 기반 구조이다.
  - 적어도 한번 실행이 되어야 생성이 되며, 사람이 관리하는 내용이 아님.
  - Region Index라는 것이, 테이블에 Min, Max 값을 가지고 있어서, (즉 값의 범위를 가지고 있어서) 그 영역이 해당 되지 않으면 검색 X
  - Storage Index가 사용되지 않는 경우
    1. lob, raw 2. != 3. 형변환발생시 4. like 연산자 %
  - partition pruning과 유사
    - parsing time에 optimizer가 Query를 분석해서, 읽어야 하는 (Query의 대상이 되는) 파티션 테이블만 읽는 것.
> Storage Index with Partitions: Example
  - partition key로 설정하지 않은 column에 대해서도 Storage Index가 동작하여 성능이 개선된다.
> 12c의 지향점 : multi-tenant
  - Instance가 하나인데, DB가 여러개이다. => cloud
  - 이런 DB를 Container라고 하고, 이런 유형의 DB를 CDB라고 함.
> I/O Resource Management: Overview
  - 기존 전통적인 Storage Server는 FIFO 형태의 I/O
  - Exadata Storage Server는 Priority에 따라서 I/O Scheduler가 scheduling함.
  - 우선순위는 계정 그룹별로(Consumer Group), 서비스 별로 정할 수 있음.
> Cell-to-Cell Data Transfer
> Multiplied Benefits
> Exadata Benefits for Data Warehousing and Analytics
  - Dramatically하게 대량의 I/O throughput.
  - Query tuning이 무의미하게 될 정도로, Hardware 성능이 좋아졌다.
  - In-memory parallel query
    - direct path read
    : 서버 프로세스가 direct로 disk에서 읽어서 session memory에 올림
    - In-memory parallel query는 direct parallel query와 다름.
    : 테이블을 쪼개서 DB Buffer에 올림.
      - 그럼 데이터가 A, B로 쪼개져서 node 1, 2로 올라간 경우에, 만약 node 2에 A를 찾는 작업이 발생하면? Cache Fusion! (GRD(Global Resource Directory)가 모든 node 메모리 정보를 가지고 있어서, node1에 A가 있는 지 알고 있고, Cache Fusion을 통해서 A Instance를 가져옴)
      (http://www.slideshare.net/afareg/11g-r2)