http://bong8nim.net/archives/434
SQL 서버가 제공하는 Northwind 같은 데이터베이스나 실제 사용중인 데이터베이스에는 이곳에 대한 데이터가 저장되어있는 실제파일들이 존재할것이다.
Northwind의 경우 Northwind.mdf 와 Northwind.ldf 파일이 그러할것이다. SQL서버를 설치한 폴더로 가서 하위폴더인 DATA폴더를 확인해보자
SQL 서버의 시스템 아키텍쳐는 크게 논리적인 데이터베이스와 물리적인 데이터베이스로 나뉘는데, Northwind 데이터베이스의 테이블, 뷰, 저장프로시저 등은 논리적인 데이터베이스(Logical Database)상에 만들어진다.
이러한 논리적인 데이터베이스들은 실제로 복수의 데이터베이스 디바이스 파일(Device File)로 저장되는데,이를 물리적인 데이터베이스(Physical Database)라고 한다.
논리적인 데이터베이스가 저장되는 물리적인 디바이스 파일에는 다음과 같은 3가지 종류가 있다.
-
주 데이터 파일(Primary Data Files, MDF)
데이터베이스를 생성하면 기본적으로 필요한 디바이스 파일이다. 주 데이터파일이 없다면 데이터베이스를 제대로 생성할수 없다. 주 데이터 파일에 기본적인 데이터구조 및 데이터들이 저장되기 때문이다.
NorthWind 데이터베이스의 경우에는 Northwind.mdf 파일이다. MDF 파일은 이러한 주 데이터 파일의 기본 확장명이다. -
보조 데이터 파일(Secondary Data Files, NDF)
여러개의 디바이스 파일을 운영할때 보조 데이터 파일로 사용한다. 이러한 보조 데이터 파일을 사용하는 이유는 데이터 I/O를 병렬적으로 수행하여 I/O 병목현상을 줄이고, 수행속도를 높이기 위해서이다.
이러한 보조 데이터 파일은 반드시 필요한것은 아니므로 꼭 생성할 필요는 없다. 보조 데이터 파일의 기본확장자는 NDF이다. Northwind데이터베이스에는 이러한 보조 데이터파일을 이용하지 않는다. -
로그 파일(Log Files, LDF)
로그파일은 데이터베이스를 복구하는데 필요한 모든 로그 정보를 저장하고있다. 로그파일은 각 데이터베이스마다 반드시 있어야 하며, 하나 이상의 파일을 그룹으로 묶을수도 있다. Northwind데이터베이스에서는 Northwind.ldf 파일이 이런역할을 하고있으며, 기본 확장자는 LDF이다.
주 데이터파일의 위치는 Master 데이터베이스의 Sysdatabases 테이블에서 검색할수있다.
SQL 데이터베이스 구조의 장점은 이러한 데이터파일이나 로그파일이 시스템과 분리 되어 있기 때문에 해당 데이터베이스파일을 복사하여 다시 첨부(Attach) 하는 것만으로 해당 데이터베이스의 데이터와 그당시까지의 로그를 다시 불러들일수 있다는 점이다. 이러한 작업에 사용되는 프로시저가 sp_attach 나 sp_attach_single_file_db 프로시저이다.
데이터 파일 구조
페이지(Page)
페이지는 SQL서버에서 데이터를 저장하고 처리하는데 사용되는 가장 기본적인 입출력 단위이다. 이러한 페이지의 크기는 각 페이지당 8kb, 즉 8192바이트의 저장공간을 사용하고 이중에서 96바이트의 공간을 페이지 헤더로 이용하여 페이지의 종류, 페이지의 여유공간 정보, 페이지가 저장하는 데이터 오브젝트 ID 등을 저장한다. 그리고 나머지 8096바이트를 실제 데이터 저장공간으로 사용한다. 각 메가 바이트당 페이지는 128개 정도가 되므로, 해당 데이터베이스의 파일사이즈를 가지고 얼마만큼의 페이지가 존재하는지 알수 있다. 예를 들어서 10MB의 크기를 가지고 있는 데이터베이스인 경우에는 1280개의 페이지가 존재할 것이다. 이러한 페이지들은 저장하는 데이터와 그 내무 구성에 따라서 다음과 같은 8가지 형태의 종류가 있다.
페이지 종류 | 내부 구성 |
---|---|
Data | text, ntext, image 형태를 제외한 모든 데이터 레코드 저장 |
Index | 인덱스 데이터를 저장 |
Text / Image | text, ntext, image 형태의 데이터를 저장 |
GAM(Global Allocation Map) | 할당된 익스텐드(Extent) 정보들을 저장 |
PageFree Space | 페이지의 여유 공간 정보를 저장 |
IAM(Index Allocation Map) | 테이블과 인덱스에 의해 사용되는 익스텐드 정보들을 저장 |
Bulk Changed Map | 마지막 백업로그(Backup Log)문 이후의 벌크 작업에 의해 수정된 익스텐드 정보들을 저장 |
DCM(Differential Changed Map) | 마지막 백업 데이터베이스(Backup Database)문 이후에 변경된 익스텐드 정보들을 저장 |
로그 데이터는 페이지를 이용하지 않는다. 로그데이터는 데이터 페이지 영역과는 완전히 분리돼서 트랜잭션 로그 파일에 연속된 긴 레코드 형태로 저장된다.
익스텐트(Extent)
익스텐트는 SQL서버에서 테이블과 인덱스를 저장하고 관리하는데 사용되는 공간의 기본 할당단위이다.
이러한 익스텐트들은 연속된 8개의 페이지들로 이루어져 있다.
각 페이지가 8KB 이므로 8개의 페이지들은 총 64KB의 크기를 가지고 있다. 그리고 메가 바이트당 16개의 익스텐트들을 유지할수 있다. 페이지의 예에서 처럼 10MB의 크기를 가지고 있는 데이터베이스인 경우에는 160개의 익스텐드들과 1280개의 페이지를 가진다. 각 익스텐드가 8개의 연속된 페이지를 가지고 있기때문에 앞에서 설명한 페이지보다는 좀더 상위의 단위이다.
익스텐드들은 페이지가 어떻게 구성되어 있는가에 따라서 혼합 익스텐트(Mixed Extent)와 단일 익스텐트(Uniform Extent)로 나뉜다.
혼합 익스텐트는 8개의 페이지에 각각 다른 오브젝트의 데이터를 저장할수 있고 단일익스텐트는 8개의 페이지에 모두 같은 오브젝트의 데이터를 저장할수 있다. 혼합 익스텐트와 단일 익스텐트로 종류를 나눈 이유는 공간을 좀더 효율적으로 이용하기 위해서이다.
예를들어 해당 오브젝트의 데이터가 8개의 페이지를 모두다 사용할 필요가 없는데도 단일 익스텐트로 구성되면, 나머지 빈공간은 계속해서 비어있게 되므로 비효율적이다.
-
혼합 익스텐트(Mixed Extent)
혼합 익스텐트는 SQL 서버에서 8개의 페이지보다 적은 공간을 사용하는 테이블이나 인덱스등의 오브젝트를 저장하기 위해서 사용된다.
당연히 해당 익스텐트에 저장될수 있는 오브젝트는 페이지의 개수만큼인 8개이다.
위 그림을 보면 페이지 1,2,3 은 Table1오브젝트의 데이터를 Page4는 Index1의 데이터를 저장하고 있다. 이 익스텐트에는 모두 6개의 오브젝트의 데이터를 저장하고 있는것이다. -
단일 익스텐트(Uniform Extent)
모든 페이지들이 동일한 오브젝트의 데이터를 저장하기 위해서 사용된다.
위 그림처럼 모든 페이지들은 Table1 오브젝트의 데이터를 저장하고 있다. 해당 익스텐트가 모두 채워지면 새로운 익스텐트에 데이터를 저장한다.데이터를 저장할때 단일 혹은 혼합 익스텐트를 결정짓는 것은 데이터의 크기이다. 만일 테이블이나 인덱스를 새로이 생성할 경우 해당데이터가 해당 익스텐트를 충분히 커버할만큼 크다면 단일 익스텐트에 데이터가 저장된다.
그렇지 않는 일반적인 경우, 새로 테이블이나 인덱스는 혼합 익스텐트에 데이터를 저장하다가 하나의 오브젝트가 하나의 익스텐트를 커버할만한 크기로 증가하면, 해당 오브젝트를 단일 익스텐트로 변경한다. 물론 단일 익스텐트쪽이 혼합 익스텐트에 비해 효율적이기때문에 이러한 작업이 수행된다.
실제로 데이터파일의 경우에는 여러개의 파일들을 묶어서 사용할수 있는데, 이럴경우 여러개의 파일들은 논리적으로 하나의 디바이스처럼 동작한다.
이러한 파일들은 해당 시스템에서 물리적으로 분리된 여러 대의 하드디스크에 있게 될때 가장 최적의 성능을 발휘할수있다. 이렇게 물리적으로 분리된 디스크에 각각 파일이 하나씩 있다면 SQL서버에서는 데이터를 저장할때 번갈아가며 이러한 파일들을 사용하게 되기때문에 I/O 입출력이 병렬로 가능하게 된다.
데이터를 익스텐트에 할당할때도 SQL서버는 내부적으로 IAM(Index Allocation Map)과 PFS(PAge Free Space)페이지에서 정보를 추출하여 여유공간의 비율에 따라 어떤 익스텐트를 할당할것인지를 결정한다. 새로운 익스텐트가 필요하면 새로운 익스텐트를 생성해 데이터를 저장한다.
로그 파일구조
데이터 파일의 경우 여러개의 파일들을 묶어서 하나의 디바이스로 이용할 경우 해당 디바이스에 대한 I/O의 병렬성이 확보되어 성능의 향상을 기대할수 있다.
하지만 로그파일의 경우에는 여러개의 파일들로 디바이스를 확보하더라도 이러한 성능의 향상은 기대할수없다. 로그파일은 내부적으로 원형 큐형식으로 데이터관리를 하는데, 이말은 여러개의 파일들로 디바이스를 설정하더라도 SQL서버는 내부적으로 큐의 순서에 맞추어서 데이터를 순차적으로 저장하기 때문이다.
큐의 경우에 데이터는 최근 저장된 순서로 다시 인출될수 있으므로 이는 트랜잭션의 개념에 가장 잘 부합되는 자료구조가 될수있지만, I/O의 병렬성은 확보할수 없다.
'Database > MS-SQL' 카테고리의 다른 글
데이터베이스의 기본 구조 (0) | 2013.10.25 |
---|---|
SQL Server DBA 가이드 (0) | 2013.10.25 |
관리 - 메모리 사용량 관리 방법 (0) | 2013.10.24 |
64비트 버전의 SQL Server 버퍼 풀 메모리 페이지 수를 줄이는 방법 (0) | 2013.10.24 |
메모리 병목 현상 해결 (버퍼 풀 / 논버퍼풀 메모리) (0) | 2013.10.24 |