Oracle 압축 흑 과학기술 (一) -- 기초 표 압축

원본 링크:https://www.red-gate.com/simple-talk/sql/oracle/compression-oracle-basic-table-compression/
Oracle 압축 에 관 한 이 일련의 글 에서 우 리 는 전통 적 인 Oracle 데이터베이스 시스템 의 각종 압축 방식 을 연구 할 것 이다. 이것 은 이 시리즈 글 의 디 렉 터 리 구 조 는 대략 1. 기초 표 압축 2. OLTP 표 압축 3. 색인 압축 이다.다만, 엑 사 데이터 의 하 이브 리드 컬럼 너 압축 (HCC) 은 논의 하지 않 는 다.
이 세 가지 압축 기술 중에서 색인 압축 과 기초 표 압축 은 제품 자체 의 핵심 구성 요소 이지 만 OLTP 압축 은 독립 적 인 'Advanced Compression Option (ACO)' license 권한 을 부여 해 야 한다.그리고 첫 번 째 글 에서 우 리 는 먼저 기초 표 로 데 이 터 를 압축 하여 만 들 고 데이터 업데이트 와 삭제 에 대한 문 제 를 두 번 째 글 에 남 겨 두 었 다. 마지막 으로 앞의 두 편의 배경 을 바탕 으로 OLTP 의 압축 을 연구 했다.색인 압축 은 4, 5 편 에 단독으로 남아 토론 한다.
본 논문 의 주요 목적 은 표 압축 과 관련 된 자주 묻 는 문 제 를 푸 는 것 이다.
기초 표 의 압축 은 언제 작용 합 니까?
사람들 은 "내 가 압축 데 이 터 를 어떻게 만 드 느 냐", "오 라 클 이 이 데이터 블록 들 을 어떻게 풀 느 냐", "압축 이 성능 에 어떤 영향 을 미 치 느 냐", "어떤 새로운 특성 을 사용 하기 전에 사람들 이 묻 는 질문" 왜 알려 지지 않 은 부작용 이 있 느 냐 "고 자주 묻는다.
첫 번 째 질문 에 대답 하 는 가장 쉬 운 방법 은 하나의 실제 예 를 통 해 하 는 것 이다.여기에 5 개의 SQL 이 있 습 니 다. 달 린 후에 우 리 는 먼저 표 의 통계 정 보 를 수집 한 다음 에 표 안에 몇 개의 데이터 블록 과 다른 상당 한 정보 가 있 는 지 확인 합 니 다.

--  1. Baseline CTAS
create table t1
as
select * from all_objects where rownum <= 50000;

--  2. CTAS with basic compression enabled
create table t1 compress basic
as
select * from all_objects where rownum <= 50000;

--  3. Normal insert into empty table defined as compressed
create table t1 compress basic
as
select * from all_objects where rownum = 0;

insert into t1 select * from all_objects where rownum <= 50000

--  4. Direct path insert into empty table defined as compressed
create table t1 compress basic
as
select * from all_objects where rownum = 0;

insert /*+ append */ into t1 select * from all_objects where rownum <= 50000

--  5. CTAS without compression, then change to compressed
create table t1
as
select * from all_objects where rownum <= 50000;

alter table t1 compress basic; 

alter table t1 move

SQL 이 실 행 될 때마다 다음 SQL 을 실행 하여 데이터 블록 에 대한 정 보 를 조회 합 니 다.

select  blocks, pct_free , compression, compress_for
from    user_tables
where   table_name = 'T1';

물론 다른 방법 도 있 습 니 다. 우 리 는 표 공간 을 압축 으로 정의 할 수 있 습 니 다. 그러면 안에 만 든 모든 시 계 는 기본적으로 압축 됩 니 다.우 리 는 또한 분 구 표 의 분 구 나 하위 분 구 를 압축 할 수 있다.우 리 는 심지어 파 티 션 표를 기본 압축 으로 정의 할 수 있다. 그러면 새로 추 가 된 파 티 션 은 모두 압축 된다.
나 는 아래 의 이 도표 로 상술 한 sql 코드 의 결 과 를 총 결 하 였 다.
test 5 는 두 가지 결과 가 있 습 니 다. 하 나 는 alter table move 이전 이 고 하 나 는 다음 입 니 다.
Test
BLOCKS
PCT_FREE
COMPRESSION
COMPRESS_FOR
1 (CTAS)
714
10
DISABLED
2 (CTAS compress)
189
0
ENABLED
BASIC
3 Insert
644
0
ENABLED
BASIC
4 Insert append
189
0
ENABLED
BASIC
5a Compress
714
10
ENABLED
BASIC
5b Move
189
0
ENABLED
BASIC
내 가 CTAS (create table as selection) 에 압축 옵션 을 추 가 했 을 때, Oracle 은 자동 으로 pctfree 를 0 으로 설정 합 니 다. 이 는 데이터 블록 의 수량 을 현저히 줄 이 고 189 개의 데이터 블록 만 사 용 했 습 니 다.pctfree 가 0 이라는 것 은 Oracle 이 이 표 가 read only 로 변 할 것 이 라 고 생각 한 다 는 것 을 의미한다.그러나 pctfree 는 물론 비 어 있 는 값 으로 설정 할 수 있 습 니 다. 이것 은 뒤의 장 에서 말 할 수 있 습 니 다.
세 번 째 네 번 째 테스트 에서 나 는 압축 을 사용 한 빈 표를 만 들 고 데 이 터 를 삽입 했다.보시 다시 피 direct path insert 를 사용 해 야 삽 입 된 데이터 가 압축 됩 니 다.일반적인 insert 작업 은 데 이 터 를 압축 하지 않 습 니 다.(insert 후 데이터 블록 644 개, CTAS 714 개 보다 적은 이 유 는 pctfree 가 10 에서 0 으로 바 뀌 었 기 때 문 입 니 다)
마지막 테스트 는 시 계 를 비 압축 에서 압축 으로 바 꾼 후에 기 존 데이터 에 영향 을 주지 않 는 다 는 것 을 알려 준다.압축 되 지 않 은 데 이 터 를 압축 하려 면 표 의 정 의 를 바 꾼 다음 move 표 가 필요 합 니 다.단, move 후 표 의 모든 색인 을 즉시 재 구축 해 야 합 니 다.
압축 원 리 는 우리 가 생각 하 는 것 과 같 지 않다.
Oracle 은 어떻게 압축 을 진행 합 니까?실제로 오 라 클 은 압축 하지 않 는 다.그 가 한 것 은 단지 등급 의 무게 제거 일 뿐이다.한 데이터 블록 에 다음 세 줄 의 데이터 가 있다 고 상상 해 보 세 요.

(‘XXXX’, ‘abcdef’, 254.32, ‘CLOSED’)
(‘XXXX’, ‘pqrstu’, 17.12,  ‘CLOSED’)
(‘AAAA’, ‘abcdef’, 99.99,  ‘CLOSED’)

오 라 클 은 'XXXX' 가 두 번, 'abcdef' 가 두 번, 'CLOSED' 가 세 번 나 왔 다 는 것 을 알 게 될 것 이다.이렇게 하면 이 블록 에서 중복 되 는 값 으로 사전 표를 만 들 수 있 습 니 다.압축 된 데 이 터 는 다음 과 같다.

T1 (‘XXXX’)
T2 (‘abcdef’)
T3 (‘CLOSED’)
(T1, T2, 254.32, T3)
(T1, ‘pqrstu’, 17.12, T3)
(‘AAAA’, T2, 99.99, T3)

사실 Oracle 은 이것 보다 더 똑똑 합 니 다. 블록 에 있 는 필드 순 서 를 다시 배열 하여 여러 필드 를 하나의 표지 로 대체 할 수 있 습 니 다.우리 의 예 에서 세 줄 의 데 이 터 는 모두 T1 과 T3 가 있다.Oracle 은 이 필드 를 다시 배열 하여 이 표지 들 이 가능 한 한 한 한 조각 에 있 도록 할 수 있 고 두 표지 의 조합 을 대체 할 수 있 습 니 다.최종 데 이 터 는 이렇게 됩 니 다.

T1 (‘XXXX’, T2)     --                 
T2 (‘CLOSED’)
T3 (‘abcdef’)
(T1, T3, 254.32)    --          
(T1, ‘pqrstu’, 17.12)   --   
(‘AAAA’, T2, T3, 99.99)

덤 프 데이터 블록의 데 이 터 를 통 해 압축 된 내부 실현 원 리 를 더욱 관찰 합 시다.이것 은 압축 표 의 데이터 블록 중의 첫 번 째 부분 입 니 다.

perm_9ir2[4]={ 2 0 1 3 }

이 표 는 4 개의 데이터 블록 이 있 지만 이 블록 에 대해 오 라 클 은 필드 의 순 서 를 다시 배열 했다. 필드 0 은 2 위, 필드 1 은 3 위, 필드 2 는 1 위, 필드 3 은 4 위 라 는 뜻 이다.

0x24:pti[0]     nrow=65    offs=0
0x28:pti[1]     nrow=400   offs=65

위 와 같이 이것 은 데이터 블록 에 있 는 두 개의 '표' 이 고 첫 번 째 는 표 지 를 저장 하 는 '표' (사실은 사전 표) 이 며 65 개의 표지 가 있 으 며 블록 의 줄 디 렉 터 리 에서 0 부터 시작 합 니 다.두 번 째 는 진정한 '표' 로 400 줄 이 있 고 블록의 줄 목록 에서 65 부터 시작 합 니 다.이것 은 이 블록의 줄 목록 에 모두 465 개의 항목 이 있다 는 것 을 의미한다.
만약 우리 가 두 번 째 '표' (진정한 데이터 표, 사전 표 가 아 닌) 부터 본다 면, 우 리 는 이것 이 일반적인 표 의 데이터 블록 dump 에서 나 온 줄 과 다 르 지 않다 는 것 을 알 게 될 것 이다.하지만 여기 에는 특별한 점 이 있 습 니 다.

tab 1, row 0, @0x1b28
tl: 5 fb: --H-FL-- lb: 0x0  cc: 4
col  0: [ 4]  41 41 41 41
col  1: [10]  41 41 41 41 41 41 41 41 41 41
col  2: [ 2]  c1 02
col  3: [10]  20 20 20 20 20 20 20 20 20 31
bindmp: 2c 00 01 04 31

열의 길이 (네모 난 괄호 에 있 는 데이터) 를 바탕 으로 줄 의 길 이 는 26 개의 바이트 (4 + 10 + 2 + 10) 이 고 4 개의 열 4 개의 바이트 와 flag byte (fb:), lock byte (lb:), column count (cc:) 를 더 하면 1 바이트 마다 - 하지만 전체 실제 길이 (tl:) 는 5 바이트 에 불과 합 니 다.그리고 마지막 줄 에서 도 이 다섯 바이트 의 실제 데 이 터 를 보 여 주 었 다.이 5 개의 바이트 는 각각 flag byte (0x2c = '– H - fl'), lock byte 와 저 장 된 열 수량 이다.그리고 나머지 2 바이트 는 우리 에 게 하나의 열 이 4 개의 연속 적 인 값 을 대표 하 는 표지 이 고 사전 표 에서 0x 31 호 표 지 를 찾 아야 한다 고 알려 주 었 다.다음은 사전 표 의 49 줄 (0x 31) 을 보 여 줍 니 다.

tab 0, row 49, @0x1ed0
tl: 19 fb: --H-FL-- lb: 0x0  cc: 4
col  0: [ 4]  41 41 41 41
col  1: [10]  41 41 41 41 41 41 41 41 41 41
col  2: [ 2]  c1 02
col  3: [10]  20 20 20 20 20 20 20 20 20 31
bindmp: 00 08 04 36 40 ca c1 02 d2 20 20 20 20 20 20 20 20 20 31

이 표 지 는 거의 줄 과 같 아 보 입 니 다. - 그런데 표지 의 총 길 이 는 19 바이트 입 니 다.그래서 덤 프 에서 나 온 데 이 터 를 보 겠 습 니 다.앞의 두 바이트 에서 이 표 지 는 이 블록 에 8 번 사용 되 었 다 고 알려 주 었 다.다음 바이트 에 서 는 표지 에 4 개의 열 이 있 음 을 알려 줍 니 다. 일부 인 코딩 을 통 해 나머지 두 바이트 에 서 는 이 표지 의 앞 두 필드 의 값 이 실제 0x 36 (54) 과 0x 40 (64) 번 표지 에 저장 되 어 있 음 을 알려 줍 니 다.뒤의 두 필드 는 바로 실제 데이터 이다.
따라서 우리 의 방법 을 통 해 줄 디 렉 터 리 에서 줄, 표지 까지 우 리 는 5 바이트 의 항목 을 완전한 26 바이트 의 줄 로 확장 할 수 있다.
우리 가 데이터 블록 dump 에서 나 온 데 이 터 를 추적 함으로써 여기 에는 아직도 배 울 만 한 많은 지식 이 있다.

Oracle 은 이러한 데 이 터 를 압축 하지 않 습 니 다. 그 는 단지 당신 의 수요 에 따라 사전 표 와 데이터 표 의 데이터 로 줄 을 재 구성 할 뿐 입 니 다.

줄 을 재 구성 할 때 추가 CPU 가 소 모 될 수 있 으 며, 전체 표 스 캔 을 할 때 특히 뚜렷 하 다.

부작용 이 있 습 니 다. 줄 을 재 구성 하기 위해 오 라 클 은 일정 시간 을 가 져 야 합 니 다.그래서 sql 에서 'consistent gets – examination' 의 기다 림 이 거의 발생 하지 않 는 다 는 것 을 알 수 있 습 니 다. 대부분의 시간 이 'cache buffers chains' 의 latch 에 쓰 였 기 때 문 입 니 다.

총결산
여전히 압축 에 관 한 부작용 이 많 습 니 다. 특히 표를 삭제 하고 업데이트 할 때 이것 은 OLTP 의 압축 을 실현 하도록 유도 하 는 것 입 니 다. - 미래의 글 은 다음 과 같 습 니 다.
우 리 는 이 첫 번 째 글 에서 다음 과 같은 것 을 발견 했다. 1. 기초 압축 은 direct path inserts 에서 만 유효 하고 일반적인 DML 은 데 이 터 를 압축 하지 않 는 다.2. Oracle 은 압축 표 의 PCTFREE 를 0 으로 기본 값 으로 설정 할 것 이다. 이것 은 Oracle 이 표를 작성 한 후에 데 이 터 를 수정 하지 않 을 것 이 라 고 생각 한 다 는 것 을 나타 낸다.3. 기초 표 압축 은 중 복 된 값 을 무 겁 게 하 는 것 일 뿐 이지 만 Oracle 은 데이터 가 차지 하 는 공간 을 최소 화 할 수 있 습 니 다.4. 이러한 디 폴 트 메커니즘 은 Oracle 이 데 이 터 를 압축 해제 할 필요 가 없다 는 것 을 의미한다. 블록 cache 를 buffer cache 에 넣 고 PGA 에서 줄 을 재 구성 하면 된다. 이 조작 데이터 CPU 밀집 형 이다.