คำถามนี้ดูเหมือนจะเป็นคำถามที่พบบ่อยในฟอรัมส่วนใหญ่และทั่วทั้งเว็บมันถูกถามที่นี่ในหลาย ๆ รูปแบบซึ่งโดยทั่วไปแล้วจะมีลักษณะดังนี้:

ใน SQL Server -

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

คำตอบที่สั้นกว่า:

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

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

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

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

เหตุผลอันดับแรก 1/2: ไม่เข้าใจโมเดลการกู้คืน

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

ในขณะที่คำตอบนี้ไม่ใช่การดำน้ำลึกในแบบจำลองการกู้คืนของ SQL Server หัวข้อของแบบจำลองการกู้คืนมีความสำคัญต่อปัญหานี้

ใน SQL Server มีรูปแบบการกู้คืนสามแบบ :

• Full,
• Bulk-Logged และ
• Simple.

เราจะเพิกเฉยBulk-Loggedตอนนี้เราจะบอกว่ามันเป็นรุ่นไฮบริดและคนส่วนใหญ่ที่อยู่ในรุ่นนี้จะมีเหตุผลและเข้าใจรูปแบบการกู้คืน

สองเราดูแลเกี่ยวกับและความสับสนของพวกเขาเป็นสาเหตุของกรณีส่วนใหญ่ของคนที่มีปัญหานี้ที่มีและSimpleFull

ระยะเวลา: การกู้คืนโดยทั่วไป

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

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

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

แบบจำลองการกู้คืน

ไปยังแบบจำลองการกู้คืน:

• Simple Recovery Model
  ดังนั้นด้วยการแนะนำข้างต้นจึงเป็นการง่ายที่สุดที่จะพูดคุยเกี่ยวกับSimple Recoverymodel ก่อน ในรุ่นนี้คุณกำลังบอก SQL Server: "ฉันสบายดีกับคุณโดยใช้ไฟล์บันทึกการทำธุรกรรมของคุณสำหรับข้อผิดพลาดและเริ่มการกู้คืน ... " (คุณไม่มีทางเลือกจริง ๆ ค้นหาคุณสมบัติของกรดและควรสมเหตุสมผล) "... แต่เมื่อคุณไม่ต้องการใช้เพื่อวัตถุประสงค์ในการกู้คืนข้อผิดพลาด / เริ่มใหม่อีกต่อไปให้ไปข้างหน้าและนำไฟล์บันทึกกลับมาใช้ใหม่"

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

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

การเปลี่ยนจาก Simple เป็น Full มี Gotcha

มีกฎและข้อยกเว้นอยู่ที่นี่ เราจะพูดคุยเกี่ยวกับการทำธุรกรรมระยะยาวในเชิงลึกด้านล่าง

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

รูปแบบการกู้คืนแบบเต็มโดยไม่มีการสำรองข้อมูลบันทึกไม่ดี

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

สิ่งนี้เกิดขึ้นตลอดเวลากับผู้คน

ทำไมสิ่งนี้จึงเป็นข้อผิดพลาดทั่วไป?

ทำไมมันเกิดขึ้นตลอดเวลา? เนื่องจากฐานข้อมูลใหม่แต่ละแห่งได้รับการตั้งค่ารูปแบบการกู้คืนเริ่มต้นโดยดูที่ฐานข้อมูลโมเดล

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

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

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

ฉันจะค้นหาความถี่ในการสำรองข้อมูลบันทึกที่ฉันต้องการได้อย่างไร

คุณต้องพิจารณาความถี่ในการสำรองข้อมูลบันทึกโดยคำนึงถึงสองสิ่ง:

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

เหตุผลหลักที่ 2/2: ธุรกรรมที่ดำเนินมายาวนาน

( "แบบจำลองการกู้คืนของฉันใช้ได้! บันทึกยังคงเพิ่มขึ้น! )

นี่อาจเป็นสาเหตุของการเติบโตของบันทึกที่ไม่สามารถควบคุมและไม่ได้ถูกควบคุม ไม่ว่าจะเป็นรูปแบบการกู้คืนข้อมูล แต่มักเกิดขึ้นในรูปแบบ"แต่ฉันอยู่ใน Simple Recovery Model - ทำไมบันทึกของฉันยังคงเพิ่มขึ้น!"

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

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

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

ฉันจะทำอะไรเกี่ยวกับธุรกรรมที่ดำเนินมายาวนานเหล่านี้

คุณสามารถช่วยตัวเองที่นี่โดย:

• ปรับขนาดไฟล์บันทึกของคุณให้เหมาะสมกับสถานการณ์กรณีที่เลวร้ายที่สุดเช่นการบำรุงรักษาหรือการดำเนินการที่มีขนาดใหญ่ และเมื่อคุณขยายไฟล์บันทึกของคุณคุณควรมองไปที่คำแนะนำนี้(และลิงก์ทั้งสองที่เธอส่งถึงคุณ) โดย Kimberly Tripp การปรับขนาดที่เหมาะสมนั้นสำคัญอย่างยิ่งที่นี่
• ดูการใช้งานของการทำธุรกรรมของคุณ อย่าเริ่มทรานแซคชันในแอปพลิเคชันเซิร์ฟเวอร์ของคุณและเริ่มการสนทนากับ SQL Server เป็นเวลานานและมีความเสี่ยงที่จะเปิดหนึ่งครั้งนานเกินไป
• การดูธุรกรรมโดยนัยในงบ DML ของคุณ ตัวอย่างเช่น: UPDATE TableName Set Col1 = 'New Value'เป็นธุรกรรม ฉันไม่ได้ใส่ที่BEGIN TRANนั่นและฉันก็ไม่ต้องทำมันยังคงเป็นธุรกรรมหนึ่งที่เพิ่งจะทำโดยอัตโนมัติเมื่อเสร็จสิ้น ดังนั้นหากทำการดำเนินการกับแถวจำนวนมากให้พิจารณาการแบ็ตช์การดำเนินการเหล่านั้นเป็นกลุ่มที่จัดการได้มากขึ้นและให้เวลาในการกู้คืน หรือพิจารณาขนาดที่เหมาะสมเพื่อจัดการกับสิ่งนั้น หรืออาจดูการเปลี่ยนโมเดลการกู้คืนระหว่างหน้าต่างโหลดจำนวนมาก

เหตุผลสองข้อนี้ใช้กับการจัดส่งบันทึกด้วยหรือไม่

คำตอบสั้น ๆ : ใช่ คำตอบอีกต่อไปด้านล่าง

คำถาม: "ฉันกำลังใช้บันทึกการจัดส่งดังนั้นการสำรองข้อมูลบันทึกของฉันจึงเป็นไปโดยอัตโนมัติ ... ทำไมฉันจึงยังเห็นการเติบโตของบันทึกธุรกรรม"

คำตอบ: อ่านต่อ

บันทึกการจัดส่งคืออะไร

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

• งานในการสำรองข้อมูลบันทึกบนเซิร์ฟเวอร์เดียว
• งานที่จะคัดลอกข้อมูลสำรองและ
• งานที่จะกู้คืนโดยไม่มีการกู้คืน (อย่างใดอย่างหนึ่งNORECOVERYหรือSTANDBY) บนเซิร์ฟเวอร์ปลายทาง

นอกจากนี้ยังมีงานตรวจสอบและแจ้งเตือนหากมีสิ่งที่ไม่เป็นไปตามที่คุณวางแผนไว้

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

การแก้ไขปัญหาทั่วไปผ่านรหัสสถานะ

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

โดยการสอบถามsys.databasesมุมมองแคตตาล็อกคุณสามารถดูข้อมูลที่อธิบายถึงเหตุผลที่ไฟล์บันทึกของคุณอาจกำลังรอการตัดทอน / นำมาใช้ซ้ำ

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

• 0 = ไม่มี
  อะไรฟังดูเหมือน .. ไม่ควรรอ

• 1 = จุดตรวจ
  กำลังรอให้จุดตรวจสอบเกิดขึ้น สิ่งนี้จะเกิดขึ้นและคุณควรจะสบายดี - แต่มีบางกรณีที่ต้องมองหาคำตอบหรือการแก้ไขในภายหลังที่นี่

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

• 3 =
  การสำรองข้อมูลหรือกู้คืนที่ใช้งานอยู่การดำเนินการสำรองข้อมูลหรือคืนค่ากำลังทำงานบนฐานข้อมูล

• 4 = รายการที่ใช้งานอยู่
  มีรายการที่ใช้งานอยู่ที่ต้องทำให้เสร็จสมบูรณ์ (ไม่ว่าจะด้วยวิธีใด - ROLLBACKหรือCOMMIT) ก่อนที่จะสามารถทำการสำรองข้อมูลได้ นี่คือเหตุผลที่สองที่อธิบายไว้ในคำตอบนี้

• 5 = การทำมิเรอร์ฐานข้อมูลมิรเรอร์
  กำลังล้าหลังหรือภายใต้ความหน่วงบางอย่างในสถานการณ์การมิเรอร์ประสิทธิภาพสูงหรือการมิเรอร์ถูกหยุดชั่วคราวด้วยเหตุผลบางอย่าง

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

• 7 = การสร้างสแนปชอตฐานข้อมูล
  คุณกำลังสร้างสแน็ปช็อตฐานข้อมูลคุณจะเห็นสิ่งนี้ถ้าคุณดูในช่วงเวลาที่เหมาะสมเมื่อสแน็ปช็อตถูกสร้างขึ้น

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

• 9 = แบบจำลองรอง AlwaysOn Availability Groups กำลังใช้เร็กคอร์ดบันทึกธุรกรรมของฐานข้อมูลนี้กับฐานข้อมูลรองที่สอดคล้องกัน เกี่ยวกับคำอธิบายที่ชัดเจนที่สุด ..

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

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

ก่อนทำการสำรองข้อมูลเต็มรูปแบบ

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

หากคุณสนใจเกี่ยวกับการกู้คืนในเวลา

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

สันนิษฐานว่าฐานข้อมูลของคุณอยู่ในFULLโหมดการกู้คืน ถ้าไม่เช่นนั้นให้แน่ใจว่ามันคือ:

ALTER DATABASE yourdb SET RECOVERY FULL;

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

DECLARE @path NVARCHAR(255) = N'\\backup_share\log\yourdb_' 
  + CONVERT(CHAR(8), GETDATE(), 112) + '_'
  + REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','')
  + '.trn';

BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION;

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

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

โปรดทราบว่าคุณอาจต้องสำรองข้อมูลบันทึกสองครั้งก่อนที่จะทำการย่อขนาด (ขอบคุณ Robert)

ดังนั้นคุณต้องหาขนาดที่เหมาะสมสำหรับไฟล์บันทึกของคุณ ไม่มีใครที่นี่สามารถบอกคุณได้ว่าอะไรคือสิ่งที่โดยไม่รู้ตัวมากขึ้นเกี่ยวกับระบบของคุณ แต่ถ้าคุณมักจะลดขนาดไฟล์บันทึกและมันก็เติบโตขึ้นอีกครั้งลายน้ำที่ดีน่าจะสูงกว่า 10-50% ที่ใหญ่ที่สุด . สมมติว่ามีขนาด 200 MB และคุณต้องการให้เหตุการณ์ autogrowth ที่ตามมาเป็น 50 MB จากนั้นคุณสามารถปรับขนาดล็อกไฟล์ด้วยวิธีนี้:

USE [master];
GO
ALTER DATABASE Test1 
  MODIFY FILE
  (NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB);
GO

โปรดทราบว่าหากไฟล์บันทึกปัจจุบัน> 200 MB คุณอาจต้องเรียกใช้ไฟล์นี้ก่อน:

USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO

หากคุณไม่สนใจเกี่ยวกับการกู้คืนในเวลา

หากนี่คือฐานข้อมูลทดสอบและคุณไม่สนใจเกี่ยวกับการกู้คืนในเวลานั้นคุณควรตรวจสอบให้แน่ใจว่าฐานข้อมูลของคุณอยู่ในSIMPLEโหมดการกู้คืน

ALTER DATABASE yourdb SET RECOVERY SIMPLE;

การวางฐานข้อมูลในSIMPLEโหมดการกู้คืนจะทำให้แน่ใจว่า SQL Server จะใช้ส่วนของไฟล์บันทึกอีกครั้ง (โดยการยกเลิกธุรกรรมที่ไม่ได้ใช้งานเป็นหลัก) แทนที่จะเติบโตเพื่อเก็บบันทึกธุรกรรมทั้งหมด (เช่นFULLการกู้คืนจะทำจนกว่าจะสำรองข้อมูล CHECKPOINTเหตุการณ์จะช่วยควบคุมการบันทึกและตรวจสอบให้แน่ใจว่ามันไม่จำเป็นต้องเติบโตเว้นแต่คุณจะสร้างกิจกรรม t-log จำนวนมากระหว่างCHECKPOINTs

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

USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
-- 200 MB
DBCC SHRINKFILE(yourdb_log, 200);
GO

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

บางสิ่งที่คุณไม่ต้องการทำ

• สำรองล็อกกับTRUNCATE_ONLYSHRINKFILEตัวเลือกแล้ว สำหรับTRUNCATE_ONLYตัวเลือกนี้เลิกใช้แล้วและไม่สามารถใช้งานได้ใน SQL Server เวอร์ชันปัจจุบันอีกต่อไป ประการที่สองหากคุณอยู่ในFULLรูปแบบการกู้คืนสิ่งนี้จะทำลายห่วงโซ่การบันทึกของคุณและต้องมีการสำรองข้อมูลใหม่ที่สมบูรณ์

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

• ใช้ "ฐานข้อมูลหดตัวเลือก" DBCC SHRINKDATABASEและตัวเลือกแผนการบำรุงรักษาที่จะทำเช่นเดียวกันคือแนวคิดที่ไม่ดีโดยเฉพาะหากคุณต้องการแก้ไขปัญหาบันทึกเท่านั้น กำหนดเป้าหมายไฟล์ที่คุณต้องการปรับและปรับแต่งอย่างอิสระโดยใช้DBCC SHRINKFILEหรือALTER DATABASE ... MODIFY FILE(ตัวอย่างด้านบน)

• หดล็อกไฟล์ 1 MB สิ่งนี้ดูน่าดึงดูดเพราะเฮ้ SQL Server จะให้ฉันทำในบางสถานการณ์และดูที่ว่างทั้งหมด! ยกเว้นว่าฐานข้อมูลของคุณจะอ่านอย่างเดียว (และคุณควรทำเครื่องหมายว่าเป็นการใช้ALTER DATABASE) สิ่งนี้จะนำไปสู่เหตุการณ์การเติบโตที่ไม่จำเป็นจำนวนมากอย่างแน่นอนเนื่องจากบันทึกจะต้องรองรับธุรกรรมปัจจุบันโดยไม่คำนึงถึงรูปแบบการกู้คืน อะไรคือประเด็นของการเพิ่มพื้นที่ว่างชั่วคราวเพื่อให้ SQL Server สามารถนำมันกลับมาช้าและเจ็บปวด?

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

เป็นเชิงรุก

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

การตั้งค่าที่แย่ที่สุดที่เป็นไปได้คือการเติบโต 1 MB หรือการเติบโต 10% ตลกดีสิ่งเหล่านี้เป็นค่าเริ่มต้นสำหรับ SQL Server (ซึ่งฉันได้ร้องเรียนและขอการเปลี่ยนแปลงที่ไม่มีประโยชน์ ) - 1 MB สำหรับไฟล์ข้อมูลและ 10% สำหรับไฟล์บันทึก อดีตมีขนาดเล็กเกินไปในวันนี้และอายุและหลังนำไปสู่เหตุการณ์ที่ยาวและนานขึ้นทุกครั้ง (พูดล็อกไฟล์ของคุณคือ 500 MB การเติบโตครั้งแรกคือ 50 MB การเติบโตครั้งต่อไปคือ 55 MB การเติบโตต่อไปคือ 60.5 MB ฯลฯ ฯลฯ - และใน I / O ที่ช้าเชื่อฉันคุณจะสังเกตเห็นความโค้งนี้)

อ่านเพิ่มเติม

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

• โพสต์บล็อกที่ผมเขียนในปี 2009 เมื่อผมเห็นไม่กี่ "นี่เป็นวิธีที่จะหดตัวลงล็อกไฟล์" โพสต์สปริงขึ้น

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

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

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

คุณยังสามารถดูเนื้อหาของไฟล์บันทึกของคุณ ต้องการทำเช่นนั้นคุณสามารถใช้ที่ไม่มีเอกสารfn_dblogหรืออ่านบันทึกการทำธุรกรรมเช่นApexSQL เข้าสู่ระบบ

มันไม่ได้แสดงให้เห็นดัชนีปรับโครงสร้าง แต่จะแสดงดราก้อนและกิจกรรมทั้งหมด DDL ต่างๆ: ALTER, CREATE, DROPทริกเกอร์เปิด / ปิดทุน / สิทธิ์เพิกถอนการเปลี่ยนชื่อวัตถุ

คำเตือน: ฉันทำงานให้กับ ApexSQL ในฐานะวิศวกรสนับสนุน

นี่เป็นปัญหาที่พบบ่อยที่สุดสำหรับ DBA เกือบทั้งหมดที่มีการเติบโตของบันทึกและการเติมดิสก์

•อะไรคือสาเหตุของบันทึกการทำธุรกรรมมีขนาดใหญ่มาก?

1. การทำธุรกรรมที่ยาวนาน
2. ธุรกรรมการบันทึกสูงเช่นสร้างดัชนีใหม่จัดระเบียบใหม่แทรกจำนวนมากลบ ฯลฯ
3. HA ใด ๆ เช่นการจำลองแบบการทำมิเรอร์ที่กำหนดค่าซึ่งเก็บบันทึกและไม่อนุญาตให้ปล่อยพื้นที่บันทึก

•ทำไมไฟล์บันทึกของฉันถึงใหญ่มาก?

ตรวจสอบlog_reuse_wait_desคอลัมน์ c ในsys.databasesตารางเพื่อดูว่ามีการเก็บบันทึกอะไรจากการตัดทอน:

select name, log_reuse_wait_desc 
from sys.databases

•มีวิธีใดบ้างที่จะป้องกันไม่ให้เกิดปัญหานี้?

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

•ฉันจะทำอย่างไรเมื่อฉันติดตามตัวเองด้วยสาเหตุที่สำคัญและต้องการทำให้ไฟล์บันทึกธุรกรรมของฉันมีขนาดที่ดี?

หากคุณระบุว่าอะไรเป็นสาเหตุของปัญหาให้ลองแก้ไขตามที่อธิบายไว้ในหน้าด้านล่าง

https://www.brentozar.com/archive/2016/03/my-favorite-system-column-log_reuse_wait_desc/

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