<11/08> 4 Walls

PPT 준비 및 이력서 수정

=============================================================================

Smart Scan? Cellsrv?

컴퓨터의 성능은 언제나 I/O 가 좌우한다 그중 DB는 더욱 그런데 SQL 튜닝도 결국 I/O 최소화를 위해 읽는 Block 수를 줄이려고 하는 것이고 엑사데이터는 풀 스캔의 비효율을 획기적으로 줄이는데 그 의의가 있다 그래서 OLTP 보다는 배치나 DW에 적합하고 혹은 혼합 워크로드 시스템에도 적합할 수 있다

Full Scan의 경우 일단 전체를 읽어보고 나서 필터링을 해야 하는데 엑사데이터의 경우 테이블을 30%정도 읽는다고 하면 나머지 70%는 읽지 않고 필요한 것만 멀티 블록 I/O로 퍼올리니 성능이 좋아진다 

11g부터는 일정 크기 이상의 테이블을 읽을 때 Buffer Cache가 아닌 PGA로 바로 퍼올리는 Serial Direct Path read Operation이 생겼는데 이 Direct Path Read 오퍼레이션만 엑사데이터에서 스마트 스캔의 대상이 된다 

스토리지가 지능을 가지고 필요한 블록만 걸러서 읽고 데이터베이스 서버로 반환하는 최적화를 스마트 스캔이라고 한다

Buffer Cache를 거치지 않고 바로 PGA로 올릴 경우 메모리 경합 및 래치를 신경쓰지 않는 나만의 공간으로 올린다는 것이고 기존에도 Parallel Query를 하면 Buffer Cache를 경유하지 않고 Direct Path read로 처리 가능했는데 11g 부터는 nono-PQ인 일반 오퍼레이션도 Direct path read가 가능해졌고 이를 이전의 Parallel Direct path read와 구분하기 위해 serial Direct path read라고 한다

10g에서도 사용가능 했지만 히든파라미터 였고 11g부터는 아예 기본적으로 활성화가 되서 나온다 스마트 스캔의 역할은 스토리지 -> 데이터베이스 엔진으로 보내는 데이터의 양을 획기적으로 줄여주기에 더 작은 I/O 대역폭으로 처리할 수 있다 

결국 엑사데이터와 기존 오라클 데이터베이스의 차이는 Storage rayer의 차이다 cellsrv라는 오라클 엔진과 비슷한 스토리지 I/O 처리 엔진이 탑재되어 있어 오라클 데이터베이스 엔진의 요청에 최적화된 I/O 요청을 처리해준다( 참고로 엑사데이터 스토리지는 리눅스가 설치되어 있으며 거기에 Cellsrv가 어플리케이션으로 실행된다)

예를 들어 오라클 데이터베이스가 where issue_dt='20120830'이라는 쿼리를 날리면 이 쿼리의 where 조건이 메타 정보로 cellsrv로 전달되고 그러면 셀 서버는 disk를 읽을 때 위의 issue_dt에 해당하는 블록만 정확하게 읽어서 데이터베이스 서버로 반환한다 원래 전통적인 오라클은 이렇게 처리하지 않고 일단 버퍼 캐시로 올리고 where 조건에 해당하지 않는 것은 필터링으로 버리고 해당하는 것만 운반 단위를 채워 클라이언트로 보내서 필요도 없는 블록을 잔뜩 퍼올리고 처리하는 비효율적인 면이 있었다

결국 엑사데이터에서의 스토리지는 그냥 달라는 대로 퍼주는 것이 아닌 지능을 갖추고 필요한 블록만 최소한 I/O로 처리하게 되며 이것이 성능의 핵심이다.