Oracle 압축 흑 과학기술 (2) - 압축 데이터 의 수정

원본 링크:https://www.red-gate.com/simple-talk/sql/oracle/compression-in-oracle-part-2-read-only-data/
이 시리즈 의 첫 번 째 글 에서 우 리 는 직접 경로 로 불 러 오기, CTAS (create table as selection) 와 'alter table move' 를 볼 때 만 기본 표 압축 체 제 를 사용 할 수 있 습 니 다.또한 표 가 압축 을 사용 할 때 Oracle 은 기본적으로 이 표 의 데이터 블록 인 pctfree 를 0 으로 설정 합 니 다. 이것 은 우리 의 기본 압축 이 데이터 만 읽 는 압축 전략 이 되 어야 한 다 는 것 을 암시 합 니 다.
블록 에 대응 하 는 dump 파일 을 볼 때 Oracle 은 '압축' 데이터 가 아 닙 니 다. 그 가 하 는 일 은 블록 마다 중복 값 목록 (즉 사전 표) 을 만 든 다음 에 일부 표 지 를 통 해 중복 값 을 대체 하여 블록 등급 의 무 게 를 제거 하 는 것 입 니 다.또한, Oracle 은 블록 에 있 는 필드 순 서 를 다시 배열 하여 하나의 표지 로 여러 필드 를 대체 할 수 있 는 기 회 를 증가 시 킬 수 있다.이것 은 Oracle 이 블록 을 읽 을 때 '압축 해제' 데이터 가 필요 하지 않다 는 것 을 알려 준다. 그 가 해 야 할 일 은 포인터 로 데 이 터 를 재 구성 하 는 것 일 뿐이다. 물론 이것 은 CPU 밀집 형 작업 이다.
이 글 에서 우 리 는 읽 기 전용 원칙 을 따 르 지 않 으 면 무슨 일이 일어 날 지 토론 할 것 이다.그리고 세 번 째 글 에서 별도의 권한 이 필요 한 OLTP 압축 을 검토 하 겠 습 니 다.앞에서 말 한 바 와 같이 아래 의 모든 예 는 Oracle 11.2.0.3 의 실례 에서 나온다.
삭제
다음 글 에서 저 는 조합 표 지 를 포함 하 는 데이터 블록 의 한 줄 dump 를 기억 할 수 있 습 니 다. 그 다음 에 Oracle 은 이 표지 가 대표 하 는 의 미 를 위로 찾 았 습 니 다. 최종 적 으로 이 조합 표 지 는 두 개의 단독 표지 와 두 개의 추가 필드 값 으로 조합 되 었 음 을 확인 할 수 있 습 니 다. 다음은 우리 가 테스트 한 줄 입 니 다.

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

이것 은 우리 가 인용 한 단일 표지 의 값 을 찾 을 때 발견 한 49 번 표지 입 니 다.

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

bindmp 의 앞의 5 개의 바이트 에서 이 표 지 는 이 블록 에서 8 번 (0008) 을 사 용 했 고 4 개의 열 로 구성 되 었 음 을 알려 주 었 습 니 다. 그리고 54 (0x 36) 와 64 (0x 40) 번 표 지 를 살 펴 보 겠 습 니 다.

tab 0, row 54, @0x1f74
tl: 7 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 41 41 41 41
bindmp: 00 0a cc 41 41 41 41

tab 0, row 64, @0x1f7b
tl: 13 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [10] 41 41 41 41 41 41 41 41 41 41
bindmp: 00 05 d2 41 41 41 41 41 41 41 41 41 41

위의 덤 프 데 이 터 를 통 해 원본 줄 을 삭제 하려 면 추가 작업 을 해 야 한 다 는 것 을 알 수 있 습 니 다. \두 가지 일이 반드시 발생 할 것 이다. 1. 이 줄 은 삭 제 된 것 으로 표시 해 야 한다 (정상 적 인 방식 으로). 2. 49 번 표지 의 '사용 계수' 도 1 을 줄 여야 한다.
한 줄 을 삭제 한 후에 여기에 작은 세 션 이 있 습 니 다. 먼저 줄 항목 자체 입 니 다.

tab 1, row 0, @0x1b28
tl: 2 fb: --HDFL-- lb: 0x2
bindmp: 3c 02

다음은 49 번 표지 의 바 이 너 리 덤 프 입 니 다. 주의 하 세 요. 두 번 째 바이트:

bindmp: 00 07 04 36 40 ca c1 02 d2 20 20 20 20 20 20 20 20 20 31

그래서 우 리 는 간단 한 줄 을 삭제 하 더 라 도 블록 데 이 터 를 유지 하 는 작업 이 증가 할 수 있다 는 것 을 깨 달 을 수 있다.그러나 이 표 지 는 블록의 다른 7 줄 에서 도 사용 되 기 때문에 내 가 이 줄 들 을 삭제 하면 무슨 일이 일어 날 까요?정 답 은 삭 제 된 동시 다발 세 션 의 수량 에 달 려 있다.만약 에 제 가 하나의 프로 세 스 를 사용 하여 모든 8 줄 을 삭제 하면 8 줄 을 삭제 할 때 Oracle 은 표 지 를 삭 제 했 습 니 다. 이때 63 번 표지 와 64 번 표 지 는 의존 항목 이 부족 하 다 는 것 을 표시 하기 위해 업데이트 해 야 합 니 다.만약 에 제 가 여러 세 션 을 사용 하여 줄 을 삭제 하고 매번 삭제 한 후에 제출 하지 않 으 면 한 장면 을 볼 수 있 습 니 다. 표 지 는 0 으로 표시 되 지만 사라 지지 않 습 니 다.(내 가 아직 관찰 하지 못 한 후속 블록 청소 작업 이 이 상태의 표 지 를 지 울 수도 있다.)
나 는 동시 테스트 를 언급 하기 전에 제출 이나 스크롤 백 에 관 한 어떤 내용 도 언급 하지 않 았 다.표지 의 변 화 는 delete 이 동작 에서 발생 했 고 그 후에 제출 되 지 않 았 습 니 다.내 가 제출 하거나 스크롤 백 하면 무슨 일이 일어 날 까요?제출 시 통상 적 인 제출 제거 작업 이 발생 할 수 있 으 며, 제출 시 SCN 으로 업 데 이 트 된 ITL 슬롯 (다시 말 해 새 일이 나 특별한 일이 발생 하지 않 았 다 는 것) 이 발생 할 수 있 습 니 다.스크롤 백 할 때 데 이 터 는 undo 정보 에 따라 복 구 됩 니 다. 삭 제 된 모든 표지 도 다시 만 들 고 관련 표지 의 사용 수가 증가 합 니 다.
그러나 중요 한 것 은 스크롤 백 후에 도 압축 은 유지 된다 는 것 이다.이 길드 들 은 스크롤 백 후 블록의 빈 공간 을 기록 하지만 원본 블록 과 스크롤 백 후의 블록 사이 에는 약간의 차이 가 있 습 니 다.이러한 조작 은 빈 공간 파편 을 통합 하 는 작업 이 필요 하기 때문이다.그래서 만약 당신 이 다시 덤 프 를 꺼 내 면, 블록의 내용 이 이미 이동 한 것 을 볼 수 있 습 니 다.나의 예 에서 (49 번 표 지 를 인용 한 8 줄 기록 을 삭제 하고 스크롤 백) 나 는 다음 과 같은 차 이 를 보 았 다.

tab 0, row 49, @0x1ed0 -- original position of token 0
tab 0, row 49, @0x134a -- position of token 0 after rollback

tab 1, row 0, @0x1b28 -- original position of row 0
tab 1, row 0, @0x1322 -- position of row 0 after rollback

압축 과 남 은 공간
데 이 터 를 삭제 하고 스크롤 백 하면 줄 이 이동 합 니 다. 이 현상 은 빈 공간 에 대한 재 미 있 는 점 을 가 져 왔 습 니 다. 시계 가 기본 압축 일 때 기본 pctfree 는 0 입 니 다.빈 공간 은 없 지만 스크롤 백 후 데 이 터 를 이동 할 공간 이 있 습 니까?
나 는 Oracle 이 확실히 약간의 공간 을 유지 할 것 이라는 것 을 발견 했다. (약 몇 십 byte 이지 만, 나의 테스트 용례 중의 두 줄 에 대해 서도 충분 하 다.)이 작은 공간 은 Oracle 이 삭 제 된 줄 을 복원 할 수 있 도록 합 니 다.일부 경우, 이 부분의 남 은 공간 은 업데이트 작업 을 할 수 있 습 니 다.
제 가 초기 데이터 세트 를 살짝 조정 하 겠 습 니 다. 줄 마다 다음 과 같 습 니 다.

 (1000001, 'AAAA', 'AAAAAAAAAA','         1')

첫 번 째 열 은 하나의 서열 이 고, 두 번 째 열 은 AAAA 에서 EEEE 까지 순환 하 며, 세 번 째 열 은 AAAAAAAA 에서 JJJJJJJJJJJJ 까지 순환 하 며, 마지막 열 은 10 글자 로 1 - 50 순환 (자리 차지 문자 용 "\ ”표시그리고 나 서 나 는 800 줄 의 데 이 터 를 만 들 었 다.제 가 데 이 터 를 만 드 는 방법 에 문제 가 있 기 때문에 첫 번 째 데이터 블록 에는 11 줄 의 데이터 가 있 고 두 번 째 세 번 째 열 은 모두 A 입 니 다. 그래서 저 는 다음 과 같은 sql 을 실행 한 다음 에 dump 표 의 첫 번 째 블록 으로 무슨 일이 발생 했 는 지 관찰 해 야 합 니 다.

update t1
set
        vc_rep = 'BBBB'
where
        vc_rep = 'AAAA'
and     vc_cycle = 'AAAAAAAAAA'
and     rownum <= 4
;

이것 은 이 블록 안에 이 두 줄 의 기록 을 갱신 할 충분 한 공간 이 있 고 항상 같은 블록 안에 있 지만 나의 줄 은 여전히 이전 이 발생 했다 는 것 을 증명 했다.이 데이터 블록 중 한 줄 이 작업 전후의 dump 데이터 비교 가 있 습 니 다.

tab 1, row 0, @0x1bb8 -- before
tl: 11 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: [10] 20 20 20 20 20 20 20 20 20 31
col 3: [ 5] c4 02 01 01 02
bindmp: 2c 00 02 03 1b cd c4 02 01 01 02

tab 1, row 0, @0x4f3 -- after
tl: 37 fb: --H-FL-- lb: 0x2 cc: 4
col 0: [ 4] 42 42 42 42
col 1: [10] 41 41 41 41 41 41 41 41 41 41
col 2: [10] 20 20 20 20 20 20 20 20 20 31
col 3: [ 5] c4 02 01 01 02
bindmp: 2c 02 04 00 cc 42 42 42 42 d2 41 41 41 41 41 41 41 41 41 41 d2 20 20 20 20 20 20 20 20 20 31 cd c4 02 01 01 02

update 작업 후, Oracle 은 이 줄 을 완전한 4 열 데이터 로 확장 했다.사전 표 에 업 데 이 트 된 이 줄 기록 의 앞 두 필드 를 바 꿀 수 있 는 두 개의 표지 가 있 습 니 다.그러나 오 라 클 은 이 로 고 를 찾 아 사용 하려 하지 않 았 다.그래서 이렇게 보면 update 압축 된 데이터 가 전체적인 혼란 을 초래 할 것 같 습 니 다. 한 줄 의 압축 기록 은 커 다란 확장 과 보 잘 것 없 는 공간 에서 이 데 이 터 를 담 을 수 없어 서 결국은 줄 의 이전 을 초래 할 수 있 습 니 다.
현재 로 서 는 확 장 된 줄 과 이전 줄 이 나타 나 면 데이터 가 혼 란 스 러 울 것 으로 보인다.그러나 우리 가 스크롤 백 작업 을 수행 할 때 오 라 클 은 이러한 혼란 을 깨끗이 정리 하고 나머지 줄 도 원래 압축 되 고 이전 되 지 않 은 위치 에 있 을 것 이다.
그래서 update 작업 이 얼마나 나 쁜 영향 을 미 칠 수 있 습 니까?이 질문 에 대답 하기 전에 제 가 한 update 작업 을 먼저 볼 수 있 습 니 다.나 는 표지 가 대체 할 수 있 는 값 을 수 정 했 고 이 값 은 많은 줄 에 존재 한다.그런데 만약 에 제 가 로고 가 대체 할 수 없 는 값 을 수정 했다 면 요?Oracle 은 이 update 때문에 이 줄 의 기록 을 확장 할 수 있 습 니까?답 은 부정 적 이다.만약 우리 가 ID (시퀀스 형식, 중복 되 지 않 음, 표지 화 할 수 없 음) 의 값 을 수정 했다 면.다음은 수정 전 회의 dump 데이터 비교 입 니 다.

tab 1, row 0, @0x1bb8 -- before
tl: 11 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: [10] 20 20 20 20 20 20 20 20 20 31
col 3: [ 5] c4 02 01 01 02
bindmp: 2c 00 02 03 1b cd c4 02 01 01 02

tab 1, row 0, @0x1bb8 -- after
tl: 10 fb: --H-FL-- lb: 0x2 cc: 4
col 0: [ 4] 41 41 41 41
col 1: [10] 41 41 41 41 41 41 41 41 41 41
col 2: [10] 20 20 20 20 20 20 20 20 20 31
col 3: [ 4] c3 64 64 64
bindmp: 2c 02 02 03 1b cc c3 64 64 64

update 작업 후의 데 이 터 는 여전히 원래 의 위치 에 있 으 며 이전 이 발생 하지 않 았 습 니 다.그러나 이 줄 은 앞의 세 줄 을 대표 할 수 있 는 표지 와 실제 값 으로 구성 되 어 있 음 을 주의 하 십시오.줄 확장 은 일어나 지 않 았 습 니 다.
내 가 처음 테스트 한 그 줄 의 데 이 터 는 사실상 모든 줄 이 하나의 표지 로 대 체 될 수 있다.만약 내 가 여러 개의 표지 로 구 성 된 줄 의 특정한 표지 화 된 필드 를 업데이트 한다 면 어떻게 되 겠 습 니까?Oracle 은 전체 줄 을 확장 하지 않 습 니 다. update 작업 에 영향 을 미 치 는 열 데이터 만 확장 할 수 있 습 니 다.이것 은 조작 전후의 dump 데이터 입 니 다:

tab 1, row 18, @0x1ac2
tl: 13 fb: --H-FL-- lb: 0x0 cc: 4
col 0: [ 4] 44 44 44 44
col 1: [10] 58 58 58 58 58 58 58 58 58 58
col 2: [10] 20 20 20 20 20 20 20 20 33 34
col 3: [ 5] c4 02 01 01 14
bindmp: 2c 00 04 03 32 37 45 cd c4 02 01 01 14

tab 1, row 18, @0x1ab8
tl: 23 fb: --H-FL-- lb: 0x2 cc: 4
col 0: [ 4] 44 44 44 44
col 1: [10] 59 59 59 59 59 59 59 59 59 59
col 2: [10] 20 20 20 20 20 20 20 20 33 34
col 3: [ 5] c4 02 01 01 14
bindmp: 2c 02 04 00 32 d2 59 59 59 59 59 59 59 59 59 59 45 cd c4 02 01 01 14

이 테스트 의 시작 부분 에서 dump 데 이 터 는 이 줄 이 세 개의 독립 된 표지 (0x 32, 0x 37 과 0x 45) 와 하나의 실제 수치 로 구성 되 어 있 음 을 나타 낸다.나 는 첫 번 째 열의 값 인 'XXXXX XXXX' 를 'YYYYYYYYYYYYYYYY' 로 업데이트 했다. 보시 다시 피 마지막 dump 데 이 터 는 표지 0x 32 와 0x 45 를 포함 하고 있 지만 표지 0x 37 은 실제 값 으로 교체 되 었 다.줄 의 길이 가 10 바이트 (13b 에서 23b 로 증가) 증가 한 것 을 볼 수 있 습 니 다. 이것 은 Oracle 이 아주 작은 빈 공간 으로 이동 해 야 한 다 는 것 을 의미 하기 때문에 최종 줄 의 주소 가 바 뀌 었 습 니 다.
따라서 기본 표 압축 에 있 는 데 이 터 를 업데이트 하려 고 할 때 Oracle 은 로 고 를 실제 값 으로 확장 할 수 있 지만 가능 한 한 최소 화 된 확장 을 할 것 입 니 다.데이터 가 압축 된 후 pctfree 가 0 인 상황 에서 도 데이터 블록 에는 작은 공간 이 있 습 니 다.따라서 대량의 확장 과 이동 을 초래 하지 않 은 상태 에서 아주 적은 양의 update 작업 을 할 수 있 지만 이러한 부작용 은 거의 예 지 될 수 없다.
압축 된 데 이 터 를 소량 으로 유지 해 야 한다 면 실제 데이터 에 대해 충분 한 테스트 를 통 해 가장 적합 한 pctfree 의 값 을 찾 아 줄 이 동 률 을 받 아들 일 수 있 는 범위 로 제어 해 야 합 니 다.
총결산

압축 표 에서 데 이 터 를 삭제 할 때 추가 CPU 를 소모 합 니 다. Oracle 은 사전 표를 유지 하여 관련 표지 의 인용 수량 을 줄 이 고 인용 수가 0 이면 이 표 지 를 삭제 해 야 하기 때 문 입 니 다.그 밖 에 표지 의 사용량 이 0 이지 만 이 표지 가 삭제 되 지 않 았 을 때 약간의 공간 낭 비 를 제외 하고 너무 많은 삭제 작업 은 큰 해 를 끼 치지 않 습 니 다.

압축 표 의 데 이 터 를 업데이트 할 때, Oracle 은 pctfree 를 0 으로 설 치 했 기 때문에, 당신 이 인위적으로 pctfree 를 높이 지 않 는 한, 당신 에 게 줄 을 늘 리 는 데 사용 할 수 있 는 공간 이 조금 밖 에 없다 는 것 을 항상 자신 에 게 일 깨 워 야 합 니 다.

표지 화 된 필드 값 을 업데이트 하면 Oracle 은 이 줄 의 복사 본 을 생 성 한 다음 에 복사 본 에 있 는 표 지 를 완전한 값 으로 수정 합 니 다. 수정 후 사전 표 에 해당 하 는 표지 가 있어 도 Oracle 은 이 값 을 압축 하지 않 습 니 다.그러나 단점 은 update 압축 데이터 가 대량의 줄 데이터 의 확장 과 심각 한 줄 이동 을 초래 할 수 있다 는 것 이다.

기본 적 인 지도 방침: 데 이 터 를 잘 알 지 않 으 면 데이터 만 읽 어야 기본 압축 을 사용 할 수 있 습 니 다.다음 글 은 OLTP 압축 을 살 펴 보고 오 라 클 이 이런 상황 에서 어떤 최 적 화 를 했 는 지 살 펴 보 겠 습 니 다.