소개

고객 요구 사항

10년 전만해도 데이터베이스 응용 프로그램을 개발하는 데 수개월 또는 수년이 걸리는 것이 일반적이었습니다. 데이터베이스를 구축할 때 데이터베이스 크기, 스키마, 사용자 수 등 모든 것이 미리 결정되었습니다. 지난 몇 년 사이 이 방식에 극적인 변화가 생겼습니다. 이제 데이터베이스 응용 프로그램을 몇 주 또는 몇 개월 안에 개발하고, 개발 과정에서 개선하기도 하고, 모든 문제가 완전히 파악되기 전에 실제 환경에 배포합니다.

업무용 응용 프로그램이 이처럼 신속하게 배포되기 때문에 저장소 엔진에 대한 요구 사항이 엄격해집니다. 저장소 엔진은 가용성이 높아야 하며 빠른 복구 시스템과 자동 관리 유틸리티를 갖춰야 합니다. 관리자는 응용 프로그램을 종료하지 않은 상태에서 신속하게 변경 작업을 수행하고자 합니다. 그리고 데이터베이스는 예상보다 훨씬 빠른 속도로 커지고 있습니다. 야간 백업 시간은 수 시간으로 단축됩니다.

Microsoft는 고객들로부터 많은 요구 사항을 수렴했습니다. 저장소 엔진 팀은 Microsoft® SQL Server® 7.0을 앞으로 20년 동안은 문제 없이 응용 프로그램 설계의 확고한 기반을 제공하는, 확장 가능하고 안정적이며 사용하기 쉬운 제품으로 만들기 위해 많은 노력을 기울였습니다.

저장소 엔진 출시 목표

이번에 출시되는 저장소 엔진에는 몇 가지 중요한 목표가 있습니다. 데이터베이스 기술을 사용하는 응용 프로그램이 널리 배포될 수 있도록 사용의 편의를 더욱 향상시키는 것이 핵심적인 전략입니다. 최종 사용자에게는 데이터베이스가 전혀 드러나지 않고 데이터베이스 관리자에게는 거의 드러나지 않는 것이 이상적이라고 할 수 있습니다.

사용의 편의

고객들은 업무 문제를 해결할 수 있는 솔루션을 찾고 있습니다. 대부분의 데이터베이스 솔루션은 비용과 복잡도가 다양합니다. SQL Server 6.0 및 6.5에서는 "사용의 편의"를 RDBMS 기능으로 정의했습니다. SQL Server 7.0은 이 개념을 한 단계 더 끌어올림으로써 업무용 응용 프로그램의 구축, 관리, 배포에 사용할 수 있는 가장 간편한 데이터베이스로서의 입지를 확고히 합니다.

사용의 편의를 위해 아래와 같은 많은 혁신적인 기능이 SQL Server 7.0 저장소 엔진에 제공됩니다.

• 표준 작업에 DBA가 필요하지 않습니다. 따라서 지점 자동화 그리고 데스크톱 및 이동 컴퓨터용 데이터베이스 응용 프로그램이 가능합니다.
• 서버 구성, DBCC, 인덱스 통계 관리 및 데이터베이스 백업의 복잡함을 드러내지 않습니다.
• 간소화된 능률적인 구성 옵션이 특정 환경 요구 사항에 자동으로 적응합니다.

확장성

고객들은 응용 프로그램에 대한 투자를 계속 이용해야 하고 데이터베이스는 사업이 성장함에 따라 더 많은 데이터, 트랜잭션, 사용자를 처리할 수 있도록 확장되어야 합니다. Microsoft는 Microsoft Windows® 95/98 운영 체제를 실행하는 휴대용 랩톱 컴퓨터에서 Microsoft Windows NT® Server Enterprise Edition을 실행하는 1TB(테라바이트) 대칭 다중 프로세서 클러스터까지 확장되는 단일 데이터베이스 엔진을 제공합니다. 이런 모든 시스템은 업무용 시스템에 필요한 보안과 안정성을 유지합니다.

저장소 엔진의 기능들은 아래를 포함한 확장성의 기본 토대입니다.

• 새 디스크 형식 및 저장소 하위 시스템이 극소형 데이터베이스에서 초대형 데이터베이스까지 확장될 수 있는 저장소를 제공합니다. .
• 다시 설계된 유틸리티가 1TB 크기의 데이터베이스를 효과적으로 지원합니다.
• 대용량 메모리가 지원되므로 잦은 디스크 액세스가 필요하지 않습니다.
• 동적 행 수준 잠금이 지원되므로 특히 OLTP 응용 프로그램에 대한 병행성이 향상됩니다.
• 유니코드 지원이 다국어 응용 프로그램을 가능하게 합니다.

안정성

• SQL Server 7.0은 복잡한 데이터 구조와 알고리즘을 간단한 구조로 바꿈으로써 병행성, 확장성, 안정성에 관련된 문제들을 해결했습니다. 새 구조는 확장성이 더 뛰어나고 병행성 문제가 없으며 매우 간단하기 때문에 안정성이 더 높습니다.
• SQL Server 7.0에서는 각 백업에 앞서 데이터베이스 일관성 검사기(DBCC)를 실행하지 않아도 됩니다. 위에서 설명한 간소함과 더불어 중요한 데이터 구조에 대한 실행 시간 검사를 통해 데이터베이스가 더욱 강력해집니다. 또한, 이제 각 백업에 앞서 DBCC를 실행하도록 권장하지도 않습니다. 이제 DBCC가 훨씬 빨라졌기 때문에 이를 실행할 때 결과를 훨씬 빨리 얻을 수 있습니다.

목표 및 기능 요약

저장소 엔진 설계 목표

이제 자동화된 지능형 저장소 엔진 작업에 힘입어 데이터베이스 응용 프로그램을 널리 배포할 수 있습니다. 정교하고 간소한 아키텍처가 성능, 안정성 및 확장성을 향상시킵니다.

저장소 엔진 기능

저장소 엔진 아키텍처 개요

개요

Microsoft는 대규모 기업 응용 프로그램을 다룰 때는 확장될 수 있고 데스크톱 응용 프로그램을 다룰 때는 축소될 수 있도록 SQL Server를 설계하고 있습니다. 이런 확장성은 앞으로 20년 동안은 문제 없이 응용 프로그램 설계를 다룰 수 있는 완전히 새로운 온디스크 구조 집합을 기반으로 합니다. 현재의 설계는 너무 제한적이기 때문에 설계 변경 작업을 진행하고 있습니다.

Sybase에서 물려받은 원래 코드는 지난 1983년 8MB UNIX 시스템에 맞게 설계된 것입니다. Microsoft의 프로그래머들이 이 코드를 최대한 개선하긴 했지만 SQL Server는 미래를 위해 더 우수한 기본 토대를 필요로 했습니다. 이러한 새 형식은 관리 효율성과 확장성을 향상시키며 하급 시스템에서 상급 시스템까지 서버가 확장될 수 있도록 함으로써 성능 및 관리 효율성을 향상시킵니다.

이점

새로운 온디스크 레이아웃에는 아래를 포함한 많은 이점이 있습니다.

• 향상된 확장성 및 Windows NT Server와의 통합 기능을 제공합니다
.
• 대량 I/O에서 더 우수한 성능을 보입니다.
• 안정적인 레코드 로케이터가 있으므로 더 많은 인덱스를 사용할 수 있습니다.
• 더 많은 인덱스를 사용할 수 있으므로 의사 결정 지원 쿼리가 더 빨리 처리됩니다.
• 데이터 구조가 간단하므로 더 우수한 품질이 제공됩니다.
• 확장성이 뛰어나기 때문에 이후의 릴리스를 개발하기 위한 프로세스가 더 간편해질 것이며 그에 따라 새 기능을 더 빠르게 구현할 수 있습니다.

저장소 엔진 하위 시스템

대부분의 관계형 데이터베이스 제품은 관계형 엔진과 저장소 엔진 구성 요소로 나뉩니다. 이 문서에서는 아래와 같은 다양한 하위 시스템이 있는 저장소 엔진에 대해 중점적으로 설명합니다.

• 파일에 데이터를 저장하고 페이지, 파일 및 확장 영역을 찾는 메커니즘
• 페이지의 레코드에 액세스할 수 있도록 하는 레코드 관리
• 레코드 식별자를 사용하여 신속하게 레코드를 찾는 데 사용되는 B-트리를 사용한 액세스 방법
• 페이지 또는 레코드 수준 잠금에 대한 실제 잠금 관리자와 잠금 프로토콜을 구현하는 데 사용되는 잠금 병행성 제어
• I/O 버퍼 관리
• 로깅 및 복구
• 백업 및 복원, 병행성 검사 및 대용량 데이터 로드에 사용되는 유틸리티

데이터베이스, 파일 및 파일 그룹

개요

SQL Server 7.0은 이전 버전보다 Windows NT Server와 훨씬 더 긴밀히 통합되었습니다. 이제 데이터베이스가 Windows NT Server 파일에 직접 저장됩니다. 이전의 UNIX 레거시 데이터베이스 장치 및 세그먼트는 각 데이터베이스를 자체의 파일 집합에 매핑하는 간단한 시스템으로 바뀌었습니다.

SQL Server는 하급 시스템과 상급 시스템 모두에 잘 맞게 확장됩니다. 중급 시스템에서 시작하여 상급 시스템으로 진출한 경쟁사들도 있습니다. 이들은 데스크톱 응용 프로그램의 요구 사항을 충족하기 위해 서로 다른 데이터 형식, 언어 및 프로그래밍 API를 사용하는 여러 가지 제품을 내놓았습니다. 많은 Microsoft Access 고객들이 SQL Server로 전환하고 있으며 Microsoft는 데스크톱 및 이동 컴퓨터용 응용 프로그램이 필요로 하는 기능에 주의를 기울여야 합니다.

파일

SQL Server 7.0은 운영 체제 파일 집합을 사용하여 데이터베이스를 생성하며 데이터베이스마다 별개의 파일이 사용됩니다. 더 이상 같은 파일에 여러 데이터베이스가 존재할 수 없습니다. 이렇게 간소화함으로써 몇 가지 중요한 이점을 얻을 수 있습니다. 이제 파일이 확장되거나 축소될 수 있으며 공간 관리가 크게 간소화되었습니다.

테이블, 저장 프로시저, 트리거, 뷰 같은 데이터베이스의 모든 데이터 및 개체는 이러한 운영 체제 파일에만 저장됩니다.

데이터베이스가 생성될 때, 그 데이터베이스를 구성하는 모든 파일은 디스크에 남아 있는, 이전에 삭제된 파일의 모든 기존 데이터를 덮어쓰기 위해 0으로 채워집니다. 이렇게 하면 파일을 생성하는 데 시간이 더 많이 걸리긴 하지만, 일반 데이터베이스 작업 중 파일에 데이터가 처음으로 기록될 때 Windows NT가 파일을 비우지 못한다는 이점이 있습니다. 파일이 이미 비워졌기 때문입니다. 이는 일상적인 작업의 성능을 향상시킵니다.

파일 그룹

데이터베이스는 하나 이상의 데이터 파일과 하나 이상의 로그 파일로 구성됩니다. 데이터 파일들을 사용자 정의 파일 그룹으로 그룹화할 수 있습니다. 그런 다음 테이블과 인덱스를 서로 다른 파일 그룹에 매핑하여 실제 디스크 상의 데이터 배치를 제어할 수 있습니다.

파일 그룹은 편리한 관리 단위이며 융통성을 크게 향상시킵니다. 테라바이트 데이터베이스에서는 백업 속도와 상관없이 전체 데이터베이스를 적절한 시간 안에 백업하는 것이 불가능합니다. SQL Server 7.0을 사용하면 밤마다 데이터베이스의 서로 다른 부분을 돌아가며 백업할 수 있습니다.

파일 그룹은 인덱스와 테이블을 어디에 배치할 것인지 잘 아는 고급 사용자에게 유용합니다. SQL Server 7.0은 파일 그룹 없이도 아주 효과적으로 동작할 수 있기 때문에 대부분의 시스템은 사용자 정의 파일 그룹을 지정할 필요가 없습니다. 이 경우 모든 파일이 기본 파일 그룹에 포함되며 SQL Server 7.0이 데이터를 데이터베이스 안에 효과적으로 할당할 수 있습니다.

로그 파일은 결코 파일 그룹의 일부가 아닙니다. 로그 공간은 데이터 공간과 별개로 관리됩니다.

파일 및 파일 그룹 사용

파일 및 파일 그룹을 사용하면 복수 디스크, 복수 디스크 컨트롤러 또는 RAID 시스템에 걸친 데이터베이스를 생성할 수 있으므로 데이터베이스 성능이 향상됩니다. 예를 들어, 컴퓨터에 디스크가 4개 있는 경우, 각 디스크에 파일을 1개씩 배치하는 방식으로 데이터 파일 3개와 로그 파일 1개로 구성된 데이터베이스를 만들 수 있습니다. 데이터에 액세스할 때 동시에 4개의 읽기/쓰기 헤드가 데이터에 병렬로 액세스할 수 있으므로 데이터베이스 작업 속도가 빨라집니다.

또한, 파일 및 파일 그룹을 사용하면 특정 파일 그룹에 테이블을 만들 수 있기 때문에 데이터를 더 적절히 배치할 수 있습니다. 그러면 특정 테이블에 대한 모든 I/O를 특정 디스크로 보낼 수 있기 때문에 성능이 향상됩니다. 예를 들어, 데이터베이스에서 액세스 빈도가 높은 테이블은 첫째 디스크에 있는 특정 파일 그룹의 특정 파일에 배치할 수 있고 액세스 빈도가 낮은 테이블은 둘째 디스크에 있는 특정 파일 그룹의 특정 파일에 배치할 수 있습니다.

다음은 파일 및 파일 그룹에 대한 일반적인 몇 가지 권장 사항입니다.

• 대부분의 데이터베이스는 단일 파일 및 단일 로그 파일을 사용할 때 잘 동작합니다.
• 복수 파일을 사용할 계획인 경우 기본 파일은 시스템 테이블 및 개체에만 사용하고 사용자 데이터 및 개체를 저장할 수 있는 보조 파일을 하나 이상 만듭니다.
• 성능을 최대화하려면 파일 또는 파일 그룹을 최대한 많은 로컬 실제 디스크에 분산 배치하고 공간을 차지하기 위해 심하게 경합하는 개체들은 서로 다른 파일 그룹에 배치합니다.
• 파일 그룹을 사용하여 특정 실제 디스크에 개체를 배치할 수 있도록 합니다.
• 같은 조인 쿼리에 사용되는 서로 다른 테이블은 서로 다른 파일 그룹에 배치합니다. 이렇게 하면 조인된 데이터에 대한 병렬 디스크 I/O 검색이 가능하기 때문에 성능이 향상됩니다.
• 액세스 빈도가 높은 테이블과 이런 테이블에 속하는 클러스터되지 않은 인덱스는 서로 다른 파일 그룹에 배치합니다. 이렇게 하면 파일들이 서로 다른 실제 디스크에 있는 경우 병렬 I/O가 가능하기 때문에 성능이 향상됩니다.
• 로그 파일(들)을 다른 파일 및 파일 그룹과 동일한 실제 디스크에 배치하지 마십시오.

공간 관리

파일 내의 공간 할당 및 공간 관리에 많은 개선이 이뤄졌으며 개체 관계에 대한 페이지를 추적하는 데이터 구조가 다시 설계되었습니다. 연결된 페이지 목록 대신 비트맵이 사용됩니다. 비트맵이 더 깔끔하고 간단할 뿐만 아니라 병렬 검색을 쉽게 해주기 때문입니다. 이제 각 파일의 자율성이 더 많이 보장되기 때문에 각 파일이 자체 데이터를 자체 내에 더 많이 가질 수 있습니다. 이는 데이터베이스 파일의 복사 또는 메일링에 유용합니다.

이제 SQL Server는 테이블 공간을 추적하기 위한 훨씬 더 효율적인 시스템을 갖추었습니다. 이 향상된 시스템은 아래와 같은 이점을 제공합니다.

• 파일 확장 및 축소
• 대량 I/O 지원 강화
• 테이블 안의 행 공간 관리
• 확장 영역 할당 비용 감소

이전 버전의 SQL Server에서는 대량의 데이터가 추가될 때 할당 때문에 블록킹이 발생할 수 있었습니다. 새로운 할당 알고리즘 및 데이터 구조는 간단하고 효율적이며 블록킹을 유발하지 않습니다. SQL Server 7.0은 페이지 상의 사용 가능한 공간을 추적합니다. 이제 클러스터된 인덱스가 없는 테이블에서 행이 삭제되면 행을 삽입할 때 그 공간을 다시 사용할 수 있습니다. 따라서 데이터가 더 조밀하게 배치되기 때문에 디스크 공간이 훨씬 더 효율적으로 사용되고 테이블 스캔 속도가 높아집니다.

SQL Server는 개체에 페이지를 신속하게 할당하고 행이 삭제되면서 해제된 공간을 다시 사용하기 때문에 매우 효율적입니다. 이러한 작업은 사용자에게 보이지 않는 데이터 구조를 사용하여 시스템 내부에서 처리됩니다. 그러나 이러한 프로세스와 구조를 SQL Server 메시지에서 참조할 때도 있습니다. 이 항목은 SQL Server의 메시지에 사용되는 용어 참조를 이해하는 데 필요한 지식을 사용자와 관리자에게 제공할 목적으로 마련된 공간 할당 알고리즘 및 데이터 구조에 대한 개요입니다.

SQL Server 7.0에서는 페이지 할당 및 재사용을 관리하는 데 사용되는 내부 데이터 구조에 몇 가지 중요한 변화가 생겼습니다. 이러한 데이터 구조는 최종 사용자에게는 보이지 않기 때문에 이런 변화들은 사용자에게 속도 향상 이외의 다른 영향을 미치지 않습니다.

파일 축소

랩톱 및 데스크톱 시스템의 제한된 디스크 공간을 고려하여, 데이터베이스 파일이 자동으로 축소되도록 설정하는 옵션이 제공됩니다. 서버는 주기적으로 각 데이터베이스의 공간 사용을 검사합니다. 데이터베이스에서 빈 공간이 많이 발견되면 데이터베이스에 있는 파일 크기가 줄어듭니다. 데이터 파일과 로그 파일 모두 줄어들 수 있습니다. 이 작업은 백그라운드에서 수행되며 데이터베이스 내의 사용자 작업에는 영향을 미치지 않습니다. 또한 SQL Server 엔터프라이즈 관리자 또는 DBCC를 사용하여 파일을 개별적으로 또는 그룹 단위로 축소할 수 있습니다.

파일 끝에 있는 페이지에서 파일의 앞 부분에 할당된 페이지로 행을 이동함으로써 파일 축소가 이뤄집니다. 인덱스에서는 파일 끝에서 파일의 시작 페이지로 노드가 옮겨집니다. 두 경우 모두, 파일 끝의 페이지가 해제된 후 파일 시스템으로 반환됩니다. 데이터베이스는 더 이상 사용 가능한 공간이 남아 있지 않아 데이터를 압축할 수 없는 지점까지만 줄어들 수 있습니다.

파일 확장

파일 자동 확장은 데이터베이스 관리의 필요성을 크게 감소시키며 로그 또는 데이터베이스에 사용할 수 있는 공간이 없을 때 발생하는 많은 문제를 제거합니다. 데이터베이스를 생성할 때 파일의 처음 크기를 반드시 제공해야 합니다. SQL Server는 데이터베이스 생성자가 제공하는 크기를 기반으로 데이터 파일을 만들며 이러한 파일이 채우는 데이터베이스에 데이터가 추가됩니다. 기본적으로, 사용할 수 있는 디스크 공간이 없어질 때까지 필요한 만큼 데이터 파일이 확장될 수 있습니다. 또는 데이터로 가득 찼을 때 미리 지정된 최대 크기까지만 자동으로 확장되도록 데이터 파일을 구성할 수도 있습니다. 이렇게 하면 디스크 드라이브의 공간이 소진되지 않습니다.

데이터베이스를 생성할 때, 데이터베이스에 포함될 것으로 예상되는 최대 데이터 양을 기준으로 데이터 파일을 최대한 크게 만들어야 합니다. 데이터 파일이 자동으로 확장될 수 있도록 하되 확장 한도를 지정해야 합니다. 데이터 파일의 처음 크기를 초과하여 파일이 자동으로 확장되기 시작하는 경우, 예상되는 데이터베이스의 최대 크기를 다시 산정한 다음 디스크 공간을 더 추가하고(필요한 경우) 데이터베이스에 파일 또는 파일 그룹을 더 만들거나 추가하여 적절한 대책을 세워야 합니다.

데이터베이스가 처음 크기를 초과하여 확장되지 못하도록 할 수 있습니다. 그러면 파일이 가득 찼을 때 데이터 파일을 더 추가하지 않는 한 데이터를 더 이상 추가할 수 없습니다. 파일 자동 확장을 허용하면 수많은 파일이 같은 디스크를 공유하는 경우 파일들이 조각날 수 있습니다. 따라서 파일 또는 파일 그룹을 최대한 많은 로컬 실제 디스크에 분산 배치하는 것이 좋습니다. 공간을 차지하기 위해 심하게 경합하는 개체들은 서로 다른 파일 그룹에 배치합니다.

실제 데이터베이스 아키텍처

SQL Server 7.0에서는 데이터의 실제 저장 방식이 크게 향상되었습니다. 이러한 변화는 일반 사용자에게는 대체로 드러나지 않지만 SQL Server 데이터베이스의 생성 및 관리에는 영향을 미칩니다.

페이지 및 확장 영역

SQL Server에서 데이터 저장소의 기본 단위는 페이지입니다. SQL Server 7.0의 페이지 크기는 이전보다 2K 커진 8K입니다. 각 페이지는 페이지 종류, 페이지 상의 사용 가능한 공간의 크기, 페이지를 소유한 개체의 ID 같은 시스템 정보를 저장하는 데 사용되는 96바이트 헤더로 시작됩니다.

SQL Server 7.0 데이터베이스의 데이터 파일에 사용되는 페이지 종류는 아래의 7가지입니다.

데이터 페이지에는 별도의 페이지에 저장되는 text, ntext 및 image 데이터를 제외한 데이터 행 안의 모든 데이터가 포함됩니다. 데이터 행은 헤더 바로 다음부터 시작하여 페이지에 순차적으로 배치됩니다. 행 오프셋 테이블은 페이지 끝에서 시작합니다. 행 오프셋 테이블은 페이지의 각 행에 대해 하나의 항목을 가지며 각 항목은 행의 첫째 바이트가 페이지의 시작에서 어느 정도 떨어져 있는지 기록합니다. 행 오프셋 테이블의 항목들은 페이지 상의 행 순서와 반대로 배치됩니다.

SQL Server 7.0에서 행은 단일 페이지 경계를 넘을 수 없으며 단일 행에 포함되는 데이터의 최대 크기는 text, ntext 및 image 데이터를 포함하지 않은 상태에서 8,060바이트입니다.

확장 영역은 테이블 및 인덱스에 공간을 할당할 때 사용되는 기본 단위입니다. 하나의 확장 영역은 연속된 8개의 페이지 또는 64K입니다. SQL Server 7.0은 효율적인 공간 할당을 위해 소량의 데이터가 포함된 테이블에 전체 확장 영역을 할당하지 않습니다. SQL Server 7.0은 두 가지 확장 영역 종류를 사용합니다. 균일 확장 영역은 단일 개체가 소유하고 확장 영역에 있는 8개의 모든 페이지는 이를 소유한 개체만 사용할 수 있습니다.

SQL Server 7.0에는 소규모 응용 프로그램에 잘 맞는 혼합 확장 영역 개념이 도입되었습니다. SQL Server 7.0 및 이전의 모든 릴리스에서, 한 번에 한 확장 영역씩 테이블에 공간이 추가됩니다. 이로 인해 페이지의 크기가 8K이기 때문에 아주 작은 테이블에서 대량의 오버헤드가 발생할 수 있습니다. 혼합 확장 영역을 사용하면 작은 테이블 또는 인덱스에 단일 페이지를 할당할 수 있습니다. 테이블 또는 인덱스에 9개 이상의 페이지가 할당되었을 때만 균일 확장 영역이 할당되기 시작합니다. 혼합 확장 영역은 최대 8개의 개체가 공유할 수 있습니다. 새 테이블 또는 인덱스에는 혼합 확장 영역의 페이지가 할당됩니다. 테이블 또는 인덱스가 8개의 페이지를 가진 지점까지 확장되면 균일 확장 영역으로 전환됩니다.

실제 데이터베이스 파일 및 파일 그룹

Microsoft SQL Server 7.0은 데이터베이스를 운영 체제 파일 집합에 매핑합니다. 데이터와 로그 정보는 절대로 같은 파일에 배치되지 않으며 데이터베이스마다 개별 파일을 사용합니다. 따라서 논리 장치를 관리할 필요가 없고 데이터베이스 파일을 배치하는 데 융통성이 생기며 새로운 백업 및 복원 기능을 사용할 수 있습니다.

SQL Server 7.0 데이터베이스는 아래와 같은 세 가지 파일 형식을 사용합니다.

• 기본 데이터 파일은 데이터베이스의 시작점이며 데이터베이스에 있는 나머지 파일을 가리킵니다. 데이터베이스마다 하나의 기본 데이터 파일을 가집니다. 기본 데이터 파일의 파일 확장명으로는 .mdf가 권장됩니다.
• 보조 데이터 파일은 기본 데이터 파일 외의 다른 모든 데이터 파일로 구성됩니다. 데이터베이스에 보조 데이터 파일이 아예 없을 수도 있고 여러 개 있을 수도 있습니다. 보조 데이터 파일의 파일 확장명으로는 .ndf가 권장됩니다.
• 로그 파일에는 데이터베이스 복구에 사용되는 모든 로그 정보가 포함됩니다. 데이터베이스마다 하나 이상의 로그 파일이 있어야 합니다. 로그 파일의 파일 확장명으로는 .ldf가 권장됩니다.

SQL Server 7.0의 파일은 원래 지정된 크기에서 자동으로 확장될 수 있습니다. 파일을 정의할 때 확장 단위를 지정할 수 있습니다. 파일이 가득 찰 때마다 이 확장 단위만큼 파일 크기가 커집니다. 파일 그룹에 여러 파일이 있는 경우 모든 파일이 가득 찰 때까지 자동으로 확장되지 않습니다. 모든 파일이 가득 차면 라운드 로빈 알고리즘을 사용하여 파일이 확장됩니다.

또한 각 파일에 최대 크기를 지정할 수도 있습니다. 최대 크기를 지정하지 않으면 디스크 상의 사용 가능한 공간을 모두 사용할 때까지 파일이 계속 확장될 수 있습니다. 사용자가 시스템 관리자에게 쉽게 접근할 수 없고 SQL Server가 응용 프로그램에 포함된 데이터베이스로 사용될 때 이 기능이

조각난 페이지 검색

조각난 페이지 검색은 데이터베이스 일관성을 유지하는 데 도움이 됩니다. Windows NT는 512바이트 세그먼트 단위로 I/O를 수행하지만 SQL Server 7.0의 페이지는 8K입니다. 이 불일치 때문에 페이지가 부분적으로 기록될 가능성이 있습니다. 처음 512바이트 세그먼트가 기록된 다음 8K I/O가 완료되기 전에 정전이나 기타 문제가 생기면 이런 상황이 발생할 수 있습니다.

처음 512바이트 세그먼트가 기록된 경우 실제로는 그렇지 않은데도 페이지가 업데이트된 것처럼 보일 것입니다. 페이지의 타임스탬프는 페이지의 처음 96바이트 헤더에 있습니다. 몇 가지 방법을 사용하여 이 문제를 처리할 수 있습니다. 먼저, I/O가 모두 수행되거나 전혀 수행되지 않도록 하는, 캐시를 사용하는 배터리 장착 I/O 장치를 사용하는 방법이 있습니다. 이런 시스템을 보유한 경우 조각난 페이지 검색이 필요하지 않습니다.

SQL Server는 페이지에 포함된 각 세그먼트의 비트를 하나씩 사용하여 비트 마스크를 생성함으로써 불완전한 I/O를 검색할 수 있습니다. 페이지가 기록될 때마다 이 비트가 이전 상태(디스크에 있었던 상태)에서 전환되며 실제 상태가 페이지 헤더에 저장됩니다. 페이지가 읽힐 때 비트 상태가 올바르지 않으면 이는 I/O가 아직 완료되지 않았고 조각난 페이지가 있다는 뜻입니다. 이 메커니즘은 검사값을 계산하는 것보다 저렴합니다.

비트가 전환되면 페이지 헤더에 표시가 되기 때문에 조각난 페이지 검색을 켜고 끌 수 있습니다. 조각난 페이지 검색을 켰다 끈 경우 비트 전환된 페이지의 상태가 관찰되며 다음 번에 이 페이지가 읽힐 때 그 상태가 바로잡힙니다.

향상된 잠금 기능

행 수준 잠금

SQL Server 6.5에서는 삽입에 대한 행 잠금을 도입했었습니다. 이제 SQL Server 7.0은 데이터 행과 인덱스 항목 모두에 대한 완전한 행 수준 잠금을 지원합니다. 트랜잭션은 페이지를 차단하지 않은 상태에서 개별 레코드를 업데이트할 수 있습니다. 특히 테이블과 인덱스에 행을 추가할 때 많은 OLTP 응용 프로그램이 병행성 향상을 직접 확인할 수 있습니다.

잠금 관리자가 대규모 데이터베이스에 사용되는 리소스를 동적으로 조정하기 때문에 잠금 서버 구성 옵션을 수동으로 조정할 필요가 없습니다. 잠금 관리자는 테이블 스캔에 적합한 페이지 잠금과 데이터 삽입, 업데이트, 삭제에 적합한 행 수준 잠금 중 하나를 자동으로 선택합니다.

동적 잠금

SQL Server 7.0은 다른 데이터베이스 업체에서는 제공하지 않는 뛰어난 잠금 메커니즘을 가지고 있습니다. 실행 시, 저장소 엔진은 쿼리 프로세서와 동적인 협력 관계를 맺고 스키마 및 쿼리의 특성을 기반으로 하여 비용이 가장 낮은 잠금 전략을 선택합니다.

동적 잠금에는 아래와 같은 이점이 있습니다.

• 데이터베이스 관리자가 더 이상 잠금 수준 조정 임계값을 조정하는 데 관여할 필요가 없기 때문에 데이터베이스 관리가 간소화됩니다.
• SQL Server가 해당 작업에 적합한 잠금을 사용하여 시스템 오버헤드를 최소화하기 때문에 성능이 향상됩니다.
• SQL Server가 잠금을 자동으로 조정하기 때문에 응용 프로그램 개발자가 개발에 전념할 수 있습니다.

복수 단위 잠금은 트랜잭션이 서로 다른 리소스 종류를 잠글 수 있도록 합니다. 잠금 비용을 최소화하기 위해 SQL Server는 해당 작업에 적합한 수준에서 리소스를 자동으로 잠급니다. 행 같은 작은 단위로 잠그면 병행성은 높아지지만 많은 행을 잠그는 경우 많은 잠금을 유지해야 하기 때문에 오버헤드가 커집니다. 테이블 같은 큰 단위로 잠그는 경우, 전체 테이블을 잠금으로 인해 다른 트랜잭션들이 테이블의 어떤 부분에도 액세스할 수 없기 때문에 병행성은 낮아지지만 유지해야 하는 잠금이 적기 때문에 오버헤드는 줄어듭니다.

SQL Server는 아래와 같은 리소스(작은 단위부터 나열됨)를 잠글 수 있습니다.

잠금 모드

SQL Server는 여러 가지 잠금 모드를 사용하여 리소스를 잠급니다. 이러한 잠금 모드가 병행 트랜잭션이 리소스에 어떻게 액세스할 수 있는지를 결정합니다.

SQL Server는 아래와 같은 리소스 잠금 모드를 사용합니다.

공유 잠금

공유 잠금은 병행 트랜잭션이 하나의 리소스를 읽을 수 있도록 합니다. 리소스에 공유 잠금이 설정되어 있으면 다른 어떤 트랜잭션도 그 데이터를 수정할 수 없습니다. 트랜잭션 격리 수준이 반복 읽기 이상으로 설정되어 있거나 트랜잭션이 진행되는 동안 공유 잠금을 유지하기 위해 잠금 참고를 사용하지 않는 한 데이터가 읽히면 바로 리소스에 대한 공유 잠금이 해제됩니다.

업데이트 잠금

업데이트 잠금은 일반적인 형태의 교착 상태를 방지합니다. 두 트랜잭션이 한 리소스에 대해 공유 모드 잠금을 얻은 다음 데이터를 동시에 업데이트하려 하는 경우 양쪽 모두 단독 잠금으로 전환하려 합니다. 따라서 두 트랜잭션 모두 상대방이 공유 모드 잠금을 해제하기를 기다리기 때문에 교착 상태가 발생합니다. 업데이트 잠금은 이 문제를 없애는 데 사용되며 한 번에 하나의 트랜잭션만 리소스에 대한 업데이트 잠금을 얻을 수 있습니다.

단독 잠금

단독 잠금은 병행 트랜잭션이 하나의 리소스에 액세스하지 못하도록 합니다. 다른 어떤 트랜잭션도 단독 잠금으로 잠긴 데이터를 읽거나 수정할 수 없습니다.

내재된 잠금

내재된 잠금은 SQL Server가 계층 구조의 하위에 있는 리소스에 대해 공유 잠금이나 단독 잠금을 얻고자 한다는 것을 나타냅니다. 트랜잭션이 테이블 잠금을 안전하게 얻을 수 있는지 확인하기 위해 SQL Server가 해당 테이블 수준의 내재된 잠금만 검사하면 되기 때문에 내재된 잠금은 성능을 향상시킵니다. 따라서 트랜잭션이 전체 테이블을 잠글 수 있는지 확인하기 위해 테이블에 대한 각 행 잠금이나 페이지 잠금을 검사할 필요가 없습니다.

스키마 잠금

열 추가 또는 테이블 삭제 같은 테이블 데이터 정의 언어(DDL) 작업이 수행되고 있을 때 스키마 잠금이 사용됩니다. 쿼리를 컴파일할 때는 단독 잠금을 포함한 어떤 트랜잭션적 잠금도 방해하지 않는 또 다른 종류의 스키마 잠금이 사용됩니다. 쿼리가 컴파일되는 동안 다른 트랜잭션이 실행될 수는 있지만 테이블에 DDL 작업을 수행할 수는 없습니다.

기본 테이블 및 인덱스 아키텍처

개요

기본 테이블 구성에 근본적인 변화가 생겼습니다. 이 새 구성에서는 쿼리 프로세서가 보조 인덱스를 더 많이 사용할 수 있기 때문에 의사 결정 지원 응용 프로그램의 성능이 크게 향상됩니다. 쿼리 최적화 프로그램은 다양한 실행 전략 집합을 사용하며 이전 버전의 SQL Server에 존재하던 많은 최적화 제한이 제거되었습니다. 특히, SQL Server 7.0에서는 인덱스 선택 문제의 중요성이 낮기 때문에 조정 작업이 줄어듭니다.

테이블 구성

이제 각 테이블의 데이터가 8K 데이터 페이지 집합에 저장됩니다. 각 데이터 페이지에는 96바이트 헤더가 있으며 이 헤더에는 페이지를 소유한 테이블의 ID 및 목록에 연결된 이전 페이지와 다음 페이지에 대한 포인터 같은 시스템 정보가 포함됩니다. 페이지 끝에 행 오프셋 테이블이 있습니다. 데이터 행이 페이지의 나머지 부분을 채웁니다.

SQL Server 7.0 테이블은 아래의 두 방법 중 하나를 사용하여 데이터 페이지를 구성합니다.

• 클러스터된 테이블은 클러스터된 인덱스를 가진 테이블입니다. 데이터 행은 클러스터된 인덱스 키를 기준으로 순서대로 저장됩니다. 데이터 페이지는 이중으로 연결된 목록에 연결됩니다. 인덱스는 클러스터된 인덱스 키 값을 기준으로 행을 빠르게 가져올 수 있도록 하는 B-트리 인덱스 구조로 구현됩니다.
• 힙은 클러스터된 인덱스가 없는 테이블입니다. 데이터 행은 특별한 순서 없이 저장되며 데이터 페이지에도 특별한 순서가 없습니다. 데이터 페이지는 연결 목록에 연결되지 않습니다.

테이블 인덱스

SQL Server 인덱스는 테이블에 연결된 구조로서 테이블의 행을 빠르게 가져올 수 있도록 합니다. 인덱스에는 테이블에 있는 하나 이상의 열로 만든 키들이 포함됩니다. 이 키들은 SQL Server가 키 값에 연결된 행을 빠르고 효율적으로 찾을 수 있도록 하는 구조로 저장됩니다. 인덱스 없이 테이블을 만들면 데이터 행이 특별한 순서 없이 저장됩니다. 이 구조를 힙이라고 합니다. SQL Server 인덱스에는 클러스터된 인덱스와 클러스터되지 않은 인덱스의 두 종류가 있습니다.

클러스터된 인덱스

인덱스에 포함된 값이 테이블에 저장된 데이터와 같은 순서로 배치되는 것이 클러스터된 인덱스입니다. 어느 정도는 데이터 저장소를 인덱스라고 할 수 있습니다. 클러스터된 인덱스는 전화 번호부에 사용되는 인덱싱 방법과 비슷합니다. 전화 번호부의 데이터는 각 항목의 성에 따라 정렬되며 각 항목의 위치는 성에 의해 결정됩니다.

클러스터된 인덱스가 테이블의 데이터 저장을 결정하기 때문에 테이블은 클러스터된 인덱스를 하나만 포함할 수 있습니다. 그러나 여러 열에 인덱스를 만들 수 있습니다. 예를 들어, 전화 번호부는 성에 따라 조직되지만 성 안에서는 같은 성을 가진 항목이 둘 이상 있을 때 이름에 따라 조직됩니다

클러스터된 인덱스는 특정 인덱스 영역에 저장된 값 범위를 가진 계층 트리를 포함합니다. 클러스터된 인덱스 값을 기준으로 데이터를 검색할 때, SQL Server는 지정된 값을 가진 페이지를 신속히 격리한 후 페이지에서 지정된 값을 가진 레코드를 검색합니다. 인덱스 트리의 최하위 수준, 즉 잎 노드는 데이터가 포함된 페이지입니다.

클러스터되지 않은 인덱스

클러스터되지 않은 인덱스는 교과서의 인덱스와 비슷합니다. 데이터와 인덱스는 서로 다른 위치에 저장되며 인덱스에는 인덱스 항목이 저장된 위치를 가리키는 포인터가 포함됩니다. 클러스터되지 않은 인덱스의 최하위 수준, 즉 잎 노드는 인덱스 항목의 저장 위치로서 페이지 번호와 페이지 내의 오프셋을 표시합니다. 따라서 클러스터된 인덱스와는 달리 클러스터되지 않은 인덱스에는 인덱스 구조와 데이터 자체 사이에 추가 수준이 포함됩니다.

클러스터되지 않은 인덱스를 기준으로 데이터를 검색할 때, SQL Server는 인덱스에서 지정된 값을 검색하여 데이터 행의 위치를 알아낸 다음 그 저장 위치에서 데이터를 직접 가져옵니다. 따라서 정확하게 일치하는 값을 찾아야 하는 쿼리에는 클러스터되지 않은 인덱스가 적합합니다.

어떤 책에는 인덱스가 여러 개 있습니다. 예를 들어, 원예 서적의 경우 식물의 속명과 학명에 대한 인덱스가 따로 있을 수 있습니다. 독자들이 일반적으로 이 두 가지 이름을 사용하여 정보를 찾기 때문입니다. 클러스터되지 않은 인덱스에서도 마찬가지입니다. 테이블의 데이터를 찾는 데 일반적으로 사용되는 각 열에 대해 클러스터되지 않은 인덱스를 정의할 수 있습니다.

클러스터되지 않은 인덱스가 클러스터된 인덱스 키를 데이터 행에 대한 포인터로 저장하기 때문에 클러스터된 인덱스 키를 최대한 작게 유지하는 것이 중요합니다. 테이블에 클러스터되지 않은 인덱스도 있는 경우 규모가 큰 열을 클러스터된 인덱스에 대한 키로 선택하지 마십시오.

SQL Server는 테이블마다 최고 249개의 클러스터되지 않은 인덱스를 지원합니다. 클러스터되지 않은 인덱스는 클러스터된 인덱스와 비슷한 B-트리 인덱스 구조를 가집니다. 차이점은 클러스터되지 않은 인덱스는 데이터 행의 순서에 어떤 영향도 미치지 않는다는 것입니다. 테이블에 대해 클러스터되지 않은 인덱스를 정의한 경우 힙의 데이터 페이지 모음은 영향을 받지 않습니다.

분포 통계

모든 인덱스에는 인덱스에 포함된 키 값의 선택도와 분포 상태를 나타내는 분포 통계가 있습니다. 선택도란 하나의 키 값이 일반적으로 얼마나 많은 행을 식별하는지 나타내는 속성입니다. 고유 키는 선택도가 높고 1,000개의 행에서 발견되는 키 값은 선택도가 낮습니다. 선택도와 분포 통계는 SQL Server가 Transact-SQL 문을 처리할 때 테이블 검색을 최적화하기 위해 사용합니다. 각 인덱스의 통계는 단일 페이지로 제한되지 않으며 image 데이터의 저장 방식과 마찬가지로 여러 페이지에 걸친 긴 비트 문자열로 저장됩니다.

데이터 형식의 변화

유니코드 데이터

SQL Server는 유니코드 데이터 형식을 지원합니다. 유니코드는 문자를 변환하고 복수 코드 페이지를 설치하는 데 따른 문제를 제거함으로써 하나의 데이터베이스에 데이터를 복수 언어로 쉽게 저장할 수 있도록 합니다. 유니코드는 각 문자에 1바이트가 아닌 2바이트를 사용하여 문자 데이터를 저장합니다. 2바이트에는 65,536개의 서로 다른 비트 패턴이 있기 때문에, 유니코드는 표준 비트 패턴 집합 하나를 사용하여 수많은 문자를 가진 중국어 같은 언어를 포함한 모든 언어의 각 문자를 인코딩할 수 있습니다. 프로그래밍 언어 또한 유니코드 데이터 형식을 지원합니다.

유니코드 데이터는 2배나 많은 저장소 공간을 필요로 하지만 이 단점은 코드 페이지 간에 확장 문자를 변환해야 하는 번거로움을 제거해 주는 장점을 통해 상쇄됩니다. 유니코드를 지원하는 새로운 데이터 형식은 ntext, nchar 및 nvarchar입니다. 지원하는 문자 범위가 더 넓고 저장소 공간을 더 많이 사용한다는 점을 제외하면 이들은 text, char 및 varchar와 같습니다.

SQL Server의 전통적인 비유니코드 데이터 형식은 특정 문자 집합에서 정의된 문자를 사용할 수 있도록 허용합니다. 문자 집합은 SQL Server 설치 중에 선택되며 다시 설치하기 전에는 변경할 수 없습니다. 유니코드 데이터 형식을 사용하면 열이 유니코드 표준에 정의된 모든 문자를 저장할 수 있습니다. 유니코드 표준은 다양한 문자 집합에 정의된 모든 문자를 포함합니다. 유니코드 데이터 형식을 사용하면 비유니코드 데이터 형식을 사용할 때보다 저장소 공간이 2배나 더 필요합니다.

향상된 데이터 저장소

char, varchar, binary 및 varbinary 데이터 형식의 최대 한도를 255바이트에서 8,000바이트로 확장하여 데이터 저장소의 융통성이 크게 향상되었습니다. 이제 아주 큰 데이터 값을 제외하고 데이터 저장소에 text 및 image 데이터 형식을 사용할 필요가 없습니다. Transact-SQL 문자열 함수 또한 이러한 매우 긴 char 및 varchar 값을 지원하지만 SUBSTRING 함수를 사용하여 text 및 image 열을 처리할 수 있습니다. Null 및 빈 문자열 처리도 향상되었습니다. 전역 고유 식별자(GUID)의 저장을 위해 uniqueidentifier라는 새 데이터 형식이 제공됩니다.

텍스트 및 이미지 향상

SQL Server는 개체 관계형 기능을 구축할 수 있는 확고한 기반을 가지고 있습니다. 직접적인 성능 향상의 예로 효율적인 새 데이터 구조를 사용하는 텍스트 및 이미지 저장소를 들 수 있습니다.

SQL Server 7.0의 ntext, text 및 image 데이터 형식은 아주 많은 데이터(최대 2GB)를 단일 값으로 저장할 수 있습니다. 일반적으로 단일 데이터 값은 응용 프로그램이 한 번에 가져올 수 있는 양보다 크며 일부 값은 클라이언트에서 사용할 수 있는 가상 메모리보다 클 수도 있습니다. 이는 이런 값을 가져오려면 보통 특별한 단계를 밟아야 한다는 뜻입니다. 이러한 데이터 형식의 값이 유니코드(4,000바이트), 문자(8,000바이트) 또는 이진 문자열(8000바이트)보다 길지 않은 경우, 작은 데이터 형식과 같은 방식으로 SELECT, UPDATE 및 INSERT 문에서 그 값을 참조할 수 있습니다.

Text, ntext 및 image 값은 데이터 행의 일부로 저장되지 않고 자체적인 별도의 페이지 모음에 저장됩니다. 이러한 각 값에서 데이터 행에는 16바이트 포인터만 저장됩니다. 각 행의 이 포인터는 데이터의 위치를 가리킵니다. text, ntext 또는 image 열이 여러 개 포함된 행은 각 열에 대해 하나의 포인터를 가집니다.

데이터는 반드시 서로 인접하지 않아도 되는 8K 페이지 모음에 저장됩니다. SQL Server 7.0의 페이지는 B-트리 구조에 논리적으로 조직됩니다. 그러나 이전 버전의 SQL Server에서는 페이지들이 서로 페이지 체인으로 연결되었습니다. SQL Server 7.0이 사용하는 방법의 이점은 문자열의 중간에서 시작하는 작업이 보다 효율적이라는 것입니다. SQL Server 7.0은 B-트리를 빠르게 탐색할 수 있지만 이전 버전의 SQL Server는 페이지 체인 전체를 검색해야 했습니다. 데이터가 32K를 넘느냐 그렇지 않느냐에 따라 B-트리의 구조가 약간 달라집니다.

트랜잭션 로그 관리

개요

트랜잭션 로그는 시스템 실패 시 데이터베이스 무결성을 복구하는 데 도움이 됩니다. 단일 데이터베이스에 대한 로그 기록이 로그 파일이라는 하나 이상의 운영 체제 파일에 유지됩니다. 이는 데이터베이스에 발생한 모든 수정 사항 및 각 수정 작업을 수행한 트랜잭션을 순차적으로 기록한 것입니다.

데이터베이스에 로그 작업이 수행되는 한 로그는 끊임없이 확장됩니다. 일부 대규모 작업의 경우 작업이 수행되었다는 사실만 로그에 기록됩니다. 로그는 각 트랜잭션의 커밋 또는 롤백을 기록합니다. 이에 따라 SQL Server가 아래와 같이 각 트랜잭션을 복원하거나 취소할 수 있습니다.

• 완료되지 않은 트랜잭션을 취소하면 트랜잭션 롤백이 이뤄집니다. SQL Server는 변경 순서를 거꾸로 되돌려 트랜잭션이 시작되기 이전의 상태로 데이터베이스를 복원합니다.
• 트랜잭션 로그를 복원하면 트랜잭션 롤포워드가 이뤄집니다. 데이터베이스 수정 사항이 원래 발생한 순서대로 적용됩니다. 이 프로세스가 끝나면 데이터베이스의 상태가 로그가 백업되었을 때의 상태와 같아집니다.

SQL Server 7.0의 로그 관리자는 버전 6.5보다 향상된 기능을 제공합니다. 새 로그 관리자는 아래와 같은 이점을 제공합니다.

• 버퍼 캐시 페이지를 차지하기 위해 데이터와 경합하지 않습니다.
• 하나 이상의 실제 파일에 분산될 수 있습니다.
• 자동으로 확장되고 축소됩니다.
• 다른 작업을 방해하지 않는 빠른 잘라내기를 허용합니다.
• 대량 I/O가 가능하도록 합니다.

로그 관리자 아키텍처

SQL Server 7.0 로그는 로그 항목만 포함된 하나 이상의 실제 파일로 구성됩니다. 이전 버전의 로그는 일반 데이터베이스 페이지를 사용하는 시스템 테이블이었습니다. 이러한 로그 페이지는 다른 테이블의 페이지처럼 할당되거나 해제되었으며 메모리 캐시의 공간을 차지하기 위해 데이터 페이지와 경합했습니다.

각 로그 파일은 논리적으로 가상 로그 파일이라는 더 작은 세그먼트로 나뉩니다. 가상 로그 파일은 트랜잭션 로그의 잘라내기 단위입니다. 가상 로그 파일에 더 이상 활성 트랜잭션에 대한 로그 레코드가 없으면 그 파일을 잘라낼 수 있으며 그 공간을 새 트랜잭션 로깅에 사용할 수 있습니다.

SQL Server는 아주 작은 가상 로그 파일은 되도록 조금만 유지하려 합니다. 가상 로그 파일의 수는 그 크기에 비해 느리게 증가합니다. 로그 파일이 작은 단위로 확장되는 경우 많은 수의 작은 가상 로그 파일을 갖게 됩니다. 로그 파일이 큰 단위로 확장되는 경우 SQL Server는 큰 가상 로그 파일을 조금만 만듭니다.

로그에 레코드가 기록되면 로그의 끝이 그 다음 가상 로그 파일까지 늘어납니다. 데이터베이스의 실제 로그 파일이 둘 이상 있는 경우, 로그의 끝이 각 실제 파일의 각 가상 파일을 통과하면서 늘어났다가 첫째 실제 파일의 첫째 가상 로그 파일로 다시 순환하여 돌아옵니다.

가상 로그 파일의 최소 크기는 256K입니다. 트랜잭션 로그의 최소 크기는 512K이기 때문에 256K 가상 로그 파일 두 개를 사용할 수 있습니다. 트랜잭션 로그에 있는 가상 로그 파일의 개수와 크기는 로그 파일의 크기가 커질 때 함께 증가합니다. 작은 로그 파일은 몇 개의 작은 가상 로그 파일을 가질 것이고 아주 큰 로그 파일은 큰 가상 로그 파일을 가질 것입니다.

이제 로그가 자동으로 확장되고 축소될 수 있습니다. 사용할 수 있는 재사용 가능 공간이 없는 경우 논리 로그 파일 청크를 더 추가하여 파일이 확장됩니다. 공간이 더 많이 필요하면 논리 로그 파일이 또 추가됩니다. 내부적으로 로그 관리자는 실제 로그 파일을 논리 로그 파일로 나눕니다. 논리 파일은 활성 또는 재사용 가능한 것으로 간주됩니다. 논리 로그 파일에 활성 로그의 어떤 영역도 포함되지 않은 경우 이를 백업할 수 있습니다. 백업한 파일은 다시 사용할 수 있습니다.

메모리, 버퍼링 및 미리 읽기

메모리 자동 관리

SQL Server는 사용 가능한 시스템 리소스를 기준으로 메모리 요구 사항을 동적으로 변경합니다. 또는 원하는 경우 수동으로 고정할 수 있습니다. 이 메커니즘을 통해 시스템 리소스를 최적의 상태로 사용할 수 있습니다.

SQL Server에는 사용 가능한 메모리를 반드시 공유해야 하는 하위 시스템이 몇 개 있습니다. 로그 및 복구 시스템은 페이지 읽기와 실행 취소를 위해, 쿼리 프로세서는 해싱과 정렬을 위해 메모리를 필요로 합니다. 메모리를 사용하는 다른 하위 시스템으로는 프로시저 캐시, 버퍼 풀, 잠금 관리자 및 데이터 구조가 있습니다. SQL Server 7.0에서 이 시스템들은 필요한 메모리를 동적으로 할당하고 더 이상 메모리가 필요하지 않을 때 반환할 수 있습니다.

SQL Server는 기본 메모리 값에서 시작합니다. 더 많은 응용 프로그램이 시작되면 시스템에 사용 가능한 실제 메모리의 양을 확인하기 위한 조회가 주기적으로 들어옵니다. SQL Server는 Windows NT의 페이징을 방지하기 위해 버퍼 캐시를 늘리거나 축소하여 사용 가능한 실제 메모리의 양을 5MB 정도로 유지합니다. 사용 가능한 메모리가 5MB 미만이면 SQL Server는 Windows NT에 메모리를 반환하며 이 메모리는 보통 사용 가능한 메모리 목록에 등록됩니다. 실제 메모리가 5MB를 넘으면 SQL Server는 메모리를 다시 버퍼 캐시에 할당합니다. SQL Server는 작업 로드에 메모리가 더 많이 필요할 때 버퍼 캐시에 메모리를 추가합니다. 유휴 서버는 버퍼 캐시를 늘리지 않습니다.

버퍼 관리 및 I/O

버퍼 관리 I/O가 변경되어 이제 LRU(최근에 사용되지 않은 것부터 사용) 목록 대신 클럭킹 메커니즘을 사용합니다. 동기화 요구가 적기 때문에 클럭킹 메커니즘은 성능을 향상시킵니다. 이를 통해 대형 SMP 시스템에서는 성능이 향상되지만 소형 시스템에는 큰 효과가 없습니다. 데이터베이스 개체를 구성하는 파일에 병렬 I/O와 대량 I/O 모두 사용되기 때문에 쿼리 성능이 향상됩니다.

미리 읽기

미리 읽기 메커니즘이 크게 향상되고 간소화되었습니다. 쿼리 프로세서와 저장소 엔진에서 참고 및 지침을 적절히 사용함으로써 구성 매개 변수는 물론 별도의 메커니즘에 사용되던 1,000줄 이상의 코드를 제거할 수 있었습니다. 이를 통해 별도의 미리 읽기 스레드가 제거되고 컨텍스트 스위치가 최소화됩니다. 새로운 할당 데이터 구조는 페이지 체인을 따르지 않고 페이지를 미리 읽을 수 있도록 합니다. 쿼리 프로세서는 중간 계층 인덱스를 사용하여 인덱스 스캔(클러스터된 테이블 스캔 포함)의 다음 페이지를 예상함으로써 미리 읽기를 도울 수 있습니다.

병렬 미리 읽기 메커니즘은 디스크 하위 시스템이 최고 속도로 동작할 수 있도록 합니다. 입력과 출력이 분리되고 이 메커니즘이 데이터 페이지를 얻은 다음 이들을 사용 가능한 다음 CPU(복수 CPU 시스템의 경우)로 보냅니다. I/O는 여러 파일에 대해 동시에 발급됩니다.

혁신과 발전

SQL Server 7.0은 SQL Server 6.5가 닦아 놓은 탄탄한 기반 위에 구축된 Microsoft 데이터베이스 제품의 획기적인 릴리스입니다. SQL Server 7.0과 관련하여 13개 이상의 데이터베이스 기술이 새로 특허 출원되었습니다. Microsoft SQL Server 7.0은 아래와 같은 중대한 혁신을 가져와 업계를 선도하고 있습니다.

• 동일한 코드 기반을 사용하여 랩톱에서 엔터프라이즈까지 확장됨으로써 100% 코드 호환성을 제공하는 최초의 데이터베이스
• 자동 구성 및 자가 조정을 지원하는 최초의 데이터베이스
• 통합 OLAP 서버를 사용하는 최초의 데이터베이스
• 통합 데이터 변환 서비스를 사용하는 최초의 데이터베이스
• 데이터 웨어하우징 프레임워크(메타데이터 문제를 해결하기 위한 최초의 총체적 방안)
• 많은 수의 서버에 대해 복수 서버 관리를 제공하는 최초의 데이터베이스
• 모든 데이터베이스에 가장 폭넓은 복제 옵션 제공
• Windows NT Server, Microsoft Office 및 BackOffice와의 최상의 통합
• 범용 데이터 액세스(다양한 정보 원본에 대한 고성능 액세스를 제공하기 위한 Microsoft의 전략)

Microsoft는 향상된 새 기능에 대한 고객들의 요구에 항상 귀기울이고 있습니다. 새 저장소 엔진 아키텍처는 고객 응용 프로그램을 다음 세기까지도 충분히 지원할 수 있도록 설계되었습니다. Microsoft 설계 팀은 시간이 지남에 따라 구성 요소를 쉽게 개선하고 바꿀 수 있도록 명료한 하위 시스템을 구현하기 위해 노력했습니다. 저장소 엔진은 전반적인 확장성은 물론 이미 이후의 릴리스에 포함하기로 결정한 특정 기능을 위해 설계되었습니다.

이 문서에 포함된 정보는 문서를 발행할 때 논의된 문제들에 대한 Microsoft Corporation의 당시 관점을 나타냅니다. Microsoft는 변화하는 시장 환경에 대처해야 하므로 이를 Microsoft 측의 책임으로 해석해서는 안 되며 발행일 이후 소개된 어떠한 정보에 대해서도 Microsoft는 그 정확성을 보장하지 않습니다.

이 설명서는 오직 정보를 제공하기 위한 것입니다. Microsoft는 이 설명서에서 어떠한 명시적이거나 묵시적인 보증도 하지 않습니다.

© 1998 Microsoft Corporation. All rights reserved.

Microsoft, Windows 및 Windows NT는 미국, 대한민국, 및/또는 기타 국가에서의 Microsoft Corporation의 등록 상표 또는 상표입니다.

여기에 인용된 다른 상표 및 상표명은 해당 소유자의 소유일 수 있습니다.

Microsoft Part Number: 098-80769 SQL Srv 7.0 Storage Engine.