자주 변경되는 스키마와 함께 SQL Server 변경 데이터 캡처 사용

우리는 구축중인 새 하위 시스템에 대해 Sql Server Change Data Capture를 사용하려고합니다.

실제로 필요한 것은 아니기 때문에 완벽한 이력 추적을 요구하고 있으며 CDC는 최소한의 노력으로이 요구 사항을 훌륭하게 해결할 것입니다.

민첩한 개발 프로세스를 따르고 있습니다.이 경우 새 열 추가, 다른 열로 데이터 이동 등과 같이 데이터베이스 스키마를 자주 변경합니다.

테이블을 만들고 해당 테이블에 대해 CDC를 활성화 한 다음 테이블에 새 열을 추가하는 작은 테스트를 수행했습니다. 새 컬럼에 대한 변경 사항이 CDC 테이블에 등록되지 않았습니다.

CDC 테이블을 새 스키마로 업데이트하는 메커니즘이 있으며 데이터베이스 스키마를 마이그레이션 할 때 캡처 된 데이터를 처리하는 방법에 대한 모범 사례가 있습니까?

우리는 또한 최근 CDC를보기 시작했습니다. 나는 그 주제에 대한 전문가는 아니지만 질문에 대한 답변이 있다고 생각합니다.

대부분의 경우 CDC는 당신이 완전히 추적 가능한 역사의 목표를 달성하는 데 도움 을 줄 것입니다. 그러나 그것이 당신을 완전히 이끌어 낼 것이라고는 생각하지 않습니다.

우선:

우리는 자주 데이터베이스 스키마를 변경합니다 ... CDC 테이블을 새 스키마로 업데이트하는 메커니즘이 있습니까?

그리고 이것이 내가 CDC가 당신을 망칠 것이라고 생각하는 곳입니다. "변경 내용 추적 오버 헤드 이해"섹션에 있는 MSDN 설명서 는 스키마 변경 사항을 추적하지 않는다는 것을 잘 알고 있습니다. 예를 들면 다음과 Alter Table Add Column같습니다.

새 열이 변경 추적 테이블에 추가되면 열 추가가 추적되지 않습니다. 새 열에 대한 업데이트 및 변경 사항 만 추적됩니다.

Drop Column 조금 더 복잡합니다.

그러나 DB 스크립트를 사용하여 스키마를 변경해야하므로 여기에서 CDC에 의존 할 필요는 없습니다. 이를 통해 QA와 프로덕션 스키마간에 일관성을 유지할 수 있습니다. 그리고 QA 로의 변경은 스크립트에 의해 수행되어야하므로 동일한 변경 사항이 Prod에 적용될 수 있습니다. 해당 스크립트에서 스키마 변경 사항을 추출하는 것은 너무 어렵지 않습니다. 이것은 역사의 "시간"차원이 실제 시간 대신 버전에 의해 결정된다는 것을 의미하지만 최종 결과는 동일합니다.

아직없는 경우 테이블을 만들어 데이터베이스 스키마의 버전을 추적하십시오. 그런 다음 해당 데이터베이스 스키마 버전 테이블을 CDC 아래에 배치하여 특정 테이블 내의 미시적 변경에 대해 거시적 변경을 스키마에 맞출 수 있습니다.

내 이해에는 스키마 변경을 표시하지 않는 CDC에 관계없이 새 열에 추가 된 데이터가 여전히 표시되어야합니다. 또한 테이블에서 테이블로의 데이터 마이그레이션도 CDC에서 선택해야합니다.

데이터베이스 스키마를 마이그레이션 할 때 캡처 된 데이터를 처리하는 방법에 대한 모범 사례가 있습니까?

감사를 처리하는 것처럼 처리하십시오. 무엇을 검사하고 있는지, 왜 검사하고 있는지, 정보를 얼마나 오래 보관해야하는지 이해해야합니다. 범위 와 보존 은 이와 같은 작업에서 가장 큰 두 가지 버그입니다.

CDC의보고 도구는 이해하기 쉬우므로 변경 내용을 알아야합니다. " 모두 추적하기"라고 말하기가 너무 쉽습니다 . 결과적으로 사용할 수있는 것은 없습니다. 마찬가지로 모든 변경 사항의 복사본을 유지하여 데이터베이스 크기를 두 배로 늘릴 수 있습니다. 많은 인서트 및 삭제가있는 높은 이탈 테이블에서 천문학적 성장으로 이어집니다. 그것은 그 자체로는 나쁘지는 않지만 그 성장을 위해 예산을 책정하고 생성 된 모든 데이터를 조사 할 수단이 필요합니다.

따라서 이로 인해 완전한 추적 성을 확보해야하는 이유를 이해할 수 있습니다. 그 요구에 대한 정당한 이유가 있습니다. 그러나 해당 요구 사항을 충족해야하는 이유를 알 때까지는 데이터베이스에 대한 효과적인 감사를 구성 할 수 없습니다.

DDL 트리거를 사용하여 열 추가를 추적 할 수 있습니다.

CREATE TRIGGER trigger_name
ON { ALL SERVER | DATABASE }
[ WITH <ddl_trigger_option> [ ,...n ] ]
{ FOR | AFTER } { event_type | event_group } [ ,...n ]
AS { sql_statement [ ; ] [ ,...n ] |
EXTERNAL NAME < method specifier > [ ; ] }

이벤트 그룹 DDL_TABLE_EVENTS를 사용하여 테이블의 CREATE, DROP 또는 ALTER를 실행할 수 있습니다.

그러나 Enterprise> 2008을 사용하는 경우 "모든 감사 기능을 감사 사양에 결합 할 수 있으므로" SQL Server Audit을 살펴볼 수 있습니다. 이 msdn 링크에는 http://msdn.microsoft.com/en-us/library/dd392015(v=sql.100).aspx 에 대한 자세한 기사가 있습니다 .

CREATE SERVER AUDIT audit_name
TO { [ FILE (<file_options> [, ...n]) ] |
APPLICATION_LOG | SECURITY_LOG }
[ WITH ( <audit_options> [, ...n] ) ] }[ ; ]

<file_options>::=
{FILEPATH = 'os_file_path'
[, MAXSIZE = { max_size { MB | GB | TB } | UNLIMITED } ]
[, MAX_ROLLOVER_FILES = integer ]
[, RESERVE_DISK_SPACE = { ON | OFF } ] }

<audit_options>::=
{ [ QUEUE_DELAY = integer ]
[, ON_FAILURE = { CONTINUE | SHUTDOWN } ]
[, AUDIT_GUID = uniqueidentifier ]}

그런 다음 서버 또는 데이터베이스 사양을 만듭니다.

Simple-Talk 에는 변경 데이터 캡처에 대한 훌륭한 기사와 CDC에 대한 매우 유용한 안내서와 MSDN 설명서가 요구 사항에 따라 다양한 방법을 설명합니다. 그러나 두 가지 모두 특정 요구 사항에 도움이 될 수 있습니다.