[SQL 2005 GUIDE] tempdb를 사용하는 작업 및 tempdb sizing

작년에 MS에서 SQL Server MVP들을 미국에서 열리는 PASS에 보내 주었었는데, PASS 전체 참석자들을 대상으로 하는 공식 세미나가 끝난 다음에 MS에서 MVP들만을 대상으로 SQL Server 2005에 대한 몇 가지 세미나를 해 주었었습니다. 그 세션 중 하나가 tempdb에 대한 내용이었는데 tempdb라는 한 가지 주제를 가지고 한 시간 내내 설명하는 것을 보고, tempdb가 SQL Server 2005에서 보다 중요한 역할을 하게 되었다는 것을 느낄 수 있었습니다.

tempdb 데이터베이스의 크기와 물리적인 배치가 시스템의 성능에 영향을 미친다는 것은 이미 앞에서 말씀드린바 있습니다. tempdb의 기본적인 내용에 대해서는 앞에 올린 글을 참조하시기 바랍니다.

SQL Server 2005에서는 tempdb를 SQL Server 2000에 비해 더 많이 사용합니다. 어떤 기능을 사용하는가에 따라서 SQL Server 2000에서보다 tempdb를 훨씬 더 많이 사용하게 될 수도 있습니다.
그래서 SQL Server 2005에서는 DBA가 시스템을 구성하고 관리할 때 tempdb 관리 작업의 우선 순위가 높아졌다고 할 수 있습니다. tempdb의 작업 부하를 분산하여 성능 향상을 꾀하는 것도 필요하지만 그보다 더 중요한 것은 작업이 원활하게 수행될 수 있도록 tempdb를 적절한 크기로 구성하는 것이 중요합니다. 

Tempdb sizing을 위해서는 어떤 작업을 실행할 때 tempdb에 공간을 필요로 하는지 알아야겠지요 !!!

그렇다면 SQL Server 2005에서 어떤 작업이 tempdb를 사용하는지 알아보겠습니다. 일부 내용은 혹시 제가 잘못 한글로 번역하는 오류를 범할까 염려되어 영어 원문을 그대로 기술하였습니다. 저도 SQL Server 2005를 공부해 가는 사람이라 제가 모르는 부분이 더 있을지 모릅니다. 혹시 아래 기능들 외에 tempdb를 사용하는 작업에 대하여, 또는 tempdb sizing에 대하여 아시는 분은 답글 부탁드립니다.


1. DBCC CHECKDB

2. 내부 개체 
   - work file (해시 조인, SORT_IN_TEMPDB 옵션 사용 시) - CTE
   - work table (커서, 스풀)

3. LOB 변수

4. 서비스 브로커

5. 임시 개체

    1) 전역 임시 테이블, 로컬 임시 테이블

    2) table 변수

    3) 임시 저장 프로시저 

    4) 임시 커서

6. 버전 저장

    1) MARS

    2) 온라인 인덱스 재구성
         - 인덱스 크기의 2 ~ 3배가 필요함 (정렬, 임시 인덱스, 롤백)

    3) Row versioning 
         - [Size of Version Store] = 2 *
            [Version store data generated per minute] *
            [Longest running time (minutes) of your transaction] *
            number of concurrent transactions/users
         - 성능 모니터의 SQL Server 2005:Transactions 성능 개체에 Version Store에
            관련되는 다음과 같은 성능 카운터들이 추가되었습니다.
                - Version Store Size (KB)
                - Version Store unit count
                - Version Store unit creation
                - Version Store unit truncation

    4) 트리거

7. XML

이상입니다.

Version Store에 대해서는 좀 더 심도있는 공부가 필요할 것 같습니다. 성능 모니터의 한글 설명으로는 이해가 잘 되질 않네요. ^ ^
모르는 것이 많아져서 답답할 때가 많지만, 이렇게 끝없이 공부할 게 있고 잡힐 듯 하면서 잡히지 않는 데이터베이스, 참 매력적인 분야인 것 같습니다.