태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

[퀴즈] Partitioned Table과 Insert 성능

오라클 2010.06.25 15:42
갑자기 퀴즈가 하고 싶어졌습니다. 지난 번 퀴즈가 너무 쉬웠다는 비난이 쏟아져서... @_@

1. 오라클 버전은 11.1.0.6입니다.

TPACK@ukja1106> select * from v$version where rownum = 1;

BANNER
-----------------------------------------------------------------------

Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
2. 파티션이 아닌 테이블 T1과 해시 파티션인 테이블 T2가 있습니다.
TPACK@ukja1106> create table t1(c1 number);

Table created.

Elapsed: 00:00:00.03
TPACK@ukja1106> create table t2(c1 number)
  2  partition by hash(c1) partitions 4;

Table created.

Elapsed: 00:00:00.01
3. 파티션이 아닌 테이블 T1에 대해 40만건을 Insert하는데는 1초가 조금 안걸립니다.
TPACK@ukja1106> insert into t1 select level from dual connect by level <= 400000;

400000 rows created.

Elapsed: 00:00:00.56
4. 해시 파티션인 테이블 T2에 대해 40만건을 Insert하는데는 무려! 6.3초가 걸립니다.
TPACK@ukja1106> insert into t2 select level from dual connect by level <= 400000;

400000 rows created.

Elapsed: 00:00:06.32
5. 자, 여기서 문제 나갑니다. 왜 이렇게 큰 성능 차이가 발생할까요?

관심있으신 분들 답변 달아보세요~ 답변 다시는 분 없으면 자삭하겠습니다. ㅎㅎ

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

제가 생각한 정답이 아래 댓글에 달렸습니다. 축하합니다! ㅎㅎ 선물은 없지만...

별도의 포스트를 통해 이 문제를 좀 더 다양한 테스트를 통해 논의하도록 하겠습니다.

저작자 표시
신고
Trackback 0 : Comments 6
  1. 스누피 2010.06.25 15:55 신고 Modify/Delete Reply

    두 가지 이유로 느려지는것 같습니다.

    첫 번째는 해시함수의 병목
    - 40만건의 데이터를 순차적으로 쌓는것과 해시함수를 한번씩 거치는 것에서 오는 병목이 첫번째 부하로 보여집니다.

    두 번째는 디스크 암(ARM)이 너무 바빠집니다.
    - 힙테이블의 경우 연속되는 블럭들의 집합인 익스텐트 하나에 40만건의 데이터를 순차적으로 기록하게 되므로
    디스크 암이 크게 움직일 필요가 없습니다. 하지만 해시 파티션의 경우 4개의 서브파티션들이 내부적으로는 각각 하나의 테이블 세그먼트 이기 때문에 각각의 익스텐트들을 가지고 있습니다. 골고루 분산되는 해시함수가 여기서는 쥐약이 됩니다. 데이터가 들어올때 마다 디스크 암은 다른 세그먼트의 익스텐트를 찾아야 하기 때문이죠.

    이상 2가지 예측이었습니다. 맞을런지는 과연.. ㅎㅎ

    • 욱짜 2010.06.26 21:02 신고 Modify/Delete

      1. 해시 함수에 의한 오버헤드는 거의 무시해도 좋을 정도입니다.

      2. 위의 테스트의 경우 디스크 IO는 전혀 발생하지 않습니다.

  2. Park 2010.06.25 17:52 신고 Modify/Delete Reply

    Hash메카니즘에 오버헤드가 있을거 같다는 막연한 짐작 뿐...
    잘 모르겠네요.. ㅡㅡa
    hash partition에서만 이럴거 같은데요..

    • 욱짜 2010.06.26 21:12 신고 Modify/Delete

      해시 함수에 의한 오버헤드는 무시할 정도입니다. 해시 파티션이 아닌 레인지나 리스트 파티션에서도 비슷한 일이(항상은 아니지만) 생길 수 있습니다.

  3. Eddy 2010.06.28 08:55 신고 Modify/Delete Reply

    테이블이 파티셔닝에 되어 있어,
    insert 할 때 insert 대상 블럭(버퍼)가 계속 바뀌게 되고,
    그로 인해 logical reads가 증가하기 때문인 것 같습니다.

    logical reads 증가는 여러 자원에 대한 경합의 증가를 의미하기도 하구요.

    이런 문제를 티팩으로 어떻게 찾아내고 해결할 지 궁금합니다. ㅋㅋ

    • 욱짜 2010.06.28 09:27 신고 Modify/Delete

      정답입니다.

      물론 티팩이 제공하는 리포트를 이용하면 어느 정도 도움을 얻을 수 있습니다. 별도의 포스트를 통해서 논의하도록 하겠습니다.

Write a comment

티스토리 툴바