การใช้ SQL Server เปลี่ยนการดักจับข้อมูลด้วยสคีมาที่เปลี่ยนแปลงบ่อยครั้ง


10

เรากำลังพิจารณาที่จะเปิดใช้งานการจับข้อมูลการเปลี่ยนแปลงเซิร์ฟเวอร์ SQL สำหรับระบบย่อยใหม่ที่เรากำลังสร้าง

มันไม่ได้เป็นเพราะเราต้องการมัน แต่เราถูกผลักดันให้มีการตรวจสอบย้อนหลังอย่างสมบูรณ์และ CDC จะแก้ปัญหานี้ได้อย่างดีด้วยความพยายามขั้นต่ำในส่วนของเรา

เรากำลังติดตามกระบวนการพัฒนาที่คล่องตัวซึ่งในกรณีนี้หมายความว่าเราทำการเปลี่ยนแปลงโครงสร้างฐานข้อมูลบ่อยครั้งเช่นการเพิ่มคอลัมน์ใหม่การย้ายข้อมูลไปยังคอลัมน์อื่น ๆ ฯลฯ

เราทำการทดสอบขนาดเล็กที่เราสร้างตารางเปิดใช้งาน CDC สำหรับตารางนั้นแล้วเพิ่มคอลัมน์ใหม่ลงในตาราง การเปลี่ยนแปลงในคอลัมน์ใหม่ไม่ได้ลงทะเบียนในตาราง CDC

มีกลไกในการอัปเดตตาราง CDC เป็นสคีมาใหม่หรือไม่และมีวิธีปฏิบัติที่ดีที่สุดสำหรับวิธีที่คุณจัดการกับข้อมูลที่บันทึกเมื่อทำการย้ายสคีมาฐานข้อมูลหรือไม่


คุณอาจได้รับคำตอบที่ดีขึ้น / เร็วขึ้นหากคุณโพสต์คำถามนี้ใน dba.stackexchange.com
TimG

2
@TimG การทวีคูณคำถามเป็นกำลังใจการโยกย้ายจะเป็นตัวเลือก - แต่มีความโปรดปรานและไม่สามารถโยกย้ายได้ในขณะที่ความโปรดปรานกำลังทำงานอยู่ ที่กล่าวว่าคำถามและความโปรดปรานได้รับการกล่าวถึงในห้องสนทนา dba.SE และได้รับความสนใจ

คำตอบ:


5

เราเพิ่งเริ่มดู CDC ด้วย ฉันไม่ใช่ผู้เชี่ยวชาญในเรื่องนี้ แต่ฉันคิดว่าฉันมีคำตอบสำหรับคำถามของคุณ

ส่วนใหญ่ CDC จะช่วยให้คุณบรรลุเป้าหมายของการติดตามย้อนหลังได้อย่างสมบูรณ์ แต่ฉันไม่คิดว่ามันจะพาคุณไปถึงที่นั่น

ก่อนปิด:

เราทำการเปลี่ยนแปลงสกีมาฐานข้อมูลบ่อยครั้ง ... มีกลไกในการอัพเดตตาราง CDC เป็นสคีมาใหม่หรือไม่

และนี่คือที่ฉันคิดว่า CDC จะล้มเหลวคุณ MSDN เอกสารภายใต้หัวข้อ "การทำความเข้าใจการเปลี่ยนแปลงที่ติดตามค่าใช้จ่าย" สวยชัดเจนว่ามันจะไม่ติดตามการเปลี่ยนแปลงสคีสำหรับคุณ ตัวอย่างเช่นกับAlter Table Add Column:

หากมีการเพิ่มคอลัมน์ใหม่ในตารางการติดตามการเปลี่ยนแปลงการเพิ่มคอลัมน์จะไม่ถูกติดตาม เฉพาะการอัปเดตและการเปลี่ยนแปลงที่เกิดขึ้นกับคอลัมน์ใหม่เท่านั้นที่จะถูกติดตาม

Drop Column ค่อนข้างซับซ้อนกว่าเล็กน้อย

อย่างไรก็ตามคุณควรใช้สคริปต์ DB เพื่อเปลี่ยนสคีมาของคุณดังนั้นคุณไม่จำเป็นต้องพึ่งพา CDC ที่นี่ ที่ช่วยให้คุณมีความสอดคล้องระหว่าง QA และแผนการผลิตของคุณ และการเปลี่ยนเป็น QA ควรดำเนินการโดยสคริปต์ดังนั้นการเปลี่ยนแปลงเดียวกันนี้สามารถนำไปใช้กับ Prod ได้ ไม่ควรยากเกินกว่าที่จะแยกการเปลี่ยนแปลงสคีมาออกจากสคริปต์เหล่านั้น นี่อาจหมายความว่ามิติ "เวลา" ของประวัติของคุณถูกขับเคลื่อนด้วยเวอร์ชันแทนที่จะเป็นเวลาจริง แต่ผลลัพธ์สุดท้ายจะเหมือนกัน

หากคุณยังไม่มีให้สร้างตารางเพื่อติดตามเวอร์ชันของสคีมาฐานข้อมูลของคุณ จากนั้นวางตารางเวอร์ชันสกีมาของฐานข้อมูลภายใต้ CDC เพื่อให้คุณสามารถจัดแนวการเปลี่ยนแปลงของสคีมาให้เข้ากับการเปลี่ยนแปลงด้วยกล้องจุลทรรศน์ภายในตารางเฉพาะ

เพื่อความเข้าใจของฉันคุณควรเห็นข้อมูลที่เพิ่มในคอลัมน์ใหม่โดยไม่คำนึงว่า CDC ไม่แสดงการเปลี่ยนแปลงสคีมา และการย้ายข้อมูลจากตารางหนึ่งไปอีกตารางหนึ่งก็ควรได้รับจาก CDC ด้วย

มีวิธีปฏิบัติที่ดีที่สุดสำหรับวิธีที่คุณจัดการกับข้อมูลที่ถูกจับเมื่อทำการย้ายสกีมาฐานข้อมูลหรือไม่

ปฏิบัติเช่นเดียวกับที่คุณจะปฏิบัติต่อการตรวจสอบบัญชี คุณต้องเข้าใจสิ่งที่คุณกำลังตรวจสอบสาเหตุที่คุณตรวจสอบและระยะเวลาที่คุณต้องเก็บข้อมูลนั้นไว้ ขอบเขตและการเก็บรักษาเป็นสองแมลงที่ใหญ่ที่สุดเมื่อมันมาถึงงานเช่นนี้

เครื่องมือการรายงานของ CDC นั้นเข้มงวดมากดังนั้นคุณต้องรู้บริบทของการเปลี่ยนแปลง มันง่ายเกินไปที่จะพูดว่า "ติดตามทุกอย่าง !" และจบลงด้วยสิ่งที่ใช้งานได้เป็นผล ในทำนองเดียวกันคุณสามารถเพิ่มขนาดของฐานข้อมูลของคุณเป็นสองเท่าโดยเก็บสำเนาของการเปลี่ยนแปลงทุกครั้ง บนโต๊ะปั่นสูงที่มีเม็ดมีดและจำนวนลบมากมายคุณจะพบกับการเติบโตทางดาราศาสตร์ นั่นไม่ใช่สิ่งเลวร้ายในตัวของมันเอง แต่คุณต้องใช้งบประมาณสำหรับการเติบโตนั้นและมีวิธีการตรวจสอบข้อมูลทั้งหมดที่สร้างขึ้น

ดังนั้นสิ่งนี้จะทำให้คุณกลับไปสู่ความเข้าใจว่าทำไมคุณถึงถูกผลักดันให้มีการตรวจสอบย้อนกลับอย่างสมบูรณ์ มีเหตุผลที่ถูกต้องสำหรับข้อกำหนดดังกล่าว แต่คุณจะไม่สามารถจัดโครงสร้างการตรวจสอบที่มีประสิทธิภาพของฐานข้อมูลจนกว่าคุณจะรู้ว่าทำไมคุณต้องปฏิบัติตามข้อกำหนดนั้น


1

คุณสามารถติดตามการเพิ่มคอลัมน์ด้วยทริกเกอร์ 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 ของตาราง

อย่างไรก็ตามคุณอาจต้องการตรวจสอบการตรวจสอบเซิร์ฟเวอร์ SQLถ้าคุณใช้องค์กร> 2008 เนื่องจากสามารถ "รวมความสามารถในการตรวจสอบทั้งหมดลงในข้อกำหนดการตรวจสอบ" การเชื่อมโยง 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 ]}

จากนั้นคุณสร้างเซิร์ฟเวอร์หรือฐานข้อมูลจำเพาะ


0

Simple-Talkมีบทความที่ยอดเยี่ยมเกี่ยวกับการเก็บข้อมูลการเปลี่ยนแปลงและคำแนะนำอย่างละเอียดเกี่ยวกับ CDC รวมถึงเอกสารMSDNอธิบายวิธีการต่าง ๆ ที่ขึ้นอยู่กับข้อกำหนด แต่พวกเขาทั้งสองสามารถช่วยคุณตามความต้องการเฉพาะของคุณ

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.