Sử dụng Sql Server Change Data Capture với lược đồ thay đổi thường xuyên

Chúng tôi đang xem xét cho phép Sql Server Change Data Capture cho một hệ thống con mới mà chúng tôi đang xây dựng.

Đó không thực sự là vì chúng tôi cần nó, nhưng chúng tôi đang bị thúc đẩy để có một truy nguyên lịch sử hoàn chỉnh, và CDC sẽ giải quyết tốt yêu cầu này với nỗ lực tối thiểu trên các bộ phận của chúng tôi.

Chúng tôi đang theo một quy trình phát triển nhanh, trong trường hợp này có nghĩa là chúng tôi thường xuyên thay đổi lược đồ cơ sở dữ liệu, ví dụ: thêm các cột mới, di chuyển dữ liệu sang các cột khác, v.v.

Chúng tôi đã thực hiện một thử nghiệm nhỏ trong đó chúng tôi đã tạo một bảng, bật CDC cho bảng đó và sau đó thêm một cột mới vào bảng. Thay đổi đối với cột mới không được đăng ký trong bảng CDC.

Có một cơ chế để cập nhật bảng CDC lên lược đồ mới và có cách thực hành tốt nhất nào về cách bạn xử lý dữ liệu bị bắt khi di chuyển lược đồ cơ sở dữ liệu không?

Gần đây chúng tôi cũng đã bắt đầu nhìn vào CDC. Tôi không phải là một chuyên gia về chủ đề này, nhưng tôi nghĩ rằng tôi có một số câu trả lời cho câu hỏi của bạn.

Đối với hầu hết các phần, CDC sẽ giúp bạn đạt được mục tiêu về một lịch sử hoàn toàn có thể theo dõi, nhưng tôi không nghĩ rằng nó sẽ đưa bạn đến đó.

Trước hết:

chúng tôi thường xuyên thay đổi lược đồ cơ sở dữ liệu ... Có cơ chế cập nhật bảng CDC sang lược đồ mới không

Và đây là nơi tôi nghĩ CDC sẽ làm bạn thất vọng. Các tài liệu MSDN dưới phần "Hiểu Change Tracking trên cao" là khá rõ ràng rằng nó sẽ không theo dõi những thay đổi schema cho bạn. Ví dụ Alter Table Add Column: với :

Nếu một cột mới được thêm vào bảng theo dõi thay đổi, việc thêm cột không được theo dõi. Chỉ các bản cập nhật và thay đổi được thực hiện cho cột mới được theo dõi.

Drop Column phức tạp hơn một chút

Tuy nhiên, bạn nên sử dụng các tập lệnh DB để thay đổi lược đồ của mình để bạn không nhất thiết phải dựa vào CDC ở đây. Điều đó cho phép bạn có sự thống nhất giữa các lược đồ QA và Sản xuất. Và thay đổi thành QA nên được thực hiện bằng tập lệnh để có thể áp dụng chính xác các thay đổi tương tự cho Prod. Không quá khó để trích xuất các thay đổi lược đồ từ các tập lệnh đó. Điều này có thể có nghĩa là thứ nguyên "thời gian" trong lịch sử của bạn được điều khiển theo phiên bản thay vì thời gian thực tế, nhưng kết quả cuối cùng sẽ giống nhau.

Nếu bạn chưa có, hãy tạo một bảng để theo dõi phiên bản lược đồ cơ sở dữ liệu của bạn. Và sau đó đặt bảng phiên bản lược đồ cơ sở dữ liệu đó dưới CDC để bạn có thể căn chỉnh các thay đổi vĩ mô cho lược đồ chống lại các thay đổi vi mô trong một bảng cụ thể.

Theo hiểu biết của tôi, bạn vẫn sẽ thấy dữ liệu được thêm vào (các) cột mới bất kể CDC không hiển thị thay đổi lược đồ. Và việc di chuyển dữ liệu từ bảng này sang bảng khác cũng nên được CDC chọn.

Có cách thực hành tốt nhất nào để bạn xử lý dữ liệu bị bắt khi di chuyển lược đồ cơ sở dữ liệu không?

Đối xử với nó như bạn sẽ đối xử với một cuộc kiểm toán. Bạn cần hiểu những gì bạn đang kiểm tra, tại sao bạn kiểm tra nó và bạn cần giữ thông tin đó trong bao lâu. Phạm vi và duy trì là hai lỗi lớn nhất khi nói đến một nhiệm vụ như thế này.

Các công cụ báo cáo của CDC rất khắc khổ, vì vậy bạn phải biết bối cảnh của những thay đổi. Thật quá dễ dàng để nói "theo dõi mọi thứ !" và kết quả là không có gì có thể sử dụng được. Tương tự như vậy, bạn có thể nhân đôi kích thước cơ sở dữ liệu của mình bằng cách giữ một bản sao của mọi thay đổi. Trên một chiếc bàn cao có nhiều chèn và xóa, bạn sẽ kết thúc với sự phát triển thiên văn. Bản thân điều đó không tệ, nhưng bạn cần lập ngân sách cho sự tăng trưởng đó và có phương tiện để kiểm tra tất cả dữ liệu được tạo ra.

Vì vậy, điều này giúp bạn trở lại để hiểu lý do tại sao bạn đang bị thúc đẩy để có thể truy xuất nguồn gốc hoàn toàn. Chắc chắn có những lý do hợp lệ cho yêu cầu đó. Nhưng bạn sẽ không thể cấu trúc kiểm toán cơ sở dữ liệu hiệu quả cho đến khi bạn biết lý do tại sao bạn phải đáp ứng yêu cầu đó.

Bạn có thể theo dõi thêm các cột bằng trình kích hoạt 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 > [ ; ] }

Bạn có thể sử dụng nhóm sự kiện DDL_TABLE_EVENT để kích hoạt TẠO, DROP hoặc ALTER của bảng.

Tuy nhiên, bạn có thể muốn xem SQL Server Audit , nếu bạn đang sử dụng Enterprise> 2008, vì nó có thể "kết hợp tất cả các khả năng kiểm toán vào một đặc tả kiểm toán". Liên kết msDN này có một bài viết chi tiết về nó: http://msdn.microsoft.com/en-us/l 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 ]}

Sau đó, bạn tạo Thông số kỹ thuật máy chủ hoặc cơ sở dữ liệu.

Simple-Talk có một bài viết tuyệt vời về thu thập dữ liệu thay đổi và hướng dẫn rất thông qua về CDC cũng như tài liệu MSDN giải thích các phương pháp khác nhau tùy thuộc vào yêu cầu. Nhưng cả hai đều có thể giúp bạn với các yêu cầu cụ thể của bạn.