Extensible Storage Engine 아키텍처

적용 대상: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

마지막으로 수정된 항목: 2008-11-19

Exchange 사서함 데이터베이스와 허브 전송 서버의 큐 및 Edge 전송 서버의 큐는 ESE(Extensible Storage Engine) 데이터베이스를 활용합니다. ESE는 DML(데이터 조작 언어) 및 DDL(데이터 정의 언어) 기능을 완전히 갖춘 다중 사용자 ISAM(Indexed Sequential Access Method) 테이블 관리자입니다. 응용 프로그램에서는 ESE를 사용하여 레코드를 저장하고 인덱스를 만들어 해당 레코드에 다양한 방식으로 액세스할 수 있습니다.

ESE 버전에는 다음 두 가지가 있습니다.

• ESENTl   Active Directory 및 여러 Microsoft Windows 구성 요소용 데이터베이스 엔진입니다. 5MB 로그 파일과 4KB 페이지 크기를 사용하는 다른 버전의 ESE와는 달리 Active Directory에서 구현되는 ESENT에서는 10MB 로그 파일과 8KB 페이지를 사용합니다.

• ESE98   Exchange 2000 Server, Exchange Server 2003 및 Exchange Server 2007의 데이터베이스 엔진입니다.

• ESE는 이전에는 JET(Joint Engine Technology) Blue로 알려졌으며, 이 JET Blue는 Microsoft Access에서 사용하는 JET 버전인 "JET Red"와는 다릅니다.

트랜잭션

ESE는 트랜잭션 기반의 정교한 데이터베이스 엔진입니다. 트랜잭션은 표시되지 않는 원자 단위로 간주되는 일련의 작업입니다. 트랜잭션의 모든 작업은 완료되어 영구적으로 저장되거나 작업이 전혀 수행되지 않습니다. 받은 편지함에서 지운 편지함 폴더로 메시지를 옮길 때 수행하는 작업을 예로 들 수 있습니다. 메시지는 한 폴더에서 삭제되고, 다른 폴더에 추가되며 폴더 속성이 업데이트됩니다. 오류가 발생했을 때 두 개의 메시지 복사본이 만들어지거나, 복사본이 전혀 생성되지 않거나, 실제 폴더 내용과 일치하지 않는 폴더 속성 값(예: 항목 수)이 생기는 것은 원하는 결과가 아닙니다.

이와 같은 문제를 막기 위해 ESE는 트랜잭션 내의 작업을 모아서 처리합니다. ESE를 사용하면 트랜잭션이 데이터베이스 파일에 커밋될 때까지는 작업이 영구적으로 적용되지 않습니다. 트랜잭션을 데이터베이스 파일에 커밋하면 모든 작업이 영구적으로 적용됩니다.

서버가 응답하지 않으면 사용자는 서버를 다시 시작하고 커밋되지 않은 트랜잭션을 롤백하며, 이때 ESE도 자동 복구 작업을 수행합니다. 트랜잭션이 커밋되기 전에 ESE에 오류가 발생하면 전체 트랜잭션이 롤백되므로 트랜잭션을 수행하지 않은 것과 마찬가지가 됩니다. 트랜잭션이 커밋된 후에 ESE가 응답하지 않으면 전체 트랜잭션이 저장되며, 클라이언트에서 변경 내용을 볼 수 있습니다.

ACID 트랜잭션

이전 섹션에 나열된 것과 같은 트랜잭션을 보통 ACID 트랜잭션이라고 합니다. ACID는 다음 특성들의 머리 글자어입니다.

• 원자성   트랜잭션 상태가 완전히 변경되거나 전혀 변경되지 않음을 나타냅니다. 원자의 상태 변경 내용에는 데이터베이스 변경 내용, 변환기의 메시지와 작업이 포함됩니다.

• 일관성   트랜잭션이 올바른 상태 변환임을 나타냅니다. 그룹 단위로 이 작업을 수행하면 상태와 연결된 무결성 제약 조건을 위반하지 않습니다. 이와 같은 방식으로 작업을 수행하려면 트랜잭션이 올바른 프로그램이어야 합니다.

• 격리성  여러 트랜잭션이 동시에 실행되어도 각 트랜잭션(t)은 다른 트랜잭션이 t 이전이나 t 이후에 실행되며, 동시에 실행되지는 않는 것처럼 표시됨을 나타냅니다.

• 지속성   커밋된 트랜잭션은 시스템이 응답하지 않아도 데이터베이스에 보존됩니다.

버전 저장소

ESE는 버전 저장소를 통해 현재 트랜잭션을 추적 및 관리할 수 있습니다. 그러므로 ESE는 ACID 테스트의 격리성 및 일관성 부분을 통과할 수 있습니다. 버전 저장소는 데이터베이스에 대해 수행한 메모리 내부의 수정 목록을 유지 관리합니다.

다음 상황에서 버전 저장소를 사용합니다.

• 롤백   트랜잭션은 롤백을 해야 하는 경우 버전 저장소를 확인하여 이전에 수행한 작업 목록을 가져옵니다. 모든 작업을 역으로 수행함으로써 트랜잭션을 롤백할 수 있습니다.

• 쓰기 충돌 감지   서로 다른 두 세션이 동일한 레코드를 수정하려고 하면 버전 저장소에서 이를 인식하여 두 번째 수정 작업을 거부합니다.

• 반복 가능한 읽기   세션에서 트랜잭션을 시작하면 현재 보고 있는 레코드를 다른 세션에서 수정하는 경우에도 항상 동일한 데이터베이스 보기가 표시됩니다. 세션에서는 레코드를 읽을 때 버전 저장소를 참조하여 세션에 표시해야 하는 레코드의 버전을 확인합니다. 반복 가능한 읽기는 클라이언트가 트랜잭션을 시작한 후에도 트랜잭션을 시작했을 때와 동일한 데이터베이스 상태를 볼 수 있는 격리 수준을 제공하며, 이때 다른 클라이언트나 세션에서 수정한 내용은 영향을 미치지 않습니다. 반복 가능한 읽기는 버전 저장소를 통해 구현됩니다. 데이터베이스에 대해 수행한 메모리 내부의 수정 목록이 있으면 특정 세션에 표시해야 할 특정 레코드 보기를 결정할 수 있습니다.

• 이미지 로깅 전 지연   ESE가 유사한 다른 데이터베이스 엔진에 비해 더 적은 데이터를 기록할 수 있도록 하는 복잡한 최적화 기능입니다.

스냅숏 격리

트랜잭션이 시작되고 나면 ESE는 세션에 트랜잭션이 시작될 때 존재했던 데이터베이스의 일관적인 단일 이미지가 해당 변경 내용과 함께 표시되도록 합니다. 다른 세션에서도 데이터를 수정하고 트랜잭션을 커밋할 수 있으므로 이러한 변경 내용은 커밋 전에 시작된 트랜잭션에는 표시되지 않습니다. 사용자는 최신 버전을 볼 수 있는 경우에만 레코드를 수정할 수 있습니다. 최신 버전을 볼 수 없는 경우에는 JET_errWriteConflict와 함께 업데이트가 실패합니다. 최신 트랜잭션 이전 버전은 자동으로 무시됩니다.

ESE에서는 스냅숏 격리라는 트랜잭션 격리 수준을 제공합니다. 사용자는 스냅숏 격리 수준을 통해 전환 방식의 일관성 있는 데이터베이스 보기를 사용하여 마지막으로 커밋된 행에 액세스할 수 있습니다. 스냅숏 격리는 ANSI SQL 격리 수준 비평 문서에서 처음으로 설명된 동시성 제어 알고리즘으로, 반복 가능한 읽기를 사용하여 ESE에서 구현됩니다.

ESE 데이터베이스 구조

서식 있는 텍스트 데이터베이스 파일 내의 모든 데이터는 B+트리에 저장됩니다. B+트리의 "B"는 "균형이 조정된"이라는 뜻입니다. "트리"는 파일 시스템의 폴더 구조와 비슷한 정렬을 나타내는데, 여기서 루트는 데이터베이스 페이지 항목의 상위 항목이며, 데이터베이스 페이지 항목은 또 다른 추가 항목의 상위 항목입니다. B+트리는 디스크의 데이터에 빠르게 액세스하기 위해 사용합니다. 디스크를 읽고 디스크에 쓰는 작업은 메모리에서 동일한 작업을 수행하는 것보다 훨씬 속도가 느리기 때문에 B+트리는 8KB 페이지로 구분됩니다. 이를 통해 ESE는 최소한의 디스크 입/출력(I/O) 수를 사용하여 필요한 데이터를 가져올 수 있습니다. 하나의 ESE 데이터베이스는 최대 2^31(2의 31승)개의 8KB 페이지를 포함할 수 있으며 총 데이터베이스 크기의 최대값은 약 16TB입니다. 그러나 실제로 데이터베이스 크기는 사용자가 데이터베이스에서 백업, 복원 및 기타 유지 관리 작업(예: 오프라인 조각 모음 및 데이터베이스 복구)을 적절한 시간 내에 수행할 수 있는 능력에 의해서만 제한됩니다.

데이터베이스 페이지

ESE의 페이지 크기는 해당 페이지를 사용하는 응용 프로그램에서 정의합니다. 예를 들어 ESE98(Exchange 2000 Server 및 Exchange Server 2003)은 4KB 페이지를 사용하는 반면 ESENT(Active Directory)는 8KB 페이지를 사용합니다. 이러한 4KB 또는 8KB 페이지에는 다른 페이지 또는 B+트리에 저장되는 실제 데이터에 대한 포인터가 포함됩니다. 포인터와 데이터 페이지는 파일 내에 혼합되어 있습니다.

가능한 경우 성능을 향상시키기 위해 페이지는 메모리 버퍼에서 최대한 길게 캐시됩니다. 그러면 디스크를 검색할 필요성이 줄어듭니다. 각 페이지는 40바이트 페이지 헤더로 시작하며, 이 헤더에는 다음 값이 포함됩니다.

• pgnoThis   이 값은 페이지의 페이지 번호를 나타냅니다.

• DbtimeDirtied   이 값은 페이지가 마지막으로 수정된 Dbtime을 나타냅니다.

• pgnoPrev   이 값은 리프에서 인접한 왼쪽 페이지의 페이지 번호를 나타냅니다.

• pgnoNext   이 값은 리프에서 인접한 오른쪽 페이지의 페이지 번호를 나타냅니다.

• ObjidFDP   이 값은 데이터베이스의 특수 페이지 개체 ID를 나타내며, FDP(Father of the Data Page)라고 합니다. FPD는 해당 페이지가 속한 B+트리를 나타내며, FDP 페이지는 복구 중에 사용됩니다.

• cbFree   이 값은 페이지에서 사용할 수 있는 바이트 수를 나타냅니다.

• cbUncommittedFree   이 값은 커밋되지 않은 사용 가능한 바이트 수(사용 가능하지만 롤백에 의해 확보할 수 있는 바이트)를 나타냅니다.

• ibMicFree   이 값은 페이지 맨 위에서 사용 가능한 다음 바이트의 페이지 오프셋을 나타냅니다.

ECC 체크섬

ECC(오류 수정 코드) 체크섬을 사용하면 .edb 파일의 데이터베이스 페이지에서 단일 비트 오류를 수정할 수 있습니다.

이 체크섬은 두 개의 32비트 체크섬으로 구성됩니다. 첫 번째 체크섬은 계산 시 페이지 번호를 시드로 사용하는 XOR 체크섬이고, 두 번째 체크섬은 페이지에서 단일 비트 오류를 수정할 수 있도록 하는 ECC 체크섬입니다.

데이터베이스 일관성 및 -1018 오류

페이지를 읽을 때 ESE는 페이지에 최신 체크섬 형식이 있는지를 확인하기 위해 페이지의 플래그를 검사합니다. 그런 다음 적절한 체크섬을 계산합니다. 체크섬이 현재 형식의 체크섬과 일치하지 않으면 ESE가 오류 수정을 시도합니다. 오류가 자동으로 수정되지 않으면 Exchange에서 -1018 오류를 보고합니다.

Exchange 저장소는 다음 작업 중 하나를 수행하는 경우 -1018 오류를 자체적으로 생성할 수도 있습니다.

• 잘못된 체크섬이 있는 페이지를 구성합니다.

• 페이지는 올바르게 구성하지만 운영 체제가 잘못된 위치에 파일을 쓰도록 합니다.

시스템 관리자가 -1018 오류를 발견하거나 서버에 대해 진단 하드웨어 테스트를 실행하여 문제가 보고되지 않으면 하드웨어가 초기 분석을 통과했으므로 문제의 원인이 Exchange에 있는 것으로 볼 수도 있습니다.

Microsoft 또는 하드웨어 공급업체의 추가 조사에 의해 하드웨어, 펌웨어 또는 장치 드라이버에서 실제로 데이터베이스 파일을 손상시킬 수 있는 미세한 문제가 발견된 경우도 많았습니다.

일반적인 진단 테스트로는 다양한 원인에 의해 발생하는 일시적인 오류를 모두 감지하지 못할 수 있으며, 펌웨어 또는 드라이버 소프트웨어의 문제는 진단 프로그램의 기능을 넘어서는 것일 수 있습니다. 그러므로 진단 테스트를 수행해도 실행 시간이 길거나 로드가 복잡하면 적절하게 시뮬레이트할 수 없는 경우도 있습니다. 또한 진단 모니터링 또는 디버그 로깅을 추가하면 이러한 문제가 다시 발생하지 않도록 시스템을 변경할 수 있습니다.

체크섬을 생성하고 데이터베이스 파일에 페이지를 쓰는 간편하고 안정적인 Exchange 메커니즘을 사용하면 -1018 오류가 Exchange가 아닌 다른 항목에 의해 발생했을 수 있음을 확인할 수 있습니다. 체크섬 및 잘못된 페이지 감지 메커니즘은 간편하고 안정적이며, 데이터베이스 버전 간에 데이터베이스 페이지 형식 변경을 적용하기 위한 사소한 변경 내용 이외에는 첫 Exchange 릴리스 이래로 기본적으로 동일하게 유지되어 왔습니다.

페이지 번호 자체를 포함하여 다른 모든 데이터를 페이지에 쓰고 나면 디스크에 쓸 페이지에 대해 체크섬이 생성됩니다. Exchange는 페이지에 체크섬을 추가한 후에 Microsoft Windows Server 운영 체제가 표준 게시 Windows Server API를 사용하여 페이지를 디스크에 쓰도록 지시합니다.

체크섬은 페이지에 대해 올바르게 생성되지만 페이지를 하드 디스크의 잘못된 위치에 쓸 수도 있습니다. 이는 "비트 전환(bit flip)" 등의 일시적인 메모리 오류에 의해 발생할 수 있습니다. 예를 들어 Exchange가 70페이지의 새 버전을 구성하는 경우 해당 페이지 자체에는 오류가 발생하지 않지만 디스크 컨트롤러 또는 운영 체제에서 사용하는 페이지 번호 복사본이 임의로 변경됩니다. 이 문제는 불안정한 메모리 셀로 인해 70(이진 10000110)이 6(이진 000110)으로 변경된 경우에 발생할 수 있습니다. 즉, 페이지의 체크섬은 올바른 상태이지만 데이터베이스에서 페이지의 위치가 잘못되는 것입니다. Exchange는 논리 페이지 번호가 실제 페이지 위치와 일치하지 않음을 감지하면 페이지에 대해 -1018 오류를 보고합니다.

Exchange에 의해 발생하는 또 다른 유형의 페이지 번호 매기기 오류는 Exchange가 페이지 자체에 잘못된 페이지 번호를 쓰는 경우에 발생할 수 있습니다. 그러나 이는 -1018 오류가 아닌 다른 오류를 발생시킵니다. Exchange가 70페이지에 71을 쓰고 페이지에 대해 체크섬을 올바르게 수행하는 경우 해당 페이지는 71 위치에 쓰여지고 페이지 번호와 체크섬 테스트를 모두 통과합니다.

Exchange 데이터베이스에서 보고되는 대부분의 단일 -1018 오류는 데이터베이스를 중지시키지 않으며, 해당 -1018 오류 자체의 존재를 제외한 다른 증상을 야기시키지 않습니다. 이 페이지는 보낸 편지함이나 지운 편지함 폴더 등 자주 액세스하지 않는 폴더에 있거나, 잘 열지 않거나 아예 비어 있는 첨부 파일에 있을 수 있습니다.

단일 -1018 오류로 인해 데이터가 크게 손실되는 일은 드물지만, -1018 오류는 저장소 시스템에서 최소한 한 번은 데이터를 안정적으로 저장하지 않거나 검색하지 않았음을 나타내므로 문제가 됩니다. -1018 오류는 다시는 발생하지 않을 일시적인 오류일 수 있지만 이 오류는 보다 심각한 증상을 야기할 수 있는 문제를 나타내는 초기 경고일 가능성이 높습니다. 첫 번째 -1018 오류가 데이터베이스의 빈 페이지에서 발생했다 하더라도 다음 번에 손상될 수 있는 페이지는 알 수 없습니다. 중요한 전역 테이블이 손상되는 경우 데이터베이스가 시작되지 않을 수 있으며, 데이터베이스 복구를 부분적으로 또는 전혀 수행하지 못할 수 있습니다.

-1018 오류가 기록되면 근본적인 원인을 찾아서 제거할 때까지 데이터베이스에 대한 일시적인 오류 또는 추가적인 임의 손상 가능성을 고려하여 이에 대한 계획을 세워야 합니다.

데이터베이스 트리 균형 조정

ESE의 기본적인 기능 중 하나는 데이터베이스 트리를 항상 균형이 조정된 상태로 유지하는 것입니다. 트리의 균형을 조정하는 프로세스는 모든 페이지가 분할 또는 병합되면 완료됩니다. 다음 그림에 나와 있는 것처럼 트리의 리프 수준과 같이 트리의 루트 수준에서도 항상 동일한 수의 노드가 존재합니다. 따라서 트리의 균형이 조정됩니다.

균형이 조정된 트리

ESE 측면에서 볼 때 데이터베이스 테이블은 B+트리의 모음입니다. 즉, 각 테이블은 데이터를 포함하는 하나의 B+트리로 구성됩니다. 그러나 데이터의 여러 가지 보기를 제공하기 위해 사용되는 보조 인덱스 B+트리도 다수 있을 수 있습니다. 테이블의 열 또는 필드 범위가 B+트리에 저장하기에는 너무 넓은 경우, Long 값 트리라는 개별 B+트리로 구분됩니다.

이러한 테이블 및 관련 B+트리의 정의는 시스템 카탈로그라는 다른 B+트리에 저장됩니다. 시스템 카탈로그의 손실은 중대한 문제이므로 ESE에서는 이 B+트리의 동일한 복사본 두 개를 각 데이터베이스에 보관합니다.

분할

페이지가 거의 가득 차면 데이터의 절반 정도가 보조 페이지에 배치되고, 보조 페이지의 상위 페이지에 추가 키가 배치됩니다. 상위 페이지도 가득 찬 경우가 아니라면 이 프로세스가 수행됩니다. 이 이벤트에서 상위 페이지는 분할되며 이 페이지의 상위 페이지에 포인터가 추가됩니다. 결과적으로 루트 블록에 이르기까지 모든 포인터 페이지를 분할해야 할 수 있습니다. 루트 블록을 분할해야 하는 경우 추가 페이지 수준이 트리에 삽입됩니다. 그림으로 표현하자면 이는 트리가 높아지는 것입니다.

병합

페이지가 거의 빈 상태가 되면 인접 페이지에 병합되고 상위 페이지의 포인터가 업데이트되며, 필요한 경우 페이지가 병합됩니다. 결과적으로 루트 블록에 이르기까지 모든 포인터 페이지가 병합되면 트리가 낮아집니다. ESE는 리프(데이터)를 얻기 위해 루트 노드에서 시작하여 원하는 리프 노드에 도달할 때까지 페이지 포인터를 따라 이동합니다.

팬아웃

ESE B+트리의 트리 구조는 고도로 팬아웃되어 있습니다. 고도의 팬아웃이란 ESE가 4번(3개의 포인터 페이지 및 데이터 페이지 자체) 이하의 디스크 읽기 작업으로 50GB 테이블의 모든 데이터에 도달할 수 있다는 뜻입니다. ESE는 4KB 페이지당 200개가 넘는 페이지 포인터를 저장하므로 최소 갯수의 상위/하위 수준으로 트리를 사용할 수 있습니다. 이러한 트리를 얕은 트리라고도 합니다. 또한 ESE는 현재 트리의 키를 저장하므로 현재 트리의 하위 항목을 빠르게 검색할 수 있습니다. 위에 나와 있는 다이어그램은 상위/하위 수준이 3개인 트리입니다. 상위/하위 수준이 4개인 트리의 경우 더 많은 데이터를 저장할 수 있습니다.

인덱스

일반적인 B+트리는 단 한 가지의 특정 방식으로만 인덱싱됩니다. 즉, 하나의 키를 사용하며, 이 키를 사용하여 데이터를 검색해야 합니다. 예를 들어 메시지 테이블의 레코드는 MTS(메시지 전송 서비스)-ID라는 메시지의 고유 식별자에서 인덱싱됩니다. 그러나 사용자는 보다 익숙한 형식으로 순서가 지정된 메시지 테이블에서 데이터를 보고자 합니다.

인덱스(구체적으로는 보조 인덱스)를 사용하여 데이터를 검색합니다. 각 보조 인덱스는 선택한 보조 키를 기본 키에 매핑하는 다른 B+트리입니다. 이러한 구조를 사용하므로 B+트리는 인덱싱되는 데이터에 비해 크기가 작습니다.

보조 인덱스를 사용하는 방법을 이해하기 위해 사용자가 메시징 폴더에서 메시지가 표시되는 방식을 변경하면 발생하는 현상을 예로 들어 보겠습니다. Outlook에서 메일을 받은 시간이 아닌 제목별로 보기가 정렬되도록 폴더 보기를 변경하면 Outlook은 저장소와 ESE가 메시지 폴더 테이블에 대해 새 보조 인덱스를 만들도록 합니다.

크기가 큰 폴더에 대해 처음으로 보기를 변경하는 경우 작업이 지연될 수 있습니다. 이때 서버를 자세히 살펴보면 디스크 활동에서 작은 돌출 부분이 보일 것입니다. 해당 보기로 다시 전환하면 인덱스는 이미 만들어져 있으며 응답 속도가 훨씬 빨라집니다.

Microsoft Exchange Information Store 서비스의 보조 인덱스 B+트리 수명은 8일입니다. 이 트리를 사용하지 않으면 Microsoft Exchange Information Store 서비스가 백그라운드 작업으로 트리를 삭제합니다.

Long 값

ESE의 열이나 레코드는 데이터 B+트리의 페이지를 포함할 수 없습니다. 여기에는 페이지의 4KB 경계를 넘는 값(예: 메시지의 본문인 PR_BODY)이 있기 때문입니다. 이러한 값을 LV(Long 값)라고 합니다. 테이블의 Long 값 B+트리는 이러한 큰 값을 저장하는 데 사용합니다.

ESE 테이블에 입력된 데이터가 데이터 B+트리에 넣기에는 너무 큰 경우에는 4KB 크기의 페이지로 구분되어 테이블의 개별 Long 값 B+트리에 저장됩니다. 데이터 B+트리의 레코드에는 Long 값에 대한 포인터가 포함됩니다. 이 포인터는 LID(Long 값 ID)라고 하며 레코드에 LID 256에 대한 포인터가 있음을 뜻합니다.

레코드 형식

B+트리의 모음은 테이블을 나타내며 테이블은 행의 모음입니다. 행은 레코드라고도 합니다. 레코드는 많은 열로 구성됩니다. 레코드의 최대 크기, 즉, 단일 레코드에 나타날 수 있는 열 수는 데이터베이스 페이지 크기에서 헤더 크기를 뺀 값에 의해 결정됩니다. ESE의 페이지 크기는 4KB이므로 최대 레코드 크기는 약 4,050바이트(4,096바이트에서 페이지 헤더의 크기를 뺀 값)입니다.

열 데이터 형식

각 열 정의에는 열에 저장하는 데이터 형식을 지정해야 합니다. ESE에서는 다음 표에 설명된 데이터 형식을 지원합니다.

Extensible Storage Engine 열 데이터 형식

열 데이터 형식은 두 범주 중 하나에 속하는데 첫 번째 범주는 고정 및 가변 열이고 두 번째 범주는 태그가 지정된 열입니다. 각 열은 16바이트의 FIELD 구조와 열 이름 크기로 정의됩니다.

ESE 데이터베이스에서 만드는 테이블은 FIELD 구조 배열을 사용하여 정의됩니다. 이 배열은 테이블의 개별 열을 식별합니다. 이 배열 내에서 각 열은 열 ID라는 인덱스 값을 사용하여 표시됩니다. 이는 array[0], array[1] 등과 같이 ID로 배열 구성원을 참조할 수 있는 일반적인 배열과 비슷합니다. ID를 사용하면 열에 빠르게 액세스할 수 있지만 열 이름을 사용하여 검색을 수행하면 FIELD 구조 배열을 통해 선형 검색을 수행해야 합니다.

고정 및 가변 열

고정 열에는 고정된 데이터 길이가 포함됩니다. 각 레코드는 값을 정의하지 않는 경우에도 정의된 레코드 공간을 차지합니다. 데이터 형식 ID 1에서 10까지를 고정 열로 정의할 수 있습니다. 각 테이블에는 최대 126개의 고정 열(열 ID 1-127)을 정의할 수 있습니다.

가변 열에는 최대 256바이트의 데이터가 포함될 수 있습니다. 오프셋 배열은 가변 열 집합이 가장 높은 레코드에 저장됩니다. 각 열에는 2바이트가 필요합니다. 데이터 형식 ID 10, 11을 가변 열로 정의할 수 있습니다. 각 테이블에는 최대 127개의 가변 열(열 ID 128-256)을 정의할 수 있습니다.

태그가 지정된 열

ESE는 단일 레코드에서 거의 나타나지 않거나 여러 번 나타나는 열을 태그가 지정된 열로 정의합니다. 정의되지 않은 태그가 지정된 열은 공간 오버헤드를 발생시키지 않습니다. 태그가 지정된 열은 동일한 레코드에서 반복해서 나타날 수 있습니다. 보조 인덱스에서 태그가 지정된 열이 나타나는 경우 인덱스는 해당 열의 개별 항목을 참조합니다.

태그가 지정된 열에는 데이터가 크기 제한 없이 가변 길이로 포함될 수 있습니다. 열 ID 및 길이가 데이터와 함께 저장됩니다. 모든 데이터 형식을 태그가 지정된 열로 정의할 수 있습니다. 각 테이블에 최대 64,993개의 태그가 지정된 열을 정의할 수 있습니다.