การสำรองข้อมูลบันทึกธุรกรรมแบบอนุกรมหรือแบบขนาน?

เรากำลังใช้ SQL Server 2012 Standard Edition อยู่ ฉันยังใช้สคริปต์ของ Ola Hallengren เพื่อจัดเตรียมกรอบงานที่ง่ายและยืดหยุ่นมากขึ้นสำหรับการสำรองและบำรุงรักษา

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

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

เป็นจริงหรือไม่ที่สคริปต์ของ Ola ทำงานในอนุกรมและความล้มเหลวจะหยุดการสำรองข้อมูลอย่างต่อเนื่อง

และจะดีกว่าหรือไม่ที่จะมีงานสำหรับแต่ละฐานข้อมูล หรืองานเดียวที่ทำทั้งหมด ความชอบของฉันมีต่องานแยกกัน แต่ฉันต้องการที่จะเข้าใจว่า DBA ของ SQL Server โดยทั่วไปมีแนวโน้มที่จะทำอะไร

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

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

สิ่งที่อาจเป็นไปได้ข้อเสียคือการทำงานแบบขนาน

1. สมมติว่าคุณมีฐานข้อมูล 50 รายการและคุณตั้งเวลาสำรองข้อมูลบันทึกธุรกรรมของฐานข้อมูลทั้งหมดและพวกเขาทั้งหมดเริ่มทำงานพร้อมกันซึ่งจะใช้ประโยชน์จาก I / O เป็นจำนวนมาก และหากดิสก์ที่มีการสำรองไฟล์เกิดขึ้นมีไฟล์ข้อมูลอื่น ๆ คุณจะเห็นความเชื่องช้า ฉันเห็นการสำรองข้อมูลช้าลงเมื่อคิวรีไม่ดีที่ร้องขอ I / O จำนวนมากทำงานพร้อมกับงานสำรอง

2. อีกครั้งสมมติว่าคุณมีฐานข้อมูล 50 จะไม่ยากในการจัดการงาน 50 ในตัวแทน SQL Server และสิ่งที่จะเป็นเงื่อนไขถ้าคุณมีฐานข้อมูล 100-200 ฉันจะไม่ชอบเมื่อคุณเปิดตัวแทน SQL Server และดูงานจำนวนมาก เพียงแค่ทำให้มันง่าย ฉันแน่ใจว่ากรณีเดียวกันจะอยู่กับคุณ

ข้อเสียของซีเรียลคือการสำรองข้อมูลต่อเนื่องแต่ละครั้งจะรอจนกว่าข้อมูลอื่นจะเสร็จสมบูรณ์ สิ่งนี้อาจเพิ่มระยะเวลาระหว่างการสำรองข้อมูล (เช่นมากกว่า 15 นาที)

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

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

ฉันจะบอกว่าไม่ต้องกังวลกับมัน การสำรองข้อมูลบันทึกธุรกรรมไม่สามารถล้มเหลวได้เว้นแต่คุณจะทำผิดพลาด ความผิดพลาดสามารถ

1. เจ้าของที่กำลังใช้งานจะถูกลบออกจากโฆษณา

2. มีคนเปลี่ยนรูปแบบการกู้คืนของฐานข้อมูล

3. พื้นที่ดิสก์ไม่เพียงพอ

นอกเหนือจากข้างต้นฉันไม่เห็นเหตุผลใด ๆ ที่ทำให้การสำรองข้อมูลบันทึกธุรกรรมล้มเหลว มันแข็งแกร่งมากที่คุณสามารถไว้ใจได้

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

การสำรองข้อมูลแบบขนานเท่านั้นจะมีประโยชน์หากเงื่อนไขต่อไปนี้ทั้งหมดเป็นจริง:

• ฐานข้อมูลและไฟล์บันทึกของคุณทั้งหมดอยู่ในแกนหมุนอิสระที่ไม่ซ้ำกัน (หรืออยู่ในดิสก์สถานะของแข็งในการรวมกันใด ๆ )

  • สำหรับการสำรองข้อมูลแบบ T-log เฉพาะไฟล์บันทึกเท่านั้นที่จะต้องปฏิบัติตามข้อกำหนดนี้

• เป้าหมายการสำรองข้อมูลของคุณสำหรับแต่ละฐานข้อมูลอยู่ในแกนแยกต่างหาก

• คุณไม่ได้ใช้ SAN HBA หรือ iSCSI ที่ใช้ร่วมกันหรือแบนด์วิดท์อื่น ๆ ระหว่างอินสแตนซ์ SQL Server และสื่อบันทึก

• เช่น IOPS จากการอ่านฐานข้อมูล A และการเขียนสำรอง A อย่าใช้ดิสก์เดียวกับการอ่านฐานข้อมูล B และการสำรองข้อมูล B

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

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

• ความล้มเหลวของดิสก์

• ความล้มเหลวของซอฟต์แวร์บีบอัดของ Hyperbac / Litespeed / บุคคลที่สาม (ถ้าคุณมีซอฟต์แวร์ระหว่าง SQL และดิสก์ที่ล้มเหลว)

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

• การเข้ารหัสผลิตภัณฑ์ล้มเหลว (หากคุณมีซอฟต์แวร์ระหว่าง SQL และดิสก์ที่ล้มเหลว)

• ความล้มเหลวของเครือข่าย (หากไฟล์ฐานข้อมูลหรือไฟล์สำรองมีโอกาสมากขึ้นอยู่ในเครือข่าย)

• สิทธิ์

  • พบมากที่สุดกับการติดตั้งใหม่

  • หรือที่ตั้งสำรองใหม่

  • การเปลี่ยนผู้ใช้บริการเซิร์ฟเวอร์ SQL (ซึ่งเป็นสิ่งที่ต้องมีสิทธิ์สำหรับการสำรองข้อมูลปกติ)

  • ล็อคผู้ใช้บริการ SQL Server เพราะมันถูกใช้โดยอินสแตนซ์ของ SQL Server มากกว่าหนึ่ง

• ข้อผิดพลาดในการกำหนดค่า

• ไฟฟ้าขัดข้อง

• ระบบปฏิบัติการขัดข้อง

ซึ่งส่วนใหญ่จะไม่ส่งผลกระทบอย่างใดอย่างหนึ่งและไม่ได้อื่น ๆ เว้นแต่เงื่อนไขข้างต้นจะได้พบกับ

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