การเพิ่มคอลัมน์ในตารางการผลิต

28

วิธีที่ดีที่สุดในการเพิ่มคอลัมน์ในตารางการผลิตขนาดใหญ่บน SQL Server 2008 R2 คืออะไร ตามหนังสือของ Microsoft ทางออนไลน์:

การเปลี่ยนแปลงที่ระบุใน ALTER TABLE จะถูกนำไปใช้งานทันที หากการเปลี่ยนแปลงนั้นต้องการการแก้ไขแถวในตาราง ALTER TABLE จะอัพเดตแถว ALTER TABLE ได้รับ schema แก้ไขการล็อกบนตารางเพื่อให้แน่ใจว่าไม่มีการอ้างอิงการเชื่อมต่ออื่น ๆ แม้แต่ข้อมูลเมตาสำหรับตารางในระหว่างการเปลี่ยนแปลงยกเว้นการดำเนินการดัชนีออนไลน์ที่ต้องใช้การล็อค SCH-M ที่สั้นมากในตอนท้าย

(http://msdn.microsoft.com/en-us/library/ms190273.aspx)

บนโต๊ะขนาดใหญ่ที่มีแถวนับล้านแถวอาจใช้เวลาสักครู่ การดับเป็นตัวเลือกเดียวหรือไม่ วิธีที่ดีที่สุดในการจัดการกับสถานการณ์เช่นนี้คืออะไร?

— SH-เบต้า
แหล่งที่มา

1

บทความล่าสุดเกี่ยวกับปัญหานี้: sqlservercentral.com/articles/Change+Tracking/74397

— 8kb

27

"มันขึ้นอยู่กับ"

หากคุณเพิ่มคอลัมน์ที่ไม่ต้องการเพิ่มข้อมูลลงในแถวก็สามารถทำได้อย่างรวดเร็ว

ตัวอย่างเช่นการเพิ่ม int หรือ char ต้องมีการเคลื่อนไหวทางกายภาพแถว การเพิ่ม varchar แบบ nullable โดยไม่มีค่าเริ่มต้นไม่ควร (ยกเว้นว่าบิตแมป NULL ต้องขยาย)

คุณต้องลองใช้สำเนาการผลิตที่ได้รับการกู้คืนเพื่อรับค่าประมาณ

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

ฉันมีการเปลี่ยนแปลงตารางแถวพันล้านตารางที่ใช้เวลาสองสามวินาทีเพื่อเพิ่มคอลัมน์ nullable

ฉันว่าจะสำรองข้อมูลก่อนหรือไม่?

— GBN
แหล่งที่มา

2

+1 ในการสำรองข้อมูล และตรวจสอบให้แน่ใจว่าคุณมีพื้นที่บันทึกเพียงพอ

— SqlACID

คุณสามารถอธิบายได้ไหมว่าทำไมการเพิ่ม int หรือ char ต้องมีการเคลื่อนไหวของแถวที่มีอยู่จริง?

— sh-beta

5

คุณหมายถึง "ไม่" ต้องการเพิ่มข้อมูลลงในแถวในบรรทัดที่สองของคุณหรือไม่

— Ben Brocka

21

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

เพิ่มคอลัมน์เป็น NULLable - ควรรวดเร็วในกรณีส่วนใหญ่
อัปเดตค่าเป็นค่าเริ่มต้น
- คุณสามารถทำสิ่งนี้ในแบตช์หากจำเป็น
- คุณสามารถใช้สิ่งนี้เพื่อใช้ตรรกะตามเงื่อนไขที่บางแถวอาจไม่ได้รับค่าเริ่มต้น
เพิ่มข้อ จำกัด ไม่ใช่ค่า null / ค่าเริ่มต้น
- สิ่งนี้จะเร็วขึ้นหากไม่มีข้อมูลใดเป็น NULL แต่ควรจะสามารถวัดได้

เห็นด้วยกับ @gbn ว่าคุณสามารถทดสอบสิ่งนี้ได้โดยการกู้คืนสำเนาของการผลิตและลองที่นั่น ... คุณจะได้รับความคิดที่ดีเกี่ยวกับเวลา (สมมติว่าฮาร์ดแวร์นั้นค่อนข้างคล้ายกัน) และคุณยังสามารถเห็นผลกระทบต่อบันทึก

— แอรอนเบอร์ทรานด์
แหล่งที่มา

เป็นบิตสุดท้าย: •add the not null/default constraintsฉันไม่แน่ใจว่าไม่มีปัญหาที่อาจเกิดขึ้นกับสิ่งนี้ ... เมื่อ MSSQL (แม้แต่ 2008R2) เปลี่ยนคอลัมน์ไม่ใช่ null ให้เป็นโมฆะถ้าคุณใส่การติดตามลงไปคุณจะเห็นว่ามันอยู่ใต้ฝาครอบจริงๆ ทำการอัปเดตเต็มรูปแบบของทุกแถวของตารางนั่นคือupdate table1 set column1 = column1ฉันถือว่ามันทำการตรวจสอบที่ไม่เป็นโมฆะในลักษณะที่งี่เง่าอย่างสมบูรณ์ ธุรกรรมนี้มีขนาดใหญ่เป็นสองเท่าของตาราง (ก่อนและหลังหน้า) ดังนั้นสำหรับตาราง DW อาจมีขนาดใหญ่มาก ก่อนหน้านี้เราต้อง bcp data ออก, ตัด, เปลี่ยนค่า null เป็น non-null จากนั้น bcp in

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

เฮ้ @ ไมค์นี่ดูเหมือนจะเป็นคำถามที่ดีมาก ๆ

— Derek Downey

4

คุณคิดว่า:

การสร้างตารางใหม่ที่มีการเปลี่ยนแปลงข้อกำหนดของตาราง
การแทรกเข้าไปในคำนิยามตารางใหม่ที่เลือกจากตารางต้นฉบับ
การเปลี่ยนชื่อตารางต้นฉบับเป็น _orig จากนั้นเปลี่ยนชื่อตารางใหม่เป็นชื่อตารางดั้งเดิม

ข้อเสียที่นี่คือคุณต้องมีพื้นที่เพียงพอในฐานข้อมูลเพื่อทำการเปลี่ยนแปลงนี้ คุณอาจต้องใช้ล็อกการอ่านบนโต๊ะเพื่อป้องกันการอ่านที่สกปรก

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

— RobPaller
แหล่งที่มา

คุณไม่ต้องการล็อกการเขียนแทนที่จะอ่านหรือไม่? เป็นเรื่องปกติที่ผู้ใช้จะเห็นข้อมูลในตารางเก่าคุณไม่ต้องการให้พวกเขาส่งการเปลี่ยนแปลงใด ๆ ที่จะถูกเขียนทับเมื่อคุณสลับบัฟเฟอร์เสร็จ

— Jon of All Trades

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

— RobPaller