ฉันจะลดขนาดการสำรองข้อมูลบันทึกธุรกรรมหลังการสำรองข้อมูลเต็มได้อย่างไร


38

ฉันมีแผนการบำรุงรักษาสามชุดที่ติดตั้งเพื่อใช้งานบนอินสแตนซ์ของ Sql Server 2005:

  • การปรับฐานข้อมูลรายสัปดาห์ตามด้วยการสำรองข้อมูลเต็มรูปแบบ
  • สำรองข้อมูลรายวันที่แตกต่างกัน
  • สำรองข้อมูลบันทึกธุรกรรมทุกชั่วโมง

การสำรองข้อมูลบันทึกรายชั่วโมงมักจะอยู่ระหว่างสองสามร้อย Kb และ 10Mb ขึ้นอยู่กับระดับของกิจกรรมความแตกต่างรายวันจะเพิ่มขึ้นประมาณ 250Mb ในตอนท้ายของสัปดาห์และการสำรองข้อมูลรายสัปดาห์ประมาณ 3.5Gb

ปัญหาที่ฉันมีคือการเพิ่มประสิทธิภาพก่อนการสำรองข้อมูลเต็มรูปแบบดูเหมือนจะทำให้การสำรองข้อมูลการทำธุรกรรมครั้งต่อไปเพิ่มขึ้นถึง 2x ขนาดของการสำรองข้อมูลเต็มรูปแบบในกรณีนี้ 8Gb ก่อนกลับสู่ภาวะปกติ

นอกเหนือจากBACKUP LOG <DatabaseName> WITH TRUNCATE_ONLYนี้มีวิธีใดที่จะลดขนาดของการสำรองข้อมูลบันทึกนั้นหรือป้องกันไม่ให้มีการบันทึกการเพิ่มประสิทธิภาพในบันทึกการทำธุรกรรมเลยเพราะแน่นอนว่าพวกเขาจะถูกบันทึกไว้ในการสำรองข้อมูลเต็มรูปแบบที่นำหน้า


1
+1 โหวตขึ้นเนื่องจากการแลกเปลี่ยนความคิดที่เกิดจากคำถามนี้
MarlonRibunal

คำตอบ:


35

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

ข้อยกเว้นเดียวสำหรับกฎนี้คือถ้าห่วงโซ่การสำรองข้อมูลบันทึกถูกใช้งานไม่ได้ (เช่นโดยไปที่แบบจำลองการกู้คืนข้อมูลอย่างง่ายการย้อนกลับจากสแน็ปช็อตฐานข้อมูลการตัดทอนบันทึกโดยใช้ BACKUP LOG ด้วย NO_LOG / TRUNCATE_ONLY) จะมีบันทึกธุรกรรมทั้งหมดตั้งแต่การสำรองข้อมูลเต็มรูปแบบครั้งล่าสุด - ซึ่งจะเริ่มห่วงโซ่การสำรองข้อมูลบันทึกใหม่ หรือหากยังไม่ได้เริ่มต้นห่วงโซ่การสำรองข้อมูล - เมื่อคุณเปลี่ยนเป็น FULL เป็นครั้งแรกคุณทำงานในรูปแบบการกู้คืนแบบหลอกเทียม - SIMPLE จนกว่าจะมีการสำรองข้อมูลเต็มรูปแบบครั้งแรก

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

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

หากคุณไม่มีกิจกรรมอื่นในฐานข้อมูลขณะที่การบำรุงรักษากำลังเกิดขึ้นคุณสามารถทำสิ่งต่อไปนี้:

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

หวังว่านี่จะช่วยได้ - รอข้อมูลเพิ่มเติม

ขอบคุณ

[แก้ไข: หลังจากการสนทนาทั้งหมดเกี่ยวกับการสำรองข้อมูลเต็มรูปแบบสามารถเปลี่ยนขนาดของการสำรองข้อมูลบันทึกในภายหลัง (ไม่สามารถทำได้) ฉันรวบรวมโพสต์บล็อกที่ครอบคลุมด้วยวัสดุพื้นหลังและสคริปต์ที่พิสูจน์ได้ ลองดูที่https://www.sqlskills.com/blogs/paul/misconceptions-around-the-log-and-log-backups-how-to-convince-yourself/]


4
พอล - ไม่เห็นด้วยอย่างสิ้นเชิง ไม่ทำการสำรองข้อมูลล็อกระหว่างการบำรุงรักษาดัชนี บันทึกจะเพิ่มขึ้นและการสำรองข้อมูลเต็มรูปแบบต่อไปจะมีขนาดใหญ่ขึ้น แต่คุณจะไม่ได้รับประสิทธิภาพการทำงานของการสำรองข้อมูล t-log ที่เกิดขึ้นในเวลาเดียวกันกับงานบำรุงรักษาดัชนีของคุณ คุณเห็นข้อดีของมันไหม? แน่นอนคุณจะยอมรับว่าการสำรองข้อมูล t-log พร้อมกันและการบำรุงรักษาดัชนีจะทำให้เกิดประสิทธิภาพ
Brent Ozar

6
ไม่ - ฉันยังคงไม่เห็นด้วย ฉันต้องการสำรองข้อมูลบันทึกบ่อยกว่าดังนั้นจึงมีขนาดเล็กมากกว่าสัตว์ประหลาดหนึ่งตัวหลังจากการบำรุงรักษาเสร็จสิ้น การมีการสำรองข้อมูลบันทึกขนาดไม่เป็นสัดส่วนอาจทำให้เกิดปัญหาในการคัดลอกข้อมูลผ่านเครือข่าย (เช่นการสำรองข้อมูลนอกสถานที่หรือการจัดส่งบันทึก) ถ้าไม่มีกิจกรรมของผู้ใช้และไม่จำเป็นอื่น ๆ สำหรับการสำรองข้อมูลเข้าสู่ระบบแล้วบางทีแต่ถ้าระบบล่มและคุณจะต้องทำสำรองหางของบันทึกที่ว่าจะใช้เวลามากเวลาที่เป็นส่วนหนึ่งของการหยุดทำงานของคุณ . ฉันควรทำโพสต์บล็อกเกี่ยวกับเรื่องนี้
Paul Randal

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

5

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

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

ฉันจะข้ามส่วนต่างรายวันเพื่อสนับสนุนการสำรองข้อมูลเต็มรูปแบบรายวัน BTW


ฉันคิดว่าฉันสามารถทำ TRUNCATE LOG ตรงท้ายการสำรองข้อมูลเต็มรูปแบบได้ แต่นั่นไม่ใช่วิธีที่ดีที่สุดฉันหวังว่าจะมีทางเลือกอื่น ๆ ... สิ่งที่เป็นประโยชน์ในการสำรองข้อมูลเต็มรูปแบบทุกวัน diffs กว่า? นั่นดูเหมือนว่าจะใช้พื้นที่มากขึ้นเพื่อผลประโยชน์ที่ค่อนข้างน้อย ฉันยังไม่สามารถเปลี่ยนเป็นการกู้คืนแบบง่าย ๆ ได้เนื่องจากฉันต้องการระดับของข้อมูลสำรองที่บันทึกเป็นรายชั่วโมง ในที่สุดฉันไม่แน่ใจว่าการเพิ่มประสิทธิภาพให้กับสคริปต์จะช่วยได้อย่างไรแน่นอนว่าฉันยังคงมีปัญหาเดียวกันอยู่บ่อยครั้งกว่า
เดฟ

ฉัน downvote นี้เพราะข้อเสนอแนะเพื่อข้าม diffs และไปที่ fulls รายวัน ทำไม? เต็ม 3.5GB ในขณะที่มีความแตกต่างเพียง 250MB กลยุทธ์การสำรองข้อมูลดูดีสำหรับฉันอย่างแน่นอน การถอด diffs หมายถึงพื้นที่เก็บข้อมูลเพิ่มขึ้นอีกหลาย GB สำหรับการเร่งความเร็วเพียงเล็กน้อยและเล็ก ๆ ในเวลากู้คืน
Paul Randal

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

1
@Dave ดูการตอบสนองของ Jeremy สร้างกระบวนงานที่เก็บไว้เพื่อจัดเรียงข้อมูลเฉพาะไฟล์และแยกมันออกเป็นส่วนย่อย ๆ
SqlACID

3

คำถามสุดท้ายของคุณคือ: "นอกจากการสำรอง BACKUP ด้วย TRUNCATE_ONLY จะมีวิธีใดในการลดขนาดของการสำรองข้อมูลบันทึกนั้นหรือป้องกันไม่ให้บันทึกการเพิ่มประสิทธิภาพในบันทึกการทำธุรกรรมเลยเพราะแน่นอนว่าพวกเขาจะถูกบันทึกไว้ใน สำรองข้อมูลก่อนหน้าหรือไม่ "

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

  • 21:30 น. - การสำรองข้อมูลบันทึกธุรกรรม
  • 9:45 PM - การสำรองข้อมูลบันทึกธุรกรรมรันเป็นครั้งสุดท้าย กำหนดการหยุดเวลา 9:59 น.
  • 10:00 PM - งานซ่อมบำรุงดัชนีเริ่มต้นและมีตัวหยุดในตัวให้เสร็จก่อน 11:30 น.
  • 23:30 น. - งานแบ็กอัพเต็มเริ่มและเสร็จสิ้นภายใน 30 นาที
  • 12:00 AM - การสำรองข้อมูลบันทึกธุรกรรมเริ่มต้นใหม่ทุก ๆ 15 นาที

นั่นหมายความว่าฉันไม่มีจุดกู้คืนได้ตรงเวลาระหว่างเวลา 09:45 น. และ 23:30 น. แต่การจ่ายเงินนั้นมีประสิทธิภาพที่เร็วกว่า


และคุณต้องเปลี่ยนไปใช้ SIMPLE ก่อน 22.00 น. ใช่ไหม มิฉะนั้นการสำรองข้อมูลบันทึก 12AM จะมีบันทึกทั้งหมดที่สร้างขึ้นระหว่าง 22.00 น. ถึง 12.00 น
Paul Randal

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

ไม่แน่นอนไม่เปลี่ยนเป็นแบบเรียบง่าย เขาถามเกี่ยวกับขนาดของการสำรองข้อมูลบันทึกธุรกรรมไม่ใช่ขนาดของการสำรองข้อมูลเต็มรูปแบบหรือไฟล์บันทึกธุรกรรมของเขา
Brent Ozar

ดังนั้นสิ่งที่คุณจะลดขนาดของการสำรองข้อมูลบันทึกธุรกรรม? พวกเขาจะมีทุกอย่างตั้งแต่การสำรองข้อมูลบันทึกก่อนหน้าเว้นแต่ว่าคุณจะทำลายห่วงโซ่การสำรองข้อมูลบันทึกแล้วเริ่มต้นใหม่ด้วยการสำรองข้อมูลเต็ม
Paul Randal

เว้นแต่งานของคุณบำรุงรักษาดัชนีไม่ได้ทำอะไร ...
พอล Randal

3

คำตอบง่ายๆ: เปลี่ยนงานเพิ่มประสิทธิภาพรายสัปดาห์ของคุณเพื่อให้ทำงานอย่างสมดุลมากขึ้นทุกคืน เช่นตาราง re-index ae ในคืนวันอาทิตย์, f - l ในคืนวันจันทร์ ฯลฯ ... ค้นหายอดเงินที่ดีบันทึกของคุณจะประมาณ 1/6 ของขนาดโดยเฉลี่ย แน่นอนว่าวิธีนี้ใช้ได้ผลดีที่สุดหากคุณไม่ได้ใช้งานการบำรุงรักษาดัชนี ssis ในตัว

ข้อเสียของสิ่งนี้และมันสำคัญมากขึ้นอยู่กับโหลดประสบการณ์ db ของคุณคือมันสร้างความหายนะด้วยเครื่องมือเพิ่มประสิทธิภาพและการใช้แผนคิวรีซ้ำ

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


2

คุณอาจดูเป็นเครื่องมือบุคคลที่สาม (Litespeed จาก Quest, SQL Backup จาก Red Gate, Hyperbac) เพื่อลดขนาดของการสำรองข้อมูลและบันทึก พวกเขาสามารถจ่ายเองได้อย่างรวดเร็วในการประหยัดเทป


2

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

  1. สร้างใหม่หรือจัดระเบียบดัชนีของคุณทุกคืนหากกำหนดการอนุญาตของคุณและหากผลกระทบเป็นที่ยอมรับ เมื่อดำเนินการภารกิจบำรุงรักษาดัชนีรายคืนเหล่านี้จะกำหนดเป้าหมายเฉพาะดัชนีที่แยกส่วนเกินกว่า 30% สำหรับการสร้างใหม่และในช่วง 15-30% สำหรับการสร้างใหม่

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

ฉันใช้แนวทางแบบ Zen เพื่อล็อกไฟล์ของฉัน: เป็นขนาดที่พวกเขาต้องการ ตราบใดที่พวกเขายังไม่สามารถทนต่อการเติบโตอย่างกะทันหันเนื่องจากการสำรองข้อมูลที่ไม่ดีเมื่อเปรียบเทียบกับกิจกรรมฐานข้อมูลที่เป็นมนต์ที่ฉันอาศัยอยู่

สำหรับสคริปต์ที่ดำเนินการบำรุงรักษาดัชนีโดยพิจารณาดูออนไลน์: มีตันออกมี Andrew Kelly ตีพิมพ์หนึ่งในนิตยสาร SQL ที่ดีเมื่อประมาณหนึ่งปีก่อน SQLServerPedia มีสคริปต์บางตัวจาก Michelle Ufford และฉบับล่าสุดของนิตยสาร SQL (ฉันเชื่อว่ากรกฎาคม 2009) มีบทความฉบับเต็มในหัวข้อเช่นกัน จุดคือการหาสิ่งที่เหมาะกับคุณและทำให้เป็นของคุณเองด้วยการปรับแต่งน้อยที่สุด


2

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

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

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