확장 가능한 스토리지 엔진 파일
적용 대상: Windows | Windows Server
확장 가능한 스토리지 엔진 파일
확장 가능한 스토리지 엔진은 다음과 같은 유형의 파일을 사용합니다.
이 표에는 ESE에서 관리하는 데이터 파일 이름에 대한 개요가 포함되어 있습니다. Windows Vista 이상에서는 JET_paramLegacyNames 설정이 사용되는 파일 이름에 영향을 줍니다.
| 레이블 | 값 |
|---|---|
트랜잭션 로그 파일
트랜잭션 로그 파일에는 데이터베이스 파일에 대한 작업이 포함됩니다. 예기치 않은 프로세스 종료 또는 시스템 종료 후 데이터베이스를 논리적으로 일관된 상태로 만들기에 충분한 정보가 포함되어 있습니다.
로그 파일의 이름은 JET_paramBaseName 사용하여 설정할 수 있는 3자로 된 기본 이름에 따라 달라집니다. 아래 예제에서는 기본 기본 이름이기 때문에 "edb"의 기본 이름을 사용합니다. 트랜잭션 로그 파일의 확장명은 JET_bitESE98FileNames JET_paramLegacyFileNames 매개 변수에 설정되어 있는지 여부에 따라 .log 또는 .jtx가 됩니다. 자세한 내용은 확장 가능한 스토리지 엔진 시스템 매개 변수를 참조하세요.
트랜잭션 로그 파일의 이름은 1부터 base><generation-number.log>로 지정<됩니다. 로그 생성 번호는 16진수 형식입니다. 예를 들어 edb00001.log는 첫 번째 로그이고 edb000ff.log는 255번째 로그입니다. 로그 파일에는 1048576번째 로그 파일까지 로그 파일 이름에 5개의 16진수 숫자가 있으며, 이때 로그 파일의 이름은 11.3 형식(예: edb00100000.log)으로 지정되기 시작합니다. <base.log>는 항상 현재 사용 중인 로그 파일입니다. 데이터베이스 엔진이 활성 상태가 아닌 경우esentutl.exe -ml edb.log 명령을 사용하여 edb.log 생성을 식별할 수 있습니다.
트랜잭션 로그 파일에는 가 있지만 일반적으로 텍스트 파일과 연결된 LOG 확장명은 트랜잭션 로그 파일은 이진 형식이며 사용자가 편집해서는 안 됩니다. 데이터베이스 작업은 먼저 로그에 기록됩니다. 데이터는 나중에 데이터베이스 파일에 쓸 수 있습니다. 아마도 즉시, 잠재적으로 훨씬 나중에. 예기치 않은 프로세스 또는 시스템 종료가 발생할 경우 작업은 로그 파일에 계속 존재하며 불완전한 트랜잭션을 롤백할 수 있습니다. 트랜잭션 로그 파일을 재생하는 작업을 일시 복구라고 하며 JetInit 또는JetInit2 가 호출되면 자동으로 수행됩니다. 소프트 복구는 Esentutl.exe 프로그램의 "-r" 옵션을 사용하여 수동으로 수행할 수도 있습니다. 백업에서 복원된 데이터베이스에서 트랜잭션 로그 파일을 재생하는 작업을 하드 복구라고 합니다.
로그 파일은 고정 크기이며 JET_paramLogFileSize 사용하여 사용자 지정할 수 있습니다. 현재 로그 파일(즉, edb.log)이 채워지면 기본 generation-number.log>로 <><이름이 바뀌고 트랜잭션 로그 스트림에 새 트랜잭션 로그 파일이 필요합니다.
각 데이터베이스 instance 연결된 단일 로그 파일 시퀀스가 있습니다. Windows XP는 JetCreateInstance를 도입하여 단일 프로세스에서 여러 트랜잭션 로그 파일 시퀀스를 사용할 수 있도록 했습니다. 그러나 동일한 디렉터리에는 여러 트랜잭션 로그 파일 시퀀스가 있을 수 없습니다.
데이터 손상이 발생할 수 있으므로 트랜잭션 로그 파일을 수동으로 조작, 이름 바꾸기, 이동 또는 삭제해서는 안 됩니다.
트랜잭션 로그 파일은 전체 백업(JetBackup, JetTruncateLog, JetTruncateLogInstance 참조) 또는 일반 작업 중에 순환 로깅을 사용하는 경우 데이터베이스 엔진에서 삭제됩니다.
트랜잭션 로그 파일이 채워지면 데이터베이스 엔진에서 새 로그 파일을 만들어야 합니다. 순환 로깅은 크래시 복구에 더 이상 필요하지 않은 경우 데이터베이스 엔진에서 로그 파일을 자동으로 정리할 수 있는 수단입니다. 이 프로세스는 백업을 수행하는 부산물로 로그 파일을 제거하는 대안입니다. 순환 로깅은 JET_paramCircularLog 시스템 매개 변수를 사용하여 제어할 수 있습니다. 트랜잭션 로그 파일은 다른 메서드를 사용하여 삭제해서는 안 됩니다.
임시 트랜잭션 로그 파일
edb.log가 채워지면 ESE는 새 파일을 만들어야 합니다. 새 로그 트랜잭션 파일을 ESE에서 사용하기 전에 임시 트랜잭션 로그 파일이라고 합니다.
새 로그 파일이 만들어지고 크기가 확장되는 동안 기본>tmp.log라고 합니다<. 새 파일을 만드는 작업은 비용이 많이 들 수 있으므로 ESE는 백그라운드 작업으로 사전에 다음 로그 파일을 만듭니다.
임시 트랜잭션 로그 파일은 새 트랜잭션 로그 파일이 필요할 것으로 예상하여 생성되므로 유용한 정보가 포함되지 않습니다.
예약된 트랜잭션 로그 파일
예약된 트랜잭션 로그 파일은 엔진이 중요한 작업을 기록하여 클린 종료할 수 있도록 시작할 때 만들어집니다.
Windows Vista: Windows Vista 이상에서는 예약 트랜잭션 로그 파일의 이름이 기본>RESXXXXX.jrs로 지정<됩니다.
Windows Server 2003: Windows Server 2003 이하에서 예약 트랜잭션 로그 파일의 이름은 res1.log 및 res2.log입니다.
데이터베이스 엔진에 디스크 공간이 부족하면 새 로그 파일을 만들 수 없습니다. 가장 안전한 작업은 완전히 종료하는 것이지만 일부 작업(예: 롤백 작업)은 여전히 기록되어야 합니다. 대부분의 데이터베이스 작업은 이 단계에서 실패합니다.
예약된 트랜잭션 로그 파일은 디스크 부족 시나리오에서 트랜잭션 로그 파일이 필요할 것으로 예상하여 생성되므로 유용한 정보가 포함되지 않습니다.
검사점 파일
검사점 파일은 특정 트랜잭션 로그 파일 시퀀스의 검사점을 저장합니다. 검사점 파일의 이름은 JET_bitESE98FileNames JET_paramLegacyFileNames 매개 변수에 설정되어 있고 해당 위치는 JET_paramSystemPath 지정되는지 여부에 따라 base.chk> 또는 <base.jcp>로 지정<됩니다.
데이터베이스 작업은 먼저 로그 파일에 기록된 다음 메모리에 캐시됩니다. 나중에 작업이 데이터베이스 파일에 기록되지만 성능상의 이유로 작업이 데이터베이스 파일에 기록되는 순서가 원래 기록된 순서와 일치하지 않을 수 있습니다. 트랜잭션 로그 파일에 기록된 작업은 다음 두 가지 상태 중 하나에 있습니다.
트랜잭션 로그 파일 및 데이터베이스 파일에 기록됩니다.
트랜잭션 로그 파일에 기록되고 데이터베이스 파일에 아직 기록되지 않았습니다.
많은 데이터베이스 작업을 단일 트랜잭션 로그 파일에 저장할 수 있습니다. 지정된 로그 파일은 다음 항목으로 구성됩니다.
데이터베이스 파일에 기록된 모든 작업입니다.
데이터베이스 파일에 기록된 작업이 없습니다.
데이터베이스 파일에 기록된 작업과 데이터베이스 파일에 아직 기록되지 않은 작업의 혼합입니다.
검사점은 검사점 이전의 모든 작업이 데이터베이스 파일에 기록된 트랜잭션 로그 스트림의 특정 시점을 나타냅니다. 검사점 이후에 발생하는 작업에 대한 보장은 없습니다. 일부는 메모리에 있을 수 있으며 일부는 데이터베이스에 기록될 수 있습니다.
검사점 이전 로그 파일의 모든 작업이 데이터베이스 파일에 표시되므로 특정 데이터베이스를 클린 상태로 전환하려면 일시 복구에 검사점 이후의 트랜잭션 로그 파일만 필요합니다.
데이터베이스 파일
데이터베이스 파일에는 데이터베이스의 모든 테이블에 대한 스키마, 데이터베이스의 모든 테이블에 대한 레코드 및 테이블의 인덱스가 포함됩니다. 해당 위치는 JetCreateDatabase, JetCreateDatabase2, JetAttachDatabase 또는 JetAttachDatabase2를 사용하여 제공됩니다.
JetTerm 또는 JetTerm2를 성공적으로 호출한 후에만 데이터베이스가 완전히 종료됩니다.
Esentutl.exe 프로그램은 "-mh" 옵션을 사용하여 데이터베이스가 완전히 종료되었는지 여부를 감지할 수 있습니다. 예를 들어 "esentutl.exe -mh sample.edb"는 sample.edb라는 데이터베이스의 데이터베이스 헤더를 읽고 sample.edb의 상태를 출력합니다. "상태: 종료 정리" 또는 "상태: 더티 종료"를 출력할 수 있습니다.
완전히 종료되지 않은 데이터베이스는 더티 종료 상태입니다. Windows XP 이전에는 이 상태를 일관성이 없다고 했습니다. 더티(일관되지 않은) 데이터베이스는 일시 복구를 사용하여 클린 상태로 가져올 수 있습니다. 손상된 데이터베이스는 더티("일관되지 않음") 데이터베이스와 동일하지 않습니다.
손상된 데이터베이스는 물리적 또는 논리적 손상을 의미하며 일시 복구로 수정할 수 없습니다. 물리적 손상은 비트 대칭 이동일 수 있으며 데이터베이스 페이지의 체크섬에 의해 자주 포착됩니다. 데이터베이스 파일에서 실패한 체크섬은 JET_errReadVerifyFailure 오류로 나타납니다.
데이터베이스만 안전하게 이동하거나 이름을 바꿀 수 있습니다. 데이터베이스가 완전히 종료되지 않은 경우 자동으로 안전하게 이동하거나 이름을 바꿀 수 없습니다.
여러 데이터베이스를 단일 트랜잭션 로그 파일 시퀀스와 연결할 수 있습니다.
임시 데이터베이스
임시 데이터베이스는 유혹에 대한 백업 저장소로 사용되며 인덱스를 만들 때도 사용됩니다.
이름과 위치는 JET_paramTempPath 구성됩니다.
유혹자는 JetOpenTempTable, JetOpenTempTable2, JetOpenTempTable3, JetOpenTemporaryTable을 사용하여 만들어집니다. 또한 일부 API 호출에서 만들어지고 스키마 정보(예: JetGetIndexInfo)를 반환하는 데 사용됩니다.
맵 파일 플러시
Windows 10 1주년 업데이트(클라이언트) 및 Windows Server 2016(서버)부터 ESE는 손실된 쓰기(또는 손실된 플러시) 1에 대한 추가 보호 수준을 추가하여 이러한 이벤트를 교차 프로세스 다시 초기화2로 검색할 수 있도록 했습니다. 이 기능을 사용하려면 메타데이터를 "플러시 맵" 파일이라는 별도의 파일에 유지해야 합니다.
각 데이터베이스 파일에 대해 하나의 플러시 맵 파일이 만들어지고 동일한 디렉터리에 있습니다. 파일 이름은 데이터베이스 파일과 비슷하지만 확장명은 다릅니다. 예를 들어 클라이언트 애플리케이션이 전체 경로 C:\MyDirectory\MyDabatase.edb를 사용하여 데이터베이스를 만드는 경우 해당 플러시 맵 파일은 C:\MyDirectory\MyDabatase.jfm입니다.
이 향상된 기능을 통해 데이터베이스 파일의 이름을 지정하는 방법에 대한 두 가지 요구 사항이 도입되었습니다.
동일한 디렉터리에 있는 두 개의 데이터베이스에는 다른 확장명이 있는 동일한 파일 이름이 없어야 합니다. 예: C:\MyDirectory\MyDabatase.db1 및 C:\MyDirectory\MyDabatase.db2.
2. 데이터베이스에 .jfm 확장이 없어야 합니다.
데이터베이스 파일을 수동으로 복사하거나 이동할 때 해당 플러시 맵 파일도 각각 복사하거나 동일한 대상 디렉터리로 이동해야 합니다. 새 데이터베이스 첨부 파일이 있을 때 플러시 맵 파일이 없는 경우( JetAttachDatabase를 통해) 데이터베이스에서 페이지를 읽을 때 새 파일이 만들어지고 요청 시 다시 채워집니다. 일치하지 않는 데이터베이스와 플러시 맵 파일을 혼합하면 ESE에서 처리되며 일치하지 않는 플러시 맵을 삭제하고 처음부터 다시 만듭니다.
플러시 맵 파일의 크기는 연결된 데이터베이스 파일에 직접 비례하며 거의 동일합니다(모든 크기(바이트). 결과는 8,192의 다음 배수로 반올림되어야 합니다.)
8,192 + ((<database file size> / <database page size>) / 4)
예를 들어 32KB 페이지 크기를 사용하는 1.5GB 데이터베이스의 경우 플러시 맵의 대략적인 크기는 24,576바이트(또는 24KB)입니다.
데이터베이스 페이지가 플러시되면 플러시 맵 파일을 새로 고쳐야 합니다. 트랜잭션 로깅을 사용하는 경우(예: "on"으로 설정된 JET_paramRecovery 기본값) 클라이언트 애플리케이션이 데이터베이스를 수정할 때 플러시 맵 새로 고침이 수행됩니다. 평균적으로 전체 플러시 맵은 생성된 트랜잭션 로그의 20% JET_paramCheckpointDepthMax 값(바이트)마다 비휘발성 미디어에 한 번씩 기록됩니다. 쓰기 작업의 수는 수정된 데이터베이스 전체에 분산되는 방식에 따라 달라집니다. 그러나 최대 약(모든 크기(바이트)입니다.
<flush map file size> / JET_paramMaxCoalesceWriteSize
트랜잭션 로깅을 사용하지 않도록 설정하면(예: "off"로 설정된 JET_paramRecovery) 데이터베이스가 명시적으로 완전히 분리되거나(JetDetachDatabase를 통해) 연결된 ESE instance 종료하여 암시적으로 완전히 분리된 경우에만 플러시 맵이 새로 고쳐집니다(JET_bitTermDirty 전달되지 않는 한 JetTerm 함수를 통해).
1 손실된 쓰기(또는 손실된 플러시)는 운영 체제에서 ESE 데이터베이스 엔진으로 성공적으로 반환되지만 실제 데이터는 비휘발성 미디어의 데이터베이스 파일에 유지되지 않는 쓰기 작업으로 정의됩니다. 일반적으로 오작동하거나 잘못 구성된 스토리지 스택(소프트웨어 또는 하드웨어)으로 인해 발생합니다. 클라이언트 애플리케이션은 데이터가 손실된 쓰기 이벤트를 겪은 지역에 있는 경우 데이터베이스에서 데이터를 읽도록 요구하는 ESE 함수에서 JET_errReadLostFlushVerifyFailure 오류를 수신할 수 있습니다.
2 프로세스의 수명 내에서 손실된 쓰기를 검색하는 기능은 Windows 8(클라이언트) 및 Windows Server 2012(서버) 이후 존재했습니다.