Oacle 파 티 션 시트 의 hash 파 티 션 시트 사용 및 확장

Hash 파 티 션 은 파 티 션 키 에 Hash 알고리즘 을 사용 하여 데이터 의 파 티 션 귀속 을 결정 합 니 다.Hash 파 티 션 을 사용 하면 어떤 장점 이 있 나 요?
자주 사용 하 는 파 티 션 표 가 가지 고 있 는 장점:예 를 들 어 데이터 사용 가능 줄 을 향상 시 키 고 관리 부담 을 줄 이 며 문장의 성능 을 개선 하 는 등 장점 이 있 습 니 다.hash 파 티 션 도 마찬가지 입 니 다.또한,Hash 파 티 션 표 는 파 티 션 키 의 hash 계산 결과 에 따라 파 티 션 을 결정 하기 때문에 특정한 파 티 션 키 의 hash 값 은 고정 되 어 있 습 니 다.즉,Hash 파 티 션 표 의 데 이 터 는 파 티 션 키 에 따라 모 였 습 니 다.같은 파 티 션 키 는 같은 파 티 션 에 있 을 것 입 니 다.예 를 들 어 증권 업계 에서 우 리 는 특정한 주식 의 K 라인 을 자주 조회 하 는데 가설 표 의 구 조 는 다음 과 같다.

create table equity
(
id number,
trade_date date,
……);

Equity 표 는 매우 클 수 있 습 니 다.equity 표 에 대한 조 회 는 보통 id 를 지정 하여 특정한 거래 날짜 나 특정한 시기 에 다른 정 보 를 조회 합 니 다.이런 상황 에서 우 리 는 어떻게 equity 표를 위해 구역 을 선택해 야 합 니까?표 자체 구조 만 봐 도 tradedate 열 은 범위 구역 으로 선택 하기에 적합 합 니 다.그러나 만약 에 우리 가 이렇게 구역 을 나 누 면 앞 에 필요 한 조회:특정한 id 를 지정 하고 특정한 범위 안의 거래 정 보 를 조회 합 니 다.예 를 들 어 1 년 동안 의 K 라인 을 보면 이런 조 회 는 항상 구역 을 뛰 어 넘 어야 합 니 다.우 리 는 분 구 표 에 대해 분 구 를 뛰 어 넘 는 조 회 를 하 는데 그 성능 이 그다지 좋 지 않 을 때 가 많다 는 것 을 알 고 있다.특히 이런 조 회 는 많은 분 구 를 뛰 어 넘 을 가능성 이 높다.우리 다시 id,tradedate 열 에 색인 을 만 들 면 되 잖 아 요.잘 생각해 보 세 요.그 렇 죠?이때 equity 표 의 데 이 터 는 tradedate 값 으로 모인,같은 tradedate 값 의 데 이 터 는 항상 하나의 데이터 블록 에 있 습 니 다.그러면 앞에서 설명 한 조 회 는 색인 을 통 해 방문 하 더 라 도 최종 적 으로 표를 읽 을 때 분 산 된 데이터 블록 을 읽 습 니 다.즉,모든 기록 은 표 데이터 블록 을 읽 어야 합 니 다.Hash 분 구 표를 만 들 면 데 이 터 를 hash 분 구 키 로 모 으 면 수요 에서 설명 하 는 조회 에 더욱 적합 합 니 다.같은 id 의 기록 은 반드시 같은 분 구 에 있 기 때 문 입 니 다.또한 같은 id 값 의 기록 이 같은 데이터 블록 에 떨 어 질 확률 도 높 아 지면 서'어느 정도'IO 를 감소 합 니 다.위 에서 hash 분 구 감소 IO 에 대한 설명 에 인용 부 호 를 붙 였 다.Hash 분 구 표 에 만 의존 하여 IO 작업 을 대폭 줄 이려 는 것 은 비 현실 적 이기 때문이다.특히 equity 표 에 기 록 된 주식 수가 매우 많 을 때 같은 주식 이 서로 다른 거래 일 에 발생 한 기록 은 물리 적 으로 도 같은 데이터 블록 에 모이 기 어렵다.실제로 우리 가 Hash 분 구 를 바탕 으로 equity 표 에 대해 IOT 표 의 조직 방식 을 사용 하면 앞에서 설명 한 조회 성능 이 크게 향상 된다.IOT 표 는 이 글 에서 토론 하 는 범위 안에 있 지 않 으 며,여 기 는 더 이상 토론 하지 않 는 다.우리 가 Hash 표를 사용 하기 로 결정 하기 전에 우 리 는 우리 가 선택 한 파 티 션 키 가 연속 적 으로 분포 되 거나 연속 적 인 파 티 션 에 가 까 운 지 확인 해 야 한다.그 밖 에 파 티 션 의 개 수 는 2 의 정수 멱 이 어야 한다.예 를 들 어 2,4,8.이런 요 구 는 Hash 함수 의 특징 에 의 해 결정 된다.이런 우리 파 티 션 표 의 각 파 티 션 에 포 함 된 데 이 터 량 이 비교적 평균 적 이다.
Hash 파 티 션 시트 확장:
Hash 파 티 션 테이블 은 add partition 명령 을 통 해 파 티 션 을 추가 합 니 다.Oracle 추천 구역 의 개 수 는 2 의 멱 이다.예 를 들 어 2,4,8.등 이다.이렇게 하면 데이터 가 각 구역 에 비교적 고 르 게 분포 되 는 것 을 확보 할 수 있다.물론 앞에서 말 한 바 와 같이 파 티 션 키 값 이 연속 분포 되 거나 연속 분포 에 가 까 워 야 한다.새로운 파 티 션 을 추가 할 때 기 존의 데 이 터 를 낡은 파 티 션 에서 새로운 파 티 션 으로 나 누 어야 합 니 다.그러면 이런 데 이 터 를 구분 할 때 소스 파 티 션 은 어떤 원칙 을 따 릅 니까?요점 은 다음 과 같다.만약 에 추가 할 구역 이 N 번 째 구역 이 고 N 과 같은 최소 2 의 정수 멱 이 M 이면 N 번 째 구역 을 추가 할 때 이 구역 의 데 이 터 는 구역 N-M/2 에서 나온다.예 를 들 어 현재 Hash 분 구 표 는 모두 100 개의 분 구 를 가지 고 있 습 니 다.우 리 는 이 분 구 를 추가 하고 싶 습 니 다.그것 은 101 개의 분 구 입 니 다.즉,위의 공식 중의 N 은 101 이 고 101 보다 작은 2 의 정수 멱 은 128 이 며 M 은 128 입 니 다.그래서 이 101 분 구 의 데이터 출처 는 101-128/2=37 분 구 입 니 다.다른 측면 에서 볼 때,우리 가 101 구역 을 늘 릴 때,37 구역 을 잠 가 야 한다.왜냐하면 우 리 는 이 구역 의 일부 데 이 터 를 새로운 101 구역 에 삽입 해 야 하기 때문이다.다음 에 우 리 는 하나의 실례 를 통 해 위의 설명 을 검증 하고 실제 작업 에서 주의해 야 할 사항 이 있 는 지 살 펴 보 겠 습 니 다.Commodity 표 는 우리 시스템 의 큰 표 입 니 다.몇 년 전에 이 표를 위해 Hash 분 구 표를 만 들 었 을 때 그 당시 의 DBA 는 분 구 수 를 선택 할 때 100 개의 분 구 를 지 정 했 습 니 다.

select TABLE_NAME,PARTITION_POSITION,PARTITION_NAME,NUM_ROWS from user_tab_partitions where table_name=\'COMMODITY\' order by PARTITION_POSITION;
TABLE_NAME PARTITION_POSITION PARTITION_NAME NUM_ROWS
-------------- ------------------ ---------------------- ----------
COMMODITY 1 COT_IND01_P1 4405650
COMMODITY 2 COT_IND01_P2 5046650
COMMODITY 3 COT_IND01_P3 5107550
……
COMMODITY 36 COT_IND01_P36 5718800
COMMODITY 37 COT_IND01_P37 9905200
COMMODITY 38 COT_IND01_P38 10118400
COMMODITY 39 COT_IND01_P39 10404950
COMMODITY 40 COT_IND01_P40 9730850
COMMODITY 41 COT_IND01_P41 9457300
COMMODITY 42 COT_IND01_P42 9717950
COMMODITY 43 COT_IND01_P43 9643900
COMMODITY 44 COT_IND01_P44 11138000
COMMODITY 45 COT_IND01_P45 9381300
COMMODITY 46 COT_IND01_P46 10101150
COMMODITY 47 COT_IND01_P47 8809950
COMMODITY 48 COT_IND01_P48 10611050
COMMODITY 49 COT_IND01_P49 10010600
COMMODITY 50 COT_IND01_P50 8252600
COMMODITY 51 COT_IND01_P51 9709900
COMMODITY 52 COT_IND01_P52 8983200
COMMODITY 53 COT_IND01_P53 9012750
COMMODITY 54 COT_IND01_P54 9310650
COMMODITY 55 COT_IND01_P55 8966450
COMMODITY 56 COT_IND01_P56 8832650
COMMODITY 57 COT_IND01_P57 9470600
COMMODITY 58 COT_IND01_P58 8932450
COMMODITY 59 COT_IND01_P59 9994850
COMMODITY 60 COT_IND01_P60 9617450
COMMODITY 61 COT_IND01_P61 10278850
COMMODITY 62 COT_IND01_P62 9277600
COMMODITY 63 COT_IND01_P63 8136300
COMMODITY 64 COT_IND01_P64 10064600
COMMODITY 65 COT_IND01_P65 3710900
……
COMMODITY 99 COT_IND01_P99 5273800
COMMODITY 100 COT_IND01_P100 5293350
100 rows selected.

각 분 구 의 데이터 분 포 를 조회 하면 분 구 37~64 의 28 개 분 구 의 기록 수 는 다른 분 구 의 두 배 에 달 하 는 것 을 볼 수 있다.100 은 2 의 정수 멱 이 아니 기 때문에 Oracle 의 hash 함 수 는 데이터 가 평균 분포 라 는 것 을 보장 할 수 없습니다.우 리 는 이 표 에 새로운 파 티 션 COT 를 추가 합 니 다.IND01_P101:

alter table nts_commodity_ts add partition COT_IND01_P101;
Table altered.
Elapsed: 00:06:58.52

통계 정 보 를 수집 한 후 새로운 파 티 션 기록 수 를 조회 합 니 다.

select TABLE_NAME,PARTITION_POSITION,PARTITION_NAME,NUM_ROWS from user_tab_partitions where table_name=\'COMMODITY\' and partition_name in (\'COT_IOT_IND01_P37\',\'COT_IOT_IND01_P101\');

TABLE_NAME PARTITION_POSITION PARTITION_NAME NUM_ROWS
------------------ ------------------ --------------------- ----------
COMMODITY 37 COT__IND01_P37 4905200
COMMODITY 101 COT_IND01_P101 5107550

이때 우 리 는 분 구 37 의 데이터 가 분 구 37 과 101 에 가 까 워 진 것 을 볼 수 있다.파 티 션 을 추가 하 는 과정 에서 session 잠 금 상황 을 감시 합 니 다.우 리 는 그 동안 두 개의 대상 이 exclusive 모드 로 잠 겨 있 는 것 을 발 견 했 습 니 다.

SQL> select * from v$lock where sid=1239 and type=\'TM\' and LMODE=6 order by sid,lmode;
ADDR                KADDR          SID TY ID1    ID2 LMODE REQUEST CTIME BLOCK
---------------- ---------------- ---------- -- ---------- ---------- ---------- ---------- ---------- ----------
FFFFFFFF7D764828 FFFFFFFF7D764888 1239 TM 4004126 0  6 0 72 2
FFFFFFFF7D764828 FFFFFFFF7D764888 1239 TM 4004063 0  6 0 72 2
          ？
select OBJECT_NAME,SUBOBJECT_NAME,OBJECT_ID from user_objects where object_id in (4004126,4004063)
OBJECT_NAME SUBOBJECT_NAME OBJECT_ID 
--------------------- ------------------------------ ---------- 
COMMODITY COT_IND01_P100 4004126
COMMODITY COT_IND01_P37 4004063

    ，  37 100     。  37        ，          。        100   ，          ？
     ：        101          100   ，                      100 DDL  ， coalesce  ，    101             37     ，101          100  ，        。   ，     ，    ，              ？    ，  hash       drop partition   ，    coalesce          ， coalesce             。
     hash                    ？
        ，    37       100      ，                   DML   ，  DML             (mode 3)。                  。
Hash               ， range          ，               IO   ，          。          ，  Hash       Hash         ，                 hash  。       ，             6 58 ，    10046        ，  6       CPU   ，     Hash     。
[code]
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
 call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse      328      0.17       0.27          0          0        148           0
Execute   1520    360.14     396.30     456820   11416202      26357    11565252
Fetch     1767      5.42      21.18      21421      26540          0        2862
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total     3615    365.73     417.76     478241   11442742      26505    11568114

이 테스트 사례 중 파 티 션 COTIND01_P37 에는 총 1 천만 개 에 가 까 운 데이터 가 있 는데 7 분 가까이 걸 리 고 파 티 션 데이터 가 1 억 개 에 이른다 고 가정 하면 1 시간 이상 걸 려 야 한다.만약 에 우리 의 Hash 분 구 수가 Oracle 의 건의 에 따라 2 의 정수 멱 이 라면 우 리 는 분 구 를 늘 릴 때 원래 의 분 구 를 배로 늘 려 야 한다.예 를 들 어 원래 의 분 구 는 128 개 이 고 확장 할 때 128 개의 분 구 를 늘 려 야 한다.분 구 를 추가 할 때마다 필요 한 시간 을 곱 하면 Hash 표 에 분 구 를 늘 리 는 것 은 매우 무 서운 작업 이 될 것 이다.한 마디 로 하면 Hash 분 구 는 장점 이 있 지만 심각 한 결함 도 있다.예 를 들 어 여기 서 묘사 한 분 구 확장 문제 이다.따라서 프로젝트 설계 초기 에 우 리 는 구역 수 를 신중하게 선택해 야 한다.그러나 데이터 양 이 증가 함 에 따라 우 리 는 구역 표 에 구역 을 나 누 는 조작 을 피하 기 어렵다.이런 조작 은 자원 을 소모 하 는 조작 이 고 조작 과정 에서 자물쇠 문제 로 인해 기 존의 일부 구역 에 대한 조작 에 영향 을 줄 수 있다.그러나 우리 가 앞 에 존재 하 는 문제점 을 두려워 하여 구역 확장 을 하지 않 으 면 뒤로 갈수 록 데이터 양 이 증가 함 에 따라 구역 을 늘 리 는 작업 은 실시 하기 어렵다.