การกู้คืนฐานข้อมูล SQL จากการสำรองข้อมูลจะสร้างดัชนีใหม่หรือไม่

10

การกู้คืนฐานข้อมูล SQL จากการสำรองข้อมูลจะสร้างตารางและดัชนีใหม่จากศูนย์หรือไม่ หรือมันเก็บไว้ในลำดับทางกายภาพภายในเดียวกันในเวลาของการสำรองข้อมูลหรือไม่

เรากำลังใช้ SQL 2000 กับการสำรองข้อมูลที่บีบอัด Quest Lightspeed หากนั่นสร้างความแตกต่าง

sql-server restore

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

16

คำตอบคือไม่สำหรับซอฟต์แวร์สำรองที่ใช้

การสำรองข้อมูลเป็นการดำเนินการทางกายภาพไม่ใช่การดำเนินการทางตรรกะ มันจะอ่านขอบเขตทั้งหมดที่มีหน้าที่ปันส่วน (เช่นแม้ว่าจะมีเพียงหน้าเดียวจากขอบเขต 8 หน้าที่ถูกจัดสรรก็จะสำรองข้อมูลขอบเขต 64K ทั้งหมด) และทำตามลำดับจริง

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

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

สาเหตุหลักที่ทำให้สิ่งนี้ไม่สามารถทำได้คือการย้ายหน้าไปรอบ ๆ ระหว่างการดำเนินการกู้คืนจะทำให้พอยน์เตอร์พอยน์ทรีเสียหาย หากหน้า A ชี้ไปที่หน้า B แต่หน้า A ถูกย้ายโดยกระบวนการกู้คืนหน้า B จะได้รับการปรับปรุงอย่างไรให้ชี้ไปที่หน้า A หากอัปเดตทันทีอาจถูกเขียนทับโดยกระบวนการกู้คืนที่เหลือ หากมีการปรับปรุงที่เลื่อนออกไปจะเกิดอะไรขึ้นหากกระบวนการกู้คืนกู้คืนบันทึกธุรกรรมบางอย่างที่ลบหน้า A หรือหน้า B มันไม่สามารถทำได้

Bottom line - การสำรองและกู้คืนเป็นการดำเนินการทางกายภาพที่ไม่เปลี่ยนแปลงข้อมูล

หวังว่านี่จะช่วยได้!

PS แม้ว่าจะไม่ได้อยู่ตรงคำถามนี้ตรวจสอบบทความที่ผมเขียนให้นิตยสารกรกฎาคม TechNet ซึ่งจะอธิบายวิธีการสำรองข้อมูลต่างๆทำงานภายใน: การสำรองข้อมูลเซิร์ฟเวอร์ SQL เข้าใจ นิตยสารเดือนกันยายนจะมีข่าวต่อไปในซีรีส์เรื่องความเข้าใจในการฟื้นฟู

— พอลแรนดัล
แหล่งที่มา

2

ฉันชอบความจริงที่ว่าคุณอธิบายว่าการจัดทำดัชนีเป็นการดำเนินการทางตรรกะ

— Jim B

อ่านั่นสมเหตุสมผลแล้ว การสำรองข้อมูลคว้าส่วนขยายฟิสิคัล 64k เต็มไม่ใช่หน้าข้อมูล 8k

— BradC

นี่เป็นเรื่องไร้สาระ การดำเนินการสำรองข้อมูลบีบอัดข้อมูลที่สำรองบ่อยครั้งและนั่นคือ "การเปลี่ยนแปลง" ที่เรากำลังพูดถึง: หลังจากที่ทุกดัชนีสามารถสร้างขึ้นใหม่จากตารางพวกเขาเป็นข้อมูลที่ซ้ำซ้อน (โดยมีการสำรองสคีมา , แน่นอน). เหตุผลที่แท้จริงคือความเกียจคร้านในส่วนของผู้พัฒนาฐานข้อมูล

— John

1

@John คุณพูดว่าอะไรไร้สาระ? การบีบอัดไม่ได้กล่าวถึงที่นี่ - เพียงสร้างดัชนีขึ้นใหม่ซึ่งไม่เหมือนกับการบีบอัด (ซึ่งจะไม่เปลี่ยนหน้าหรือตำแหน่งในฐานข้อมูลระหว่างการกู้คืนในขณะที่การสร้างใหม่) การสร้างดัชนีใหม่ตั้งแต่เริ่มต้นในระหว่างการคืนค่าจะช้าอย่างไม่น่าเชื่อเมื่อเทียบกับการกู้คืนตามการสำรองข้อมูล ฉันคิดว่าคุณเข้าใจผิดบางอย่างที่นี่

— Paul Randal

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

— John

6

การสำรองข้อมูล SQL ดั้งเดิมเป็นเพียงการถ่ายโอนข้อมูลไฟล์สำรองแบบทีละหน้าดังนั้นคำตอบคือ "ไม่" การสำรองข้อมูล Lightspeed ของ Quest น่าจะใช้อัลกอริธึมการบีบอัดข้อมูลบางประเภท แต่ก็ยังไม่ "สร้าง" ไฟล์ข้อมูลหรือดัชนีใหม่ซึ่งจะใช้เวลานานมากในฐานข้อมูลขนาดใหญ่

— แอรอนตัน
แหล่งที่มา

ใช่ แต่มันต้องเขียนทุกหน้าลงดิสก์ ทำไมไม่เขียนมันในลำดับตรรกะแทนที่จะเรียงตามลำดับ? (อาจจะเป็นมากขึ้นของการสำรองข้อมูลคำถามแทนการเรียกคืนคำถาม: ไม่เขียนสำรองหน้าในการสั่งซื้อทางกายภาพหรือในตรรกะ?)

— BradC

สมมติว่ามีผลิตภัณฑ์ที่เขียนข้อมูลออกมาตามลำดับดัชนีคุณต้องการให้บันทึกไว้ในตารางลำดับใด ให้บอกว่าฉันมีตารางที่มี 3 คอลัมน์ product_id ชื่อผลิตภัณฑ์และราคา คอลัมน์ใดที่ถูกต้องในการเรียงลำดับเพื่อบันทึกหน้าในลำดับดัชนี BTW ไม่มีอะไรหยุดคุณจากการจัดทำดัชนีบนทั้งตาราง (ดัชนีคลัสเตอร์) หรือแต่ละแถว (ดัชนีคอมโพสิต)

— Jim B

@Jim B: ง่ายมาก ตารางจะถูกบันทึกในลำดับดัชนีแบบกลุ่ม ดัชนีที่ไม่ใช่คลัสเตอร์จะถูกเก็บไว้ในคำสั่งซื้อที่สำคัญ กองจะถูกเก็บไว้ในคำสั่งเดิม (ไม่เรียง) (แอรอนและพอลได้กล่าวถึงเหตุผลที่ถูกต้องว่าการสำรอง / กู้คืนไม่ได้ทำเช่นนี้การไม่สามารถหาคำสั่ง "ที่ต้องการ" ไม่ใช่หนึ่งในเหตุผลเหล่านี้หรือไม่เช่นนั้นการสร้างดัชนีแบบเต็มจะมีปัญหาเดียวกัน )

— BradC

ข้อมูลถูกสำรองในลำดับฟิสิคัลเพจที่แน่นอนซึ่งถูกบันทึกไว้ในไฟล์ฐานข้อมูล เมื่อข้อมูลถูกกู้คืนข้อมูลจะถูกเรียกคืนตามลำดับหน้าเดียวกับที่สำรองไว้ SQL จะไม่ย้ายข้อมูลด้วยเหตุผลหลายประการ รวมถึงอาจมีปัญหากับธุรกรรมที่กู้คืนบันทึกและปัญหาการโยงหน้าไม่ต้องพูดถึงเวลาพิเศษจำนวนมากที่จำเป็นในการสับเปลี่ยนข้อมูลรอบ ๆ บนฐานข้อมูลแบบหลาย TB

— mrdenny

2

ทำการสำรองข้อมูลเป็นประจำและบ่อยครั้งมาก (ฉันหวังว่า) ดังนั้นนักออกแบบทำให้แน่ใจว่าการสำรองข้อมูลนั้นรวดเร็วที่สุด I / O ที่เร็วที่สุดคืออะไร ลำดับ คุณอ่านบล็อกจากดิสก์ตามลำดับจริงคุณมีประสิทธิภาพที่ดีที่สุด

ทำไมบนโลกควรฐานข้อมูลดำเนินการสุ่ม I / O ที่ยุ่งยากทุกคืนเดียว , การกำจัดหัวของดิสก์ทั่วสถานที่? ความแตกต่างจะอยู่ที่คำสั่งสองขนาด ไม่มีสิ่งที่เป็นไปได้ในเรื่องนี้

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

ฉันเห็นด้วยกับประเด็นโดยรวมของคุณ แต่ขึ้นอยู่กับการกำหนดค่าการจัดเก็บข้อมูลแบบสุ่ม I / O แบบสุ่มอาจไม่ใช่คำสั่งที่มีขนาดที่แย่กว่าลำดับ I / O (ไดรฟ์ SAN ที่แผ่กระจายไปทั่วแกนหมุนหลายสิบตัวอย่าง) ในความเป็นจริงหากไฟล์ข้อมูลมีการแยกส่วนในฮาร์ดไดรฟ์แล้วแม้ "I / O" ลำดับ "ไม่ได้เรียงตามลำดับจริงๆ แต่จุดที่พอลแทนที่อยู่ดีนี้ (มีปัญหากับการปรับปรุงตัวชี้และการจัดระเบียบที่ควรจะดำเนินการลงทะเบียน)

— BradC

0

อืมม BradC คุณเคยทำงานกับ Firebird / Interbase มาก่อนหรือไม่ซึ่งการแบ็คอัพหลัก / การคืนค่ายูทิลิตี้ / API นั้นเหมือนกับ "คัดลอกฐานข้อมูล ... " ของ SSMS / EM หรือไม่ ถ้าเป็นเช่นนั้นรู้ว่า MS SQL Server ไม่ชอบ

การสำรองข้อมูล SQLServer เป็นดัมพ์ฐานข้อมูลที่ถูกกู้คืน "ตามที่เป็นจริง" - ดังนั้นจึงเป็นเหมือนทางลัดออนไลน์ที่สะดวกสบายสำหรับการดำเนินการ "detach-copy-reattach on place" ฐานข้อมูลที่กู้คืนเกือบจะเป็นสำเนาที่ถูกต้องของไฟล์ฐานข้อมูลต้นฉบับ (เกือบเป็นเพราะคุณสามารถเปลี่ยนตำแหน่งของไฟล์ฐานข้อมูลของฐานข้อมูลที่เรียกคืน) ...

— Fabricio Araujo
แหล่งที่มา