SQL Server 2008

엔터프라이즈 데이터베이스의 변경 내용 추적

Paul S. Randal

한 눈에 보기:

• 변경 내용 추적의 필요성
• SQL Server 2005의 변경 내용 추적
• SQL Server 2008의 변경 내용 추적
• SQL Server 2008의 변경 데이터 캡처

목차

SQL Server 2005에서 변경 내용을 추적하는 방법
SQL Server 2008에서 간편하게 변경 내용을 추적하는 방법
변경 데이터 캡처의 작동 원리
변경 내용 추적의 작동 원리
요약

개발자들이 SQL Server에서 겪는 한 가지 어려운 문제는 데이터베이스에서 어떤 데이터가 변경되었는지를 추적하는 것입니다. 이보다 훨씬 더 큰 과제는 작업 성능에 크게 영향을 주지 않으며 생성, 구현 및 관리가 어렵지 않은 간단한 솔루션을 설계하는 것이지요. 왜 모두 변경 내용을 추적하느라 진땀을 뺄까요? 변경 내용 추적이 정말 그럴 만한 가치가 있는 것일까요? 가장 많이 인용되는 두 가지 예는 데이터 웨어하우스 업데이트 지원과 간헐적으로 연결되는 이종 시스템의 동기화 지원입니다.

데이터 웨어하우스는 일반적으로 OLTP(온라인 트랜잭션 처리) 데이터베이스에 일부 테이블을 표현하지만 테이블 스키마는 실제로 상당히 다를 수 있습니다. 이는 곧 OLTP 데이터베이스의 데이터를 데이터 웨어하우스로 옮기는 ETL(추출, 변환, 로드) 프로세스가 필요하다는 뜻이지요.

이를 위해 세 가지 가능성을 생각해 볼 수 있습니다. 첫째는 전체 데이터 웨어하우스를 정기적으로 새로 고치는 것입니다. 이는 대규모 데이터 볼륨에 확실히 실용적이며, 또한 데이터 웨어하우스 업데이트가 지속적으로 제공되지 않는다는 의미이기도 합니다. 두 번째 방법은 OLTP 데이터베이스의 파티션 구성표를 사용하여 이전의 ETL 프로세스보다 최신인 데이터에 대해서만 ETL 프로세스를 실행하도록 허용하는 것입니다. 이 방법은 데이터 업데이트나 삭제에는 효과가 없고 데이터 삽입에만 효과가 있으며 파티션 경계 정의 및 파티션 전환을 관리하기 위한 복잡한 메커니즘이 필요합니다. 세 번째 방법은 OLTP 데이터의 변경 내용을 추적하고 변경된 데이터만 사용하여 ETL 프로세스를 수행하는 것입니다. 이는 데이터 볼륨 측면에서 가장 효율적인 방법입니다.

오늘날의 비즈니스 환경에서 모바일 장치는 유비쿼터스 환경에 있으므로 간헐적으로 연결되는 시스템을 처리하는 것은 필수입니다. 데이터베이스 시스템 측면에서는 자주 연결되지 않는 장치에서 데이터 저장소를 효율적으로 업데이트하는 방법이 문제라고 할 수 있습니다. 특히 데이터 저장소 자체가 작고 구성표가 주 데이터베이스와 근본적으로 다를 경우에는 더욱 그렇습니다.

대량의 제품 카탈로그 중 일부를 담당하고 있는 모바일 제품 판매 사원을 생각해 보십시오. 그녀는 매일 밤 휴대 장치를 주 데이터베이스에 연결하여 휴대 장치의 저장소에 맞게 간소화된 제품 카탈로그 일부분에 대한 모든 변경 내용이 담긴 최신 데이터를 다운로드합니다. 데이터 전송 과정은 가능한 한 효율적이어야 합니다.

이제 데이터베이스 시스템이 장치에 다운로드할 제품 카탈로그의 해당 부분 전체를 준비하면 장치가 이를 다운로드하도록 할 수 있습니다. 다시 말해 데이터가 변경되지 않더라도 장치가 연결될 때마다 모든 데이터가 다운로드됩니다. 이는 상당히 비효율적인 방식에 틀림 없습니다.

다른 방법은 데이터베이스 시스템이 제품 카탈로그의 해당 부분에 대한 변경 내용을 추적하도록 하는 것입니다. 그러면 휴대 장치가 연결될 때 마지막 연결 후에 변경된 데이터를 요청합니다. 이 솔루션에서 데이터베이스 시스템은 데이터의 하위 집합을 준비하기만 하면 되므로 최대한 효율적으로 최신 데이터를 다운로드할 수 있습니다.

변경 내용을 추적하는 또 다른 이유는 요즘 들어 중요성이 부각되고 있는 감사 기능을 지원하기 위해서입니다. 감사 기능은 데이터의 변경 내용뿐만 아니라 변경된 시간과 변경한 사용자도 추적합니다. 전체 감사 추적의 지속 가능성, 보안 및 정확성에 대한 엄격한 제약 조건을 사용하면 감사 기능을 한 차원 높일 수 있습니다.

SQL Server 2008에서 데이터 변경 내용을 추적하기 위해 설계된 기술은 감사 기능을 지원하기 위해 만들어진 것은 아니지만 SQL Server 2008은 감사를 위해 특별히 설계된 SQL Server Audit라고 하는 새로운 기능을 제공합니다. 자세한 내용은 2008년 4월 호 TechNet Magazine에서 Rick Byham의 기사 "SQL Server 2008: 보안"(technet.microsoft.com/magazine/cc434691)을 참조하십시오.

아시다시피 데이터의 변경 내용을 추적하는 데는 여러 가지 분명한 이유가 있습니다. 그렇다면 이제 중요한 문제는 추적을 가장 잘 수행할 수 있는 방법에 달려 있습니다.

SQL Server 2005에서 변경 내용을 추적하는 방법

SQL Server 2005(및 이전 버전의 SQL Server)에는 미리 준비된 간단한 솔루션이 없습니다. 그래서 이러한 플랫폼에서 개발자들은 보통 타임스탬프 열, DML(데이터 조작 언어) 트리거 및 추가 테이블을 포함하는 응용 프로그램용 사용자 지정 솔루션을 만들어야 했습니다. 이러한 솔루션들은 그러나 여러 가지 잠재적 문제를 내포하고 있습니다. 예를 들면 다음과 같습니다.

• 타임스탬프 열의 추가는 테이블 스키마의 변경을 유발합니다(저장 프로시저와 다른 코드에 도미노 효과가 발생할 수 있음).
• DML 트리거는 암시적으로 DML을 포함하고 있고 해당 트리거를 실행하는 트랜잭션의 일부이므로 실행 시간 때문에 트랜잭션의 길이가 늘어납니다. 트리거가 복잡해질수록 실행 시간이 오래 걸리고 따라서 작업 성능에 대한 부정적인 영향도 높아집니다. 변경 내용을 추적하는 데 사용되는 DML 트리거는 삽입된 테이블과 삭제된 테이블을 처리하여 모든 변경 내용을 수집한 다음 다른 추적 테이블에 삽입해야 합니다.
• 추적 테이블이 제어할 수 없게 길어지면 에이전트 작업과 같은 것을 만들어 오래된 데이터를 정기적으로 제거해야 할 수 있으므로 이를 방지할 수 있도록 특정한 방법으로 관리해야 합니다.

SQL Server 2008에서 간편하게 변경 내용을 추적하는 방법

SQL Server 2008은 데이터 변경 내용을 훨씬 더 간편하게 추적할 수 있는 변경 내용 추적과 변경 데이터 캡처라는 새로운 기술을 도입했습니다. 두 기능은 변경된 데이터를 추적하고(삽입, 업데이트 또는 삭제 작업을 사용하여 데이터가 어떻게 변경되었는지도 정확하게 추적함) 사용자 지정 솔루션의 필요성을 없애 줍니다. 이러한 유사점과는 별개로 이 두 기능의 메커니즘과 정확한 추적 대상은 사실 상당히 다릅니다.

변경 데이터 캡처는 열 값 자체를 포함하여 테이블(또는 테이블의 정의된 열 집합)에 발생한 모든 변경 내용을 추적하는 비동기 메커니즘을 사용합니다. 이는 앞서 설명한 데이터 웨어하우스 ETL 프로세스와 같은 시나리오에서 사용하도록 설계되었습니다.

그림 1에서는 시분할로 소비되고 있는 변경 데이터를 보여 줍니다. 변경 데이터 캡처 메커니즘은 변경된 데이터를 테이블 집합으로 추출하는데, 테이블의 맨 위에는 가장 최근의 변경 내용이 옵니다. 그러면 ETL 프로세스가 변경 데이터를 보관하는 테이블을 쿼리하여 지정된 기간 내에 발생한 모든 변경 내용을 확인할 수 있습니다. 이 메커니즘을 통해 ETL 프로세스는 각 일괄 처리에서 소비되어야 하는 데이터의 양을 제한할 수 있습니다.

그림 1 시분할로 소비되고 있는 시간별 변경 데이터(더 크게 보려면 이미지를 클릭하십시오.)

반면에 변경 내용 추적은 테이블에서 변경된 특정 행(그리고 필요에 따라 변경된 열 목록도)만 추적하는 동기 메커니즘을 사용합니다. 이는 앞서 설명한 간헐적으로 연결되는 시스템 시나리오와 같은 문제를 해결하도록 설계되었습니다. 그림 2에서는 이 방법을 보여 줍니다.

그림 2 변경 데이터 추적을 사용하는 간헐적으로 연결되는 시스템(더 크게 보려면 이미지를 클릭하십시오.)

두 기능으로 인해 I/O와 로깅 작업이 늘어나지만 사용자 지정 솔루션의 경우에도 변경 데이터를 어딘가에 저장해야 하므로 사정은 마찬가지입니다. 이 두 기능과 사용자 지정 솔루션의 잠재적인 차이점은 변경 데이터를 저장하는 데 사용되는 테이블이 추적 대상 테이블과 같은 데이터베이스에 있어야 한다는 것입니다. 따라서 모든 변경 데이터가 백업에 포함되며 로그 전달 또는 데이터베이스 미러링을 사용하여 네트워크를 통해 전송될 수 있습니다.

개발 측면에서 이러한 두 기능은 변경 내용 추적의 많은 복잡성을 없애 줍니다. 두 기능 모두 테이블 스키마 변경 내용 또는 트리거가 필요하지 않습니다. 두 기능은 구성 가능한 자동 정리 프로세스를 제공하고, 트랜잭션 커밋 시간별로 변경 내용을 정렬하며, 변경 정보를 검색하는 기본 제공 기능을 제공합니다.

관리 측면에서 각 기능마다 나름대로의 장단점이 있습니다. 모든 기술이 그렇듯이 이러한 기능을 사용하는 솔루션을 개발하고 배포하기 전에 반드시 알고 있어야 하는 정보가 많이 있습니다. 이 기사의 나머지 부분에서는 각 기능을 간략히 살펴보면서 이 두 기능의 작동 원리에 대해 살펴보고 프로덕션 환경에서 사용하기 전에 실제로 고려해야 할 사항을 알아보겠습니다.

변경 데이터 캡처의 작동 원리

변경 데이터 캡처는 추적 테이블을 변경하는 트랜잭션의 일부로서 아무런 작업도 하지 않습니다. 대신 일반적으로 삽입, 업데이트 및 삭제 작업이 트랜잭션 로그에 기록되고 로그에서 정기적으로 수집됩니다. 수집 작업은 SQL 에이전트 로그 판독기 작업을 통해 수행되며 수집된 작업은 변경 테이블이라 불리는 별도의 테이블에 저장됩니다. 나중에 필요할 때 변경 테이블을 쿼리하여 두 기능 중 하나를 사용하는 변경 데이터를 가져올 수 있습니다. 변경 테이블과 두 기능을 합쳐 캡처 인스턴스라고 합니다. 그림 3에는 변경 데이터 캡처를 사용하여 데이터 웨어하우스 ETL 프로세스를 구동하는 데이터의 흐름이 나와 있습니다.

변경 데이터 캡처를 사용하려면 두 단계가 필요합니다. 먼저 sysadmin 고정 서버 역할의 멤버가 sys.sp_cdc_enable_db를 사용하는 데이터베이스에 대해 변경 데이터 캡처를 설정해야 합니다. 그런 다음 db_owner 고정 서버 역할의 멤버가 sys.sp_cdc_enable_db를 사용하는 특정 테이블에 대해 변경 데이터 캡처를 설정해야 합니다. 이러한 보안이 필요한 이유는 변경 데이터 캡처가 잘못 구성될 경우 디스크 사용량이 높아질 수 있기 때문입니다. 이렇게 되면 테이블 소유자가 이 기능을 사용할 수 없고 데이터베이스 관리자가 과도한 디스크 사용량 때문에 놀라게 될 것은 분명합니다.

변경 데이터 캡처를 사용하도록 데이터베이스를 설정하면 새로운 스키마(cdc라고 함), 일부 메타데이터 테이블 및 DDL(데이터 정의 언어) 이벤트를 캡처하기 위한 트리거와 같은 몇 가지 요소가 데이터베이스가 추가됩니다. (이 트리거는 테이블의 DDL 변경 내용 목록을 확인할 수 있는 훌륭한 기능입니다.)

변경 데이터 캡처를 사용하면 변경 테이블에 대한 캡처 인스턴스와 변경 데이터를 반환하는 최대 2개의 함수를 만들 수도 있습니다. 변경 테이블 이름은 캡처 인스턴스 이름에 _CT를 붙인 것입니다. 첫 번째 함수는 항상 생성되며 변경 테이블에서 변경 데이터를 반환하는 데 사용됩니다. 두 번째 함수는 net changes를 허용하는 옵션이 지정된 경우에 생성됩니다. 따라서 첫 번째 함수가 반환하는 중간 변경 내용이 아닌 캡처된 모든 변경 내용의 최종 결과만 반환됩니다. 두 함수의 이름은 각각 fn_cdc_get_all_changes_와 fn_cdc_get_net_changes_이며 여기에 캡처 인스턴스 이름이 추가됩니다. 변경 내용 추적과 마찬가지로 이 기능도 테이블에 기본 키 또는 기타 고유 인덱스가 있어야 합니다.

변경 데이터 캡처를 설정하기 위해 데이터베이스의 첫 번째 테이블을 처리할 때는 SQL 에이전트 작업인 캡처 작업과 정리 작업이 생성될 수 있습니다. "될 수 있다"고 말한 이유는 캡처 작업이 트랜잭션 복제에서 트랜잭션을 수집하는 데 사용되는 것과 동일하기 때문입니다. 트랜잭션 복제가 이미 구성되어 있으면 정리 작업만 생성되고 기존의 로그 판독기 작업도 캡처 작업으로 사용됩니다. 로그 판독기 작업이 두 개면 로그에 경합 문제가 매우 빠르게 발생하고, 따라서 성능에도 문제가 발생하므로 이러한 점은 유용하게 작용합니다. 어느 쪽이든 변경 데이터 캡처를 사용하려면 SQL 에이전트가 실행되고 있어야 합니다.

로그 판독기 내 논리는 변경 데이터 캡처를 사용 또는 사용하지 않도록 설정할 테이블을 자동으로 처리하고 이에 따라 적절히 트랜잭션 로그에서 수집되는 것을 변경합니다. 여기서 한 가지 중요한 점은 변경 데이터 캡처가 설정되고 나면 트랜잭션 복제에서처럼 로그 판독기가 처리할 때까지 트랜잭션 로그가 잘리지 않습니다. 따라서 검사점 작업은 SIMPLE 복구 모드에서도 로그 판독기에 의해 이미 처리된 후에만 로그를 자릅니다.

또한 로깅 작업을 줄이기 위해 BULK_LOGGED 복구 모델이 사용되는 경우 변경 데이터 캡처는 인덱스 생성/삭제/재작성 작업을 제외하고 모든 것이 완전히 로깅되도록 합니다. 이러한 동작을 아직 경험해 보지 않았다면 특히 캡처 작업 기본값이 로그를 자주 처리하지 않도록 변경된 경우에 이러한 작업이 트랜잭션 로그 크기 문제를 초래할 수 있다는 사실을 알아두십시오.

기본적으로 캡처 작업은 지속적으로 실행되며 5초마다 로그를 검사하고 로그에서 최대 500개의 트랜잭션을 처리합니다. 또한 기본적으로 정리 작업은 매일 오전 2시에 실행되며 변경 테이블에서 3일이 지난 변경 데이터 항목을 모두 제거합니다. sys.sp_cdc_change_job 프로시저를 사용하면 이 설정을 변경할 수 있는데, 변경 내용을 적용하려면 sys.sp_cdc_stop_job and sys.sp_cdc_start_job을 사용하여 작업을 다시 시작해야 합니다.

로그 판독기 프로세스는 일반적으로 시스템 성능에 미치는 영향이 적지만 변경 데이터가 많고 부하가 매우 큰 OLTP 시스템에서는 로그 판독기 프로세스 하나만 추가해도 트랜잭션 로그에 경합이 발생할 수 있습니다. 실제 경합은 트랜잭션에서 로그에 데이터를 기록하고 있는 지점과 로그 판독기 프로세스에서 로그를 읽고 있는 지점 사이를 전환해야 하는 디스크 헤드 때문에 발생하게 됩니다. 이 경우 OLTP 성능에 영향을 주지 않도록 캡처 작업의 실행 빈도를 변경해야 할 수 있습니다. 그러나 이렇게 하면 성능을 위해 일반 디스크 공간이 희생되므로 캡처 작업이 처리할 때까지 로그가 계속해서 증가합니다.

정리 작업 빈도 또는 변경 데이터 보존 기간을 변경하는 경우에도 똑같은 문제가 발생합니다. 변경 테이블은 변경 데이터가 정리될 때까지 계속해서 증가합니다. 따라서 무엇을 추적하고 얼마나 보관해야 하는지에 대한 전면적인 설계 고려 사항이 생겨납니다. 여기서 고려해야 할 중요 사항은 다음과 같습니다.

• 캡처 인스턴스에 대한 필수 열 목록. 많은 열이 캡처될수록 많은 변경 데이터가 변경 테이블에 삽입됩니다.
• 변경 테이블에서 사용하는 디스크 공간의 양.
• 변경 데이터를 소비하는 프로세스가 실행되는 빈도. 한 번도 사용하지 않은 데이터는 삭제할 수 없습니다.
• 정리 프로세스가 실행되는 빈도. 변경 데이터가 너무 많이 생성되어 이를 삭제하는 정리 프로세스가 주말에만 실행되는 경우가 있을 수 있습니다. 예를 들어 트랜잭션 로그가 너무 많이 생성되는 경우가 있습니다.

테이블의 모든 변경 내용만 추적하거나 테이블에 있는 열의 하위 집합을 추적하도록 변경 데이터 캡처를 설정할 수 있습니다. 하위 집합은 일부 중요하지 않은 열이 너무 범위가 넓은 varchar 열이거나 BLOB(Binary Large Object) 열일 경우 또는 변경 테이블에서 사용하는 공간이 단시간에 방대해질 수 있는 경우에 사용하면 유용할 수 있습니다.

디스크 공간 사용 가능성의 증가를 고려했을 때 변경 데이터 캡처가 활성화되어 있는 경우 변경 테이블의 파일 그룹 위치를 설정할 수 있습니다. 이렇게 하면 기본 디스크 공간을 더욱 쉽게 관리할 수 있으며 모든 변경 데이터를 주 데이터베이스보다 저렴한 RAID 수준의 볼륨에 저장할 수 있습니다. 또한 정리 작업 설정은 모든 캡처 인스턴스에 적용되지만 개별 캡처 인스턴스는 디스크 공간이 문제가 될 때마다 언제든지 별도로 정리할 수 있습니다. 캡처 테이블에 대해 sp_spaceused를 사용하면 디스크 공간 사용량을 쉽게 모니터링할 수 있습니다.

변경 테이블에 기록되는 실제 행에는 트랜잭션에 대한 메타데이터(커밋 로그 시퀀스 번호 또는 LSN)뿐만 아니라 트랜잭션 내에서 변경이 발생한 순서, 수행된 작업, 변경된 열의 비트 마스크 및 실제 열 값도 포함되어 있습니다.

변경 데이터 캡처가 설정되어 있는 동안에는 DDL 변경에 제한이 없습니다. 그러나 열이 추가 또는 삭제되는 경우에는 수집되는 변경 데이터에 일부 영향을 줄 수 있습니다. 추적된 열이 삭제되면 캡처 인스턴스에서 모든 항목의 해당 열 값이 NULL이 됩니다. 열이 추가되면 캡처 인스턴스에서 이를 무시합니다. 다시 말해, 캡처 인스턴스의 모양은 처음 만들어질 때 설정됩니다.

열 변경이 필요할 경우 특정 테이블에 대한 또 다른 캡처 인스턴스(테이블당 최대 2개 캡처 인스턴스까지)를 만들고 변경 데이터의 소비자가 새로운 테이블 스키마로 마이그레이션하도록 허용할 수 있습니다. 그러나 이 경우 추적된 테이블에 대한 두 개의 캡처 인스턴스는 곧 디스크 공간, I/O 및 로깅의 양도 2배라는 뜻이므로 신중을 기해야 합니다.

자세히 설명하지 않아도 앞서 설명한 함수를 사용하면 변경 테이블에서 변경 내용을 가져올 수 있습니다. 함수는 시작 LSN과 종료 LSN을 받으며, 표준 시간을 LSN으로 변환할 수 있는 다른 함수도 제공됩니다. 업데이트를 검색할 때 이전 및 이후 값을 확인할지 또는 이전 값만 확인할지를 지정할 수도 있습니다. 변경 데이터 캡처를 사용하는 필자의 스크린캐스트를 www.technetmagazine.com/video에서 확인할 수 있습니다.

변경 데이터 캡처의 작동 원리

앞서 언급했듯이 변경 내용 추적은 동기 프로세스이며 변경 데이터 캡처보다 훨씬 덜 복잡합니다. 추적 대상 테이블에 있는 행을 변경하는 트랜잭션의 일부이며 행이 변경되었다는 사실이 별도의 테이블에서 추적됩니다. 이 테이블을 내부 테이블이라고 하며 이름이나 저장 위치는 제어하지 못합니다. 필자는 이것이 문제가 된다고 생각하지 않습니다. 이 테이블에는 변경 데이터 캡처에 사용되는 변경 테이블보다 적은 데이터가 있기 때문입니다. 그러나 디스크 공간 문제는 여전히 남아 있습니다. 이 문제는 나중에 설명하겠습니다.

변경 추적이 동기적으로 수행된다는 것은 추적 대상 테이블을 변경하는 각 트랜잭션 내에서 추가 처리 작업이 수행된다는 의미입니다. 성능에 미치는 영향은 테이블에 비클러스터형 인덱스가 있고 테이블이 변경될 때마다 이 인덱스를 업데이트해야하는 경우와 유사합니다. 트랜잭션 자체도 내부 sys.syscommittab 테이블의 행에 의해 커밋될 때 추적됩니다.

변경 내용 추적은 정규 ALTER DATABASE 및 ALTER TABLE 구문을 사용하여 설정 및 해제되며 테이블 수준 전 데이터베이스 수준에서 설정되어야 하는 변경 데이터 캡처와 같은 모델을 따릅니다. 작업 순서는 다음과 같습니다.

ALTER DATABASE AdventureWorks2000 SET CHANGE_TRACKING = ON
  (CHANGE_RETENTION = 2 DAYS, AUTO_CLEANUP = ON);
GO
USE AdventureWorks2000;
GO
ALTER TABLE Person.Person ENABLE CHANGE_TRACKING
  WITH (TRACK_COLUMNS_UPDATED = ON);
GO

데이터베이스 및 테이블 수준에서 변경 내용 추적을 설정하는 데 필요한 권한도 변경 데이터 캡처를 설정하는 데 필요한 권한인 테이블 소유자가 아닌 db_owner입니다. 데이터베이스 수준에서 변경 내용 추적이 설정되어 있는 경우 보관 기간을 설정할 수 있을 뿐 아니라 변경 데이터를 자동으로 정리할지 여부도 지정할 수 있습니다. 기본 보관 기간은 2일이며 최대값은 90일이고, 최소값은 1분입니다.

자동 정리도 기본적으로 설정되어 있습니다. 이러한 설정을 변경할 때는 변경 데이터 캡처에서 설명했던 것과 같이 무엇을 희생할지를 평가해야 합니다.

기본적으로 각 행에는 변경된 데이터만 캡처됩니다. 이 작업은 버전 번호(데이터베이스에 변경 내용 추적이 설정되면 버전 번호가 매겨져 작업의 순서를 지정할 수 있음) 및 변경을 수행한 작업 유형과 함께 변경된 행의 기본 키에 대한 메모를 만드는 방식으로 수행됩니다(따라서 테이블의 변경 내용을 추적하려면 해당 키에 기본 키가 있어야 함). 또한 필요한 경우 변경된 열을 추적할 수도 있습니다. 이 경우 변경된 열당 4바이트가 필요합니다.

디스크 공간 모니터링은 변경 데이터가 내부 테이블에 저장된다는 점에서 변경 내용 추적과 약간 다릅니다. 사용 중인 내부 테이블의 이름을 확인하기 위해 sys.internal_tables 시스템 카탈로그 뷰를 사용하면 됩니다.

SELECT [name] FROM sys.internal_tables
  WHERE [internal_type_desc] = 'CHANGE_TRACKING';
GO

그런 다음 sp_spaceused로 이름을 전달하면 사용 중인 디스크 공간을 알 수 있습니다.

변경 데이터 캡처와는 달리 변경 내용 추적이 설정되어 있을 때는 추적 대상 테이블에서 수행할 수 있는 DDL에 제한이 따릅니다. 가장 중요한 제한 사항은 기본 키를 어떠한 방식으로든 변경할 수 없다는 점입니다. 주목할 만한 또 다른 제한 사항은 관련된 테이블에 변경 내용 추적이 설정되어 있는 경우 ALTER TABLE SWITCH가 실패한다는 점입니다. 이는 분할된 변경 내용 추적 대상 테이블에서 교체되어 나가는 파티션 또는 분할된 테이블로 교체되어 들어오는 변경 내용 추적 대상 테이블에 대해 각각 변경 내용 추적을 자동으로 시작하거나 제거할 필요가 없기 때문일 가능성이 큽니다.

새로운 CHANGETABLES (CHANGES …) 함수를 사용하면 내부 변경 테이블에서 변경 내용을 검색할 수 있습니다. 이 함수는 변경 내용 추적 대상 테이블의 이름과 이전에 사용되었을 당시의 버전 번호를 받고 이전 시간 이후로 변경된 모든 행에 대한 정보를 반환합니다. 현재의 유효한 버전과 가장 오래된 유효한 버전을 알아낼 수 있는 다양한 함수가 있습니다. 그러면 응용 프로그램이 반환된 정보를 사용하여 변경 내용 추적 대상 테이블을 쿼리하여 실제 열 값을 가져올 수 있습니다. 이는 물론 여러 단계로 이루어진 프로세스입니다. 현재 버전을 확인하고, 이 버전을 사용하여 변경 내용 추적을 쿼리한 다음 실제 테이블을 쿼리하여 이 버전에 해당하는 열 데이터를 가져옵니다.

끊임없이 변화하는 시스템에서 변하지 않는 버전, 변경 데이터 및 실제 열 데이터가 유지되지 않는 한 일관성이 없거나 정확하지 않은 결과를 얻을 수 있습니다. 이를 방지하려면 스냅숏 격리를 사용하여 여러 단계의 프로세스를 명시적 트랜잭션에 래핑해야 합니다. 효과적인 방법이긴 하지만 잠재적인 단점이 몇 가지 있습니다. 스냅숏 격리는 작업 성능에 영향을 줄 가능성이 있으며, tempdb의 성능과 공간 사용량에 영향을 줍니다. 이에 대한 자세한 내용은 technet.microsoft.com/library/cc280358에서 확인할 수 있습니다.

요약

그림 4에 나와 있는 변경 내용 추적과 변경 데이터 비교를 통해 DBA가 신경 써야 할 주요 차이점을 쉽게 이해할 수 있을 것입니다. 이 표를 보면 변경 데이터 캡처가 변경 내용 추적보다 훨씬 더 부하가 높다는 것을 알 수 있습니다. 따라서 추적 대상 테이블에 BLOB 열이나 너무 범위가 넓은 행이 포함되어 있는 경우 추적 테이블의 크기가 단숨에 커질 수 있으므로 추적 대상을 결정할 때는 좀 더 신중해져야 합니다. 또한 로그 판독기가 로그에서 레코드를 수집할 때까지 로그가 잘리지 않으므로 트랜잭션 로그 관리 문제가 발생할 가능성도 있습니다.

그림 4 변경 내용 추적과 변경 데이터 캡처 비교

그러나 변경 내용 추적에는 고유 요구 사항이 있습니다. 예를 들어 기본 키가 필요하며, 변경 내용 추적이 설정되어 있을 경우 스냅숏 격리를 사용하는 것이 좋습니다. 스냅숏 격리는 그 자체만으로 상당한 작업 오버헤드를 가중시킬 수 있으며 tempdb를 더욱 세심하게 관리해야 합니다.

개발자와 DBA가 처리해야 할 또 다른 문제는 재해 복구입니다. 이 내용은 이 기사의 범위를 범위를 벗어나므로 자세히 다루지는 않겠지만 매우 중요한 항목이라 간단히 언급만 하고 넘어가겠습니다.

두 기능은 BACKUP 및 RESTORE와 함께 잘 작동합니다. 문제는 데이터베이스가 실질적으로 이전 상태로 복원되었을 경우에 발생합니다. 전체 응용 프로그램/시스템은 어떻게 동작할까요? 변경 내용 추적을 위해 설계된 사용자 지정 솔루션에서도 이러한 문제가 발생하므로 SQL Server 2008을 사용할 때는 여전히 이 문제를 고려해야 합니다.

언제나 그렇듯이 새로운 변경 내용 추적 기능과 관련된 설계 및 배포 프로젝트를 시작하기 전에는 제공되는 모든 문서(technet.microsoft.com/library/bb418491)와 기존의 모든 백서를 반드시 읽어 보십시오. 먼저 여기서 다루지 않은 가능한 문제가 여러분에게 적용될 수 있는지 확인해야 합니다. 또한 새로운 모니터링 SP와 DMV(동적 관리 뷰)도 자세히 알아보아야 합니다.

어쨌든 이러한 새로운 기능은 이전의 데이터 변경 내용 추적 방법보다 훨씬 더 발전된 기술입니다. 이러한 기술이 도입되었으니 여러분이 관리하는 솔루션에서 개발자들이 이러한 기능을 사용하려고 할 것은 분명합니다.

중요하게 고려해야 중요한 구성 및 관리 문제가 있지만 이 기사를 통해 여러분이 새로운 기술을 쉽게 이해하여 여기서 설명한 일부 문제를 예상하고 준비하시기를 바랍니다. 이 기사에 대한 의견이나 질문이 있으시면 Paul@SQLskills.com으로 보내 주십시오.

Paul S. Randal은 SQLskills.com의 상무이자 SQL Server MVP입니다. 1999년부터 2007년까지 Microsoft의 SQL Server 저장소 엔진 팀에서 근무한 Paul은 DBCC CHECKDB/repair for SQL Server 2005를 저술했으며 SQL Server 2008 개발 과정에서 핵심 저장소 엔진 부분을 담당했습니다. Paul은 재해 복구, 고가용성 및 데이터베이스 유지 관리 분야의 전문가이며 전 세계 각종 컨퍼런스에서도 꾸준히 의견을 발표하고 있습니다. 블로그 주소는 SQLskills.com/blogs/paul입니다.