ALTER TABLE 에 있어서의 SHRINK 와 MOVE (10g)

[출처] http://blog.naver.com/hirokorea?Redirect=Log&logNo=20028027191

 

ALTER ～ SHRINK SPACE

---

결론으로부터 말하면 SHRINK에 세그먼트(segment)의 축소(HWM 의 저하)의 효과를 기대한다면 행 이행·행 연쇄를 해소하고 나서 실행하는 편이 좋을 것이다.(행 연쇄는 지울 수 없기 때문 ASSM 에서는 어디에 연쇄할까는 운나름 ???)

 

SHRINK 조작은 Oracle 10g부터의 기능이며 ONLINE에서 실행할 수 있는 등 매우 유용하지만 약점도 존재한다. Oracle 10g R1에서 SHRINK에 대한 효과가 상당히 향상되었다고 생각된다. 최신 릴리스에선 이러한 약점도 반드시 해결되어 있을 것이라 생각한다.(Oracle 10g R2 는 미검증)

 

SHRINK 와 MOVE 의 특징

---

■ ALTER TABLE MOVE 의 동작 이미지는 다이렉트·패스·인서트로 복제, 오리지날을 TRUNCATE TABLE(그리고 메뉴얼 조작으로 색인을 REBUILD).

■ ALTER TABLE SHRINK 는 단편화의 해소를 도모하는 SQL를 사용해 레코드 단위에 위탁하는 DELETE, INSERT 커서 처리라고 하는 느낌이다.

ALTER TABLE SHRINK 와 ALTER TABLE MOVE 의 대표적인 특징

비교 내용	SHRINK	MOVE
ONLINE(다른 처리와 병행) 실행할 수 있을까	네	아니오
	·SHRINK 하행 단위에 처리를 완료시키고 있으므로 RX 락으로 OK. ·MOVE 는 색인 구성표 이외에서는 X 락이 필요하게 된다 참고: 표 락의 종류와 상호 관계
행 이행은 해소할까	아니오(입력 데이터에 의존)	네
	·SHRINK는 단편화의 해소하는 프로세스에 있어서 연쇄하고 있는 상태가 일부(운이 좋다면 전부) 해소될 가능성이 있다.⇒ SHRINK 시의 행 이행의 해소에 대해 ·MOVE 는 완전한 재구축이므로 행 이행은 모두 해소된다.
하이워타마크는 내려갈까	데이터 분포에 의존	네
	SHRINK는 대량의 행 이행 및 행 연쇄가 방치된 상태에서는 별로 효과를 기대할 수 없다.⇒ SHRINK 시의 세그먼트(segment) 축소에 대해 ·MOVE 는 HWM를 저하시킬 수 있다.
작업에 큰 빈영역(데이터 세그먼트)이 필요한가	아니오	실데이터분 이상의 빈영역이 필요
	·SHRINK는 처리의 방식이 행 단위로 이동이 행해지기 때문에 불필요. ·MOVE 는 복제와 삭제라고 하는 구조가 되므로 레코드 건수에 비례한 빈영역이 필요.
작업에는 큰 일시표 영역(템프세그먼트)이 필요한가	아니오	네(색인 상태에 의존)
	·SHRINK 는 처리의 방식이 행 단위로 이동이 행해지기 위해 불필요. ·MOVE 는 복제와 삭제라고 하는 구조가 되므로 인덱스의 컬럼수와 레코드 건수에 비례한 일시표 영역이 사용된다.
대규모 색인의 메인터넌스가 발생할까	아니오	네
	·SHRINK 하행 단위에 인덱스도 처리되므로 발생하지 않는다. ·MOVE는 ROWID가 모두 변경된다. 테이블에 색인이 존재하는 경우에는 모든 색인의 재구축 (REBUILD)이 필요하다(수동으로 실시할 필요가 있다).

 

 

SHRINK시의 행 이행의 해소에 대해

---

SHRINK 조작에 의해서 행 이행이 해소하는 일이 있다. 이것은 단편화를 해소할 경우에 행해지는 레코드 데이터의 이동에 의하는 것으로 항상 연쇄한 상태가 해소하는 것은 아니다. 단편화의 해소(행 데이터의 이동)는 물리 ROWID 에 의해서 핸들링 되고 있는 것처럼 보인다. (연쇄행 단편 ROWID 는 사용하지 않는다?? )

 

세그먼트(segment)의 축소, HWM의 저하에 대해

---

적당한 스크립트를 만들어 동작을 지켜본 결과 (덤프 한 것은 아니고 ROWID를 작업 전후로 트레이스 했다)있던 SHRINK는 물리 ROWID 를 단편화를 해소하기 위한 중요한 값으로 이용하고 있는 것 같다.(행 단편에 있어서의 연쇄행 단편 ROWID는 사용하지 않는것 처럼 보인다. 데이터·딕셔너리에 정보가 존재하지 않을것이다.)
어느 테이블이 연속한 데이터 블록으로 구성되어 있다고 가정했을 경우, 그 테이블에 단편화가 발생하고 있는 경우의 SHRINK 의 동작은 ROWID가 큰 값으로부터 차례로 전방의 빈영역에 채우고 있는 것은 아닐까 생각 할수도 있다.
중요한 점은 세그먼트(segment)의 선두 근처에서 행 이행(또는 행 연쇄)이 발생하고, 실제의 격납 위치가 세그먼트(segment)의 마지막(HWM)에 가까운 위치에 연쇄하고 있을 때, 그 행 이행이 그대로 남아 버리는 일(※)이 있다고 하는 점이다.
이것은 다른 모든 레코드가 단편화를 해소해 연속한 빈영역이 발생해도 HWM의 행 이행에 의한 데이터 블록의 점유에 의해서 HWM 의 위치를 거의 낮추지 못하는 것을 나타낸다.⇒ 테이블·풀 스캔시에 엑세스 블럭이 많아짐. 

 

(※) Oracle 10g R1 에 대한 실험의 행동으로부터의 예상

 

세그먼트(segment)의 축소 효과가 낮을 때의 SHRINK 의 동작 이미지

 

또 SHRINK 하행 단위로 처리를 행하기 때문에 MOVE 동작과는 달리 자동 세그먼트(segment) 영역 관리에 의한 PCTUSED 에 해당하는 한계치의 영향을 받고 있을 가능성도 생각할 수 있다.(미검증).

이러한 점으로부터 격납 효율과 하이워타마크를 내리는 것에 있어서 MOVE 에 상당한 우위성이 있다고 생각된다.

 

 

SHRINK 실행시의 주의점

---

사용하기 위한 전제

• 테이블 영역이 로컬 관리 테이블 영역, 자동 세그먼트(segment) 영역 관리인 것
• LONG 열을 포함하지 않는 것
• 클러스터화 테이블이 아닌 것
• 압축테이블이 아닌 것

세그먼트(segment)의 축소를 할 수 없는 케이스

• 펑션 색인, 비트 맵 결합 색인을 사용하고 있는 장소
• ON COMMIT 마테리아라이즈드·뷰의 마스터 테이블의 경우

그외

• ROWID 가 변경되기 위해 ROWID 마테리아라이즈드·뷰는 재구축 하지 않으면 정합성이 맞지 않게 된다

 

관련사항

---

 

테이블에 있어서의 SHRINK 의 사용예
행 이행·행 연쇄를 검출한다
SHRINK 가 실행 가능한 schema 테이블(파티션표를 포함한다), 인덱스 구성표(오버플로우를 포함한다), 인덱스LOB 세그먼트(segment), 마테리아라이즈드·뷰(·로그 포함한다)