'2011/05'에 해당되는 글 1건

  1. 2011.05.04 Oracle에 SSD(Flash Disk)를 사용한다면 (8)

Window 7을 사용하는 사람들은 ReadyBoost 기능을 잘 알 것이다. 부팅 시에 필요한 정보를 성능이 우수한 Flash Disk(USB)에 넣음으로써 부팅속도를 향상시키는 것이다. 즉 부팅 시에 성능이 느린 Hard Disk를 사용하지 않으므로 성능이 향상된다. 이와 비슷한 기능이 오라클에도 있다.

 

Oracle 11.2부터 Database Smart Flash Cache라는 것이 추가되었다. 이 개념은 buffer cache Aging Out되어 Disk로 내려가는 단점을 보완한 것이다. buffer cache에서 Aging Out 되더라도 성능이 우수한 Flash Disk(SSD)로 내려가는 개념이다. 따라서 SSD Aging out된 블록을 다시 읽을 때 기존 Disk보다 빠른 성능을 낼 수 있다. Database Smart Flash Cache 기능이 추가되어 메모리 구조도가 약간 변경되었다.
 

그림의 출처: Database Administrator's Guide 11g Release 2


Flash Disk
2 cache로 사용하는 셈이다. 하지만 Flash Disk에서 조차 aging out될 때는 Disk로 내려가는 것은 막을 수 없다.

 

제약사항

반드시 솔라리스나 오라클 엔터프라이즈 리눅스를 사용해야 한다.

 

어떨 때 사용해야 되나?

아래의 세 가지 경우를 모두 만족하면 Database Smart Flash Cache를 고려해야 한다.


첫 번째, AWR이나 Statspack에서 Buffer Pool Advisory를 참조하여 buffer cache가 부족한 경우

두 번째, db file sequential read Top Wait Eevnt일 경우

세 번째, 여분의 CPU가 있는 경우

 

위의 세 가지 경우를 모두 만족해야 되는 이유는 기존의 Disk에도 약간의 Cache기능이 있으므로, 위의 조건과 같이 buffer cache가 부족하거나 aging out이 많이 발생하는 경우만 성능향상의 폭이 크기 때문이다.

 

All or Nothing

RAC인 경우 하나의 SSD Disk를 다른 노드에 공유할 수 없다. , 노드별로 Smart Flash Cache를 별도로 설정해야 한다. 또한 하나의 노드에 Database Smart Flash Cache를 설정하였으면 나머지 노드에도 모두 Smart Flash Cache를 설정해야 한다.

 

Database Smart Flash Cache Size 설정

Flash Cachebuffer cache 2~10배 정도를 권고한다. Flash Cache의 Sizebuffer cache 2배보다 작으면 효과를 볼 수 없다.

 

Parameters

db_flash_cache_file:

Flash Cache로 사용할 파일의 경로를 설정한다. 만약 파일이 없으면 오라클이 startup시에 생성한다. 반드시 SSD내의 경로를 사용해야 한다. 그렇지 않으면 성능이 떨어진다.
:/dev/fioa1


db_flash_cache_size:

Giga 단위로 기술해야 한다. 이 파라미터를 0으로 설정하면 Database Smart Flash Cache기능이 Disable된다. 이 파라미터는 scope = memory 옵션을 사용할 수 없다. 따라서 이 파라미터를 적용하려면 Shutdown Startup이 필요하다.

: 16G

 

Buffer Cache 튜닝

aging out이 발생하여 buffer cache에서 Flash Cache로 밀려날 때에도 블록의 메타정보는 그대로 남게 된다. 그 메타정보는 어림잡아 한 블럭당 100 byte 정도이다. 만약 RAC라면 한 블럭당 200 byte를 차지한다. 이 메타정보는 블록이 flash cache로 이동될 때 flash cache내의 address 정보를 가지고 있을 것으로 추측된다. 만약 Flash Cache를 사용할 것이라면 buffer cache block 100 byte 정도(RAC라면 200 byte) 줄어들므로 그만큼 더 잡아주기 바란다.

 

필자의 여건상 Database Smart Flash Cache를 테스트 해볼 수 없다. 누가(SSD를 보유한 사람이) 테스트를 하여 후기를 올려주었으면 한다. 테스트 시나리오는 아래와 같다. Flash Cache의 적용 전/후의 성능을 비교하는 것이다. 나라면 이렇게 테스트 할 것이다.

 

Database Smart Flash Cache 미적용 시나리오

1. buffer cache를 아주 작게 잡는다.

2. 큰 테이블 두 개에 각각 사이즈가 큰 인덱스를 하나씩 만들어 Nested Loop Join을 시키면 aging out이 발생될 것이다.

 

Database Smart Flash Cache 적용 시나리오

1. buffer cache를 아주 작게 잡는다.

2. Database Smart Flash Cache기능을 Setup 한다.

3. 큰 테이블 두 개에 각각 사이즈가 큰 인덱스를 하나씩 만들어 Nested Loop Join을 시키면 aging out이 발생될 것이다.

 

측정항목

AWRdb file sequential read의 부하가 얼마나 줄어드는지 관찰한다.

Nested Loop Join의 전체건 처리 속도는 얼마나 빨라지는지

 

이상으로 Oracle 11.2에 추가된 Database Smart Flash Cache 기능에 대해 살펴보았다.  한가지 이상한 점은 Database Smart Flash Cache 기능을 HP IBM 서버 등에는 사용할 수 없다는 것이다. 요즘 Oracle HP와 사이가 좋지 않다. 오라클의 가격정책도 이런 사실을 증명해준다. 돌아올 수 없는 강을 건넌 것인가? 아니면 Oracle 다음 버전(V 12)에서 HP IBM서버도 지원 할 것인가? 나는 전자라고 생각한다.

 

Reference:

Oracle Database 11g Release 1 (11.2.0.1) New Features- 1.8.1.1 Database Smart Flash Cache

Oracle Database Administrator's Guide 11g Release 2-Configuring Database Smart Flash

저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by extremedb

댓글을 달아 주세요

  1. salvationism 2011.05.09 15:23 신고  댓글주소  수정/삭제  댓글쓰기

    [신기능들에 대한 불신과 베타 테스터]
    신기능을 쓰면 항상 따라오는 베타 테스터 라는 느낌.
    어떻게 보면 느낌이 아니라 사실 입니다.

    신기능이 늘어날 수 록..
    한편에서는 장애 포인트만 많아지네.. 이런 생각이 간혹 듭니다.

    ID 1260804.1 를 읽어 보면 ExaData에서
    판치고 있는 Wrong Result의 심각성과 늘어난 장애 포인트를 느끼게 됩니다.
    Exa 지원하면서 많이 느끼기도 했구요.

    smart flasg cache는 Exa에 비해 단순해서 좀 안정적일거라는 짐작은 합니다.
    운영에서의 적용은 번거로운면이 많이서 극히 일부만 쓰지 않을까하는.. ㅎㅎ;;

  2. 라튜니 2011.05.31 15:00 신고  댓글주소  수정/삭제  댓글쓰기

    다음글이 언제 포스팅 되는지 궁금합니다~ 요즘 포스팅이 너무 뜸하신거 같아요~

  3. NCDB 2011.05.31 19:20 신고  댓글주소  수정/삭제  댓글쓰기

    안녕하세요.
    동규님 좋은글 항상 감사하며 보고 있습니다.
    다름이 아니라 동규님 추천으로 relational database index design and the optimizers 란 책을 샀는데요.
    여기 챕터 끝나면 연습문제가 있는데 혹시 솔루션을 어디서 구할수 있는가 해서여.
    FTP로 들어가서 보니 답이 안나와 있습니다.
    바쁘시겠지만 답변 부탁드리겠습니다.
    감사합니다.

  4. ExtraOdinary 2011.06.01 17:40 신고  댓글주소  수정/삭제  댓글쓰기

    좋은 정보 잘 보았습니다. 보면서 한가지 의문이 드는데요. 기존 Buffer Cache에서 자주 밀려나는 Block 즉, FTS에 의해 Buffer Cache에서 자주 밀려나는 블록들이 Flash Cache에 캐싱이 될텐데요. 그 경우 기존의 FTS 보다 훨씬 속도 측면에서
    빨리질 것으로 생각이 됩니다.
    이런 경우 System statistics를 사용하는 환경에서 Multi Block I/O의 속도가 빨라져 실행계획이 FTS에 유리하도록 Cost 계산이 될 것 같은데, 이 때 실행계획이 바뀌는 현상은 없을까요?

  5. Favicon of http://www.battery-uk.co.uk BlogIcon batterypang 2011.10.21 15:05 신고  댓글주소  수정/삭제  댓글쓰기

    좋은 정보 잘 보았습니다. 보면서 한가지 의문이 드는데요. 기존 Buffer Cache에서 자주 밀려나는 Block 즉, FTS에 의해 Buffer Cache에서 자주 밀려나는 블록들이 Flash Cache에 캐싱이 될텐데요. 그 경우 기존의 FTS 보다 훨씬 속도 측면에서
    빨리질 것으로 생각이 됩니다.
    이런 경우 System statistics를 사용하는 환경에서 Multi Block I/O의 속도가 빨라져 실행계획이 FTS에 유리하도록 Cost 계산이 될 것 같은데, 이 때 실행계획이 바뀌는 현상은 없을까요?

  6. DBA 2011.12.14 19:24 신고  댓글주소  수정/삭제  댓글쓰기

    제 생각에는 차라리 Memory를 더 꽂아서 Buffer cache를 늘려주는게 어떨까 하는 것이구요.
    Storage 에도 캐쉬 메모리를 더 늘려주는 방안이 있을 수 있습니다. Read/write 캐쉬를 더 늘려주는 것이죠.

    Buffer cache내에서 Keep pool, recycle pool등을 활용하는 방안도 있을 수 있을 것이구요.

    물론 SSD를 2차 캐쉬처럼 쓰는 위의 방법도 나름 장점은 있을 것 같습니다. 이른바 하이브리드 구성인데요.
    SSD 가격이 비싸서 전체를 SSD로 하기에는 비용 문제가 너무 크다. 따라서 하이브리드 방식을 채택하다는 것인데,
    어느 정도 효과는 있을 것이 분명합니다.

    솔라리스하고 리눅스에서만 구성이 가능하다는 점은 범용적으로 쓰이기에는 한계가 있다는 것이 아쉽군요.

    또 하나 위에도 적었듯이 비용 문제인데요.
    SSD 살 돈으로 메모리 더 사고... 마그네틱 하드디스크 성능에 더 투자를 하는 방법대비 어느게 더 싸게 먹히느냐라는 문제가 있습니다.

  7. 유일환 2012.11.09 17:37 신고  댓글주소  수정/삭제  댓글쓰기

    블로그 매우 잘보고 있습니다. 좋은글 감사드립니다!!! 꾸벅!!