การลดขนาดไฟล์บันทึกของ SQL Server มีผลต่อประสิทธิภาพอย่างไร


19

ฉันมีฐานข้อมูล SQL Server 2008 ที่มีไฟล์ข้อมูลขนาด 2GB บางส่วน แต่ไฟล์บันทึกมีขนาดเกิน 8GB ด้วยฐานข้อมูลก่อนปี 2551 ฉันสามารถใช้ 'บันทึกการสำรองข้อมูล' และTRUNCATE_ONLYตัวเลือก แต่ไม่สามารถใช้งานได้กับฐานข้อมูล 2008 และใหม่กว่า

ฉันมีสคริปต์ที่ตัดทอนไฟล์บันทึก:

USE [MyDatabase]
GO
ALTER DATABASE [MyDatabase] SET RECOVERY SIMPLE WITH NO_WAIT
DBCC shrinkfile('MyDatabase_log', 1)
ALTER DATABASE [MyDatabase] SET RECOVERY FULL WITH NO_WAIT
GO

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

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

คำตอบ:


26

ฉันขอแนะนำให้อ่านความสำคัญของการจัดการขนาดบันทึกการทำธุรกรรมที่เหมาะสมโดย Paul S. Randal

แก่นสารคือว่ามีเพียงสองวิธีที่ดีในการจัดการบันทึกธุรกรรม :

  1. ไปกับการสำรองข้อมูลแฟ้มบันทึกปกติและแฟ้มบันทึกจะนำมาใช้ใหม่เป็นพื้นที่หลังจากการสำรองข้อมูลแฟ้มบันทึกแต่ละครั้งและจะไม่ขยายไปเรื่อย ๆ หรือ

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

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

ถ้าคุณลดขนาดบันทึกมันจะเพิ่มขึ้นอีกครั้ง - อาจทำให้เกิดการแตกแฟรกเมนต์ของ VLF และทำให้ภาระงานของคุณหยุดชั่วคราวในขณะที่บันทึกเติบโตขึ้นเนื่องจากบันทึกไม่สามารถใช้การเริ่มต้นได้ทันที [... ]

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


URL เป็นสาเหตุที่คุณไม่ควรลดขนาดไฟล์ข้อมูลของคุณมีการเปลี่ยนแปลง sqlskills.com/blogs/paul/…
ripvlan

ตามที่มี URL เพื่อความสำคัญของการจัดการขนาดบันทึกการทำธุรกรรมที่เหมาะสม: sqlskills.com/blogs/paul/…
ripvlan

6

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

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

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


4

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

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


บันทึกใช้เวลาประมาณ 4-6 เดือนในการรับขนาดนี้ดังนั้นจึงไม่เร็วมาก ฉันคิดว่า (อาจไม่ถูกต้อง) ว่าไฟล์บันทึกมีการทำธุรกรรมระหว่างการสำรองข้อมูลเต็มรูปแบบนั่นคือเหตุผลที่ฉันกล่าวว่าฉันทำการสำรองข้อมูลเต็มรูปแบบ 2 ครั้งต่อวันดังนั้นเนื้อหาของบันทึกระหว่างไม่สามารถมากเกินไป ดังที่ฉันพูดฉันอาจเข้าใจผิดแนวคิดของไฟล์บันทึก
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.