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

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

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

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

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

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

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

ข้อยกเว้นเดียวสำหรับกฎนี้คือถ้าห่วงโซ่การสำรองข้อมูลบันทึกถูกใช้งานไม่ได้ (เช่นโดยไปที่แบบจำลองการกู้คืนข้อมูลอย่างง่ายการย้อนกลับจากสแน็ปช็อตฐานข้อมูลการตัดทอนบันทึกโดยใช้ 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/]

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

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

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

คำถามสุดท้ายของคุณคือ: "นอกจากการสำรอง 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 น. แต่การจ่ายเงินนั้นมีประสิทธิภาพที่เร็วกว่า

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

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

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

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

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

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

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

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

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

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

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