인덱스 유지관리 작업과 SQL Server 쿼리 성능

인덱스 유지관리 작업과 SQL Server 쿼리 성능

 

• Version : SQL Server 2005, 2008, 2008R2, 2012, 2014

 

SQL Server 데이터베이스 엔진에서는 기본 데이터에 삽입, 업데이트 또는 삭제 작업을 수행할 때마다 인덱스를 자동으로 유지 관리한다. 이러한 수정이 거듭되면 시간이 흐름에 따라 인덱스의 정보가 조각화되어 데이터베이스 내에 흩어지게 될 수 있다. 조각화는 키 값을 기준으로 하는 인덱스의 논리적 페이지 순서가 데이터 파일 내의 물리적 순서와 일치하지 않을 때 나타난다. 심하게 조각화된 인덱스는 쿼리 성능을 저하시키고 응용 프로그램의 응답이 느릴 수 있다.

 

인덱스 조각화가 심할 경우에는 Reorganization 또는 Rebuild에 대한 고민을 하게 되는데 이러한 작업 이후 쿼리 성능이 어떻게 되는지 살펴보자.

 

• 인덱스 다시 구성 및 다시 작성 :

https://msdn.microsoft.com/ko-kr/library/ms189858.aspx

 

 

테스트를 하기 위해 샘플 테이블 및 인덱스를 생성 한다.(데이터 생성에 많은 시간이 걸린다. 필자는 30분동안 데이터를 생성하였다.)

-- Create sample table and indexes CREATE TABLE testtable ([col1] [int] NOT NULL primary key clustered, [col2] [int] NULL, [col3] [int] NULL, [col4] [varchar](50) NULL);   CREATE INDEX idx_testtable_col3 on testtable (col3 asc);   -- Load sample data into table DECLARE @val INT SELECT @val=1 WHILE @val < 5000000 BEGIN INSERT INTO testtable (col1, col2, col3, col4) VALUES (@val,round(rand()*100000,0),round(rand()*100000,0),'TEST' + CAST(@val AS VARCHAR)) SELECT @val=@val+1 END GO

 

 

샘플 데이터가 완성되었으면 SQL Server 인덱스 성능을 테스트 한다. 생성된 인덱스의 조각화 정보 확인 및 실제 조회 시 사용된 CPU, Reads, Write, Duration을 체크 한다. 이때 쿼리는 단일 값 및 범위, 인덱스 스캔을 할 수 있는 3가지 유형을 테스트하였다.

 

인덱스 조각화 정보 확인

SELECT object_name(object_id) as tablename, index_id,index_type_desc, avg_fragmentation_in_percent,      page_count,page_count*8/1024 as [size(mb)] FROM [sys].[dm_db_index_physical_stats](DB_ID(), NULL, NULL, NULL, DEFAULT) WHERE object_name(object_id) = 'testtable' and index_id=2

 

 

 

각 쿼리의 성능을 비교 한다. 아래 성능표는 각 쿼리를 실행 했을 때 프로파일러를 통해 확인한 값이다.

SELECT col2 FROM testtable WHERE col3=55627; SELECT col2 FROM testtable WHERE col3 BETWEEN 72000 AND 75000; SELECT count(col3) FROM testtable;

	Test Scenario	CPU	Read	Write	Duration
1회	Single Value	0	189	0	0
	By Range	329	22583	0	716
	Index scan	1548	13662	0	423
2회	Single Value	0	189	0	1
	By Range	483	22583	0	687
	Index scan	1174	13662	0	331
3회	Single Value	0	189	0	0
	By Range	452	22583	0	668
	Index scan	1283	13662	0	356

 

 

인덱스 Reorganization 및 Rebuild를 통해서 성능을 확인하기 위해 인덱스 유지관리 작업을 한다. 이때 동일한 환경에서 작업 후 성능을 평가하기 위해 데이터베이스 백업 작업을 진행 한다. 이후 각 테스트마다 백업 된 데이터베이스를 복원하여 유지관리 작업을 진행하여 성능을 평가 한다.

 

인덱스 Rebuild

-- REBUILD test -- After this completes run query against [dm_db_index_physical_stats] to -- get fragmentation stats ALTER INDEX [idx_testtable_col3] ON [dbo].[testtable] REBUILD PARTITION = ALL WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON);

	Test Scenario	CPU	Read	Write	Duration
1회	Single Value	0	193	0	0
	By Range	593	22587	0	699
	Index scan	1171	8774	0	324
2회	Single Value	0	189	0	0
	By Range	517	22583	0	703
	Index scan	1219	8772	0	357
3회	Single Value	0	189	0	0
	By Range	671	22583	0	824
	Index scan	1094	8772	0	315

 

인덱스 Reorganization

-- REORG test -- After this completes run query against [dm_db_index_physical_stats] to -- get fragmentation stats ALTER INDEX [idx_testtable_col3] ON [dbo].[testtable] REORGANIZE WITH ( LOB_COMPACTION = ON );

	Test Scenario	CPU	Read	Write	Duration
1회	Single Value	0	484	0	21
	By Range	640	22587	0	814
	Index scan	1156	8936	0	299
2회	Single Value	0	189	0	1
	By Range	453	22583	0	747
	Index scan	1485	8934	0	402
3회	Single Value	0	189	0	0
	By Range	531	22583	0	746
	Index scan	1110	8934	0	333

 

 

이 테스트 결과를 보면 인덱스 유지관리를 하였을 때 전체적으로 쿼리 성능이 크게 변하지 않는 것을 확인 할 수 있었다. 하지만 인덱스 스캔의 Read의 경우 매우 많은 성능 이점을 확인 할 수 있었다. 인덱스 재구성 후 인덱스 페이지가 감소되어 인덱스 스캔의 성능이 빨라진 것으로 유추할 수 있다.

 

이번 테스트 이후 인덱스 리빌드 작업은 과연 모든 운영 시스템에 필요한지 다시 한번 생각하게된다. 인덱스 스캔이 많다면 고려해볼만 하지만 대부분의 쿼리는 단일 값 또는 범위 검색을 하기 때문이다. 비즈니스를 확인하고 선택은 스스로 판단할 수 있도록 한다.

 

[참고자료]

http://www.mssqltips.com/sqlservertip/3533/sql-server-query-performance-after-index-maintenance-for-reorganization-vs-rebuild-operations/

 

2015-03-05 / 강성욱 / http://sqlmvp.kr

 

 

인덱스 리빌드, 인덱스 재구성, sqlserver, mssql, index rebuild, index reorg, sql 인덱스, DB 튜닝, sql튜닝