태그 보관물: fragmentation

fragmentation

SQL Server에서 HEAP 조각화를 낮추는 방법은 무엇입니까? REBUILD 충분히 웃긴 후에 20 % 조각화가

최근에 하나의 힙 테이블에 70 % 이상의 조각화가 있음을 알았습니다. 그래서 나는하기로 결정

ALTER TABLE dbo.myTable REBUILD

충분히 웃긴 후에 20 % 조각화가 발생했습니다. 그 이후로 그 테이블에는 쓰지 않았습니다. 그래서 나는 한 번 더 재건을하기로 결정했습니다.

두 번째 시간이 지나면 테이블이 50 % 조각화를 더 많이합니다!
나는 이것이 어떻게 일어날 수 있는지 정말로 이해하지 못한다 …



답변

힙에서 조각화는 무엇을 의미합니까?

DMV avg_fragmentation_in_percent를 쿼리 하여 열에서 가져 오는 힙의 조각화 값은sys.dm_db_index_physical_stats

IN_ROW_DATA 할당 단위에서 인덱스의 논리적 조각화 또는 힙의 범위 조각화

또한 동일한 BOL은

힙의 리프 페이지에서 순서가 틀린 범위의 백분율입니다. 비 순차 범위는 힙에 대한 현재 페이지를 포함하는 범위가 이전 페이지를 포함하는 범위 다음에 실제로 다음 범위가 아닌 범위입니다.

따라서 힙에 할당 된 페이지에 여유 공간이 아니라 조각화를 생성하는 다양한 페이지 시퀀스가 ​​표시 됩니다.

이것은 작은 테스트로 증명할 수 있습니다. 힙 테이블을 작성하고 그 안에 레코드를 삽입 한 후 단편화를 점검하십시오.

create table dbo.HeapTest
(
Id INT not NULL Default (1),
Col1   char(5000) Not null Default ('Heaps Are Cool')
)

SET NOCOUNT ON

Insert into dbo.Heaptest default values
go 50

select index_type_desc,avg_fragmentation_in_percent,fragment_count,
avg_page_space_used_in_percent,record_count
from sys.dm_db_index_physical_stats(db_id(),object_id('dbo.HeapTest','U'),0,default,'detailed')

따라서 힙 테이블은 50 개의 레코드로 작성됩니다. 다음은 DMV sys.dm_db_index_physical 통계 쿼리 후의 조각화 모습입니다.

avg_fragmentation_in_percent열 값이 33 %임을 알 수 있습니다 . 이제 페이지가 어떻게 배열되는지 봅시다. 문서화되지 않은 쿼리 를 사용하여 수행 할 수 있습니다 %%lockres%%. 쿼리는

SELECT  %%lockres%%, * FROM dbo.HeapTest;

아래는 출력 결과입니다. 관련 부분 만 첨부합니다. dbo.HeapTest 테이블에 50 개의 행을 삽입 한 이후 쿼리에서 50 개의 행을 생성했습니다.

무엇 말하는 것은 첫 번째 페이지입니다 것은 ID를 가지고 197다음 페이지하는 ID가 242우리가 페이지 ID에 도달 할 때까지 다음 페이지 것은 연속 ID를 가지고 264우리가 페이지 ID를 가져 그 후 때문에 280. 이 그래서 점프 페이지의 ID 번호에 실제로 분열을 일으키는 것입니다.

이제 힙을 다시 빌드하지 말고 조각화 및 페이지 배열 방법을 보려면 명령을 다시 실행하십시오. 우리는 조각화를 얻는다

조각화는 이제 볼 수 있습니다 14%.

할당 된 페이지 번호를 보자

우리는이 하나 개의 점프는 모든 페이지가 연속적으로 페이지 ID를 할당 휴식. 단 하나의 점프 조각화가 상당히 감소했기 때문입니다.

힙을 다시 빌드하고 조각화를 확인하면 완전히 사라졌습니다. 그리고 페이지 ID 할당은

조각화가 증가한 이유

이제 조각화를 일으킨 원인에 대해 페이지가 힙에 할당 될 때 페이지가 할당되지 않은 이유는 페이지에 할당 된 PAGE ID의 급상승이 조각화 값을 증가시키는 원인으로 보아 왔기 때문입니다.

HEAP의 단편화라는 단어에는 의미가 없으며 순서가없는 여러 페이지에 대해 단편화를 어떻게 정의 할 것인지도 명심해야합니다.

조각화에 대해 정말로 걱정

힙 테이블이 조각화되고 쿼리 속도가 느려지는 시나리오에 실제로 직면하면 테이블을 재구성하는 것보다 클러스터 된 인덱스를 만드는 것이 좋습니다. 그 이유는 힙을 재 구축 할 때 모든 기본 비 클러스터형 색인도 재 구축되므로 많은 자원을 사용하고 트랜잭션 로그를 크게 사용하여 재 구축 프로세스에 시간이 훨씬 오래 걸리기 때문입니다. 프로덕션 시스템에서는 항상 이것을 피하려고 시도합니다. 바울은 이것을 신화 섹션에서 힙에 대해 다루었 다 .

추신 : 프로덕션 시스템에서는 문서화되지 않은 명령을 사용하지 마십시오. 이것은 단지 시연을위한 것입니다.


답변