⚡ This Site is Updated Every Day

Recovery Model อลเวง ตอนที่ 2

 recovery-model-9expert-2

Recovery Model อลเวง ตอนที่ 2

จากตอนที่ 1 ลูกค้าเลือกใช้ ใช้ Full Recovery Model บน Production Server  นั้นถูกต้องครับ แต่ผู้เขียนอยากจะขยายความเพิ่มเติม ถึง Model Recovery ทั้ง 2 แบบ เลยถามต่อในคำถามที่ 2

คำถามที่ 2 แล้วสังเกตเห็นหรือไม่ครับ เมื่อใช้ Simple Recovery Model นั้นขนาดของไฟล์ Log ก็ไม่ได้เพิ่มขึ้นมากมายขนาดนี้ แต่พอเปลี่ยนมาใช้ Full Recovery Model แล้วปรากฏว่าขนาดของไฟล์ Log เพิ่มขึ้นมาก ?

คำตอบที่ 2 “ก็แปลกใจอยู่เหมือนกันครับอาจารย์ แต่พวกผมก็มีวิธีการจัดการกับขนาดของไฟล์ Log ที่มีขนาดเพิ่มขึ้นเรื่อยแบบนี้เหมือนกันนะครับ แต่ไม่ได้ใช้การแบ็คอัพแบบ Transaction Log Backup”

 
การใช้ Simple Recovery Model นั้น ควรใช้ขณะกำลังพัฒนาฐานข้อมูลอยู่ นั้นถูกต้อง เหตุผลก็คือเพื่อลดกระบวนการทำงานให้กับผู้ดูแลฐานข้อมูลเพียงแค่นั้น  
เนื่องจาก Simple Recovery Model มีการดำเนินการที่สำคัญเรียกว่า “truncate log on checkpoint” หรือไฟล์ Log ถูกทำให้สั้นลง (เล็กลง) เมื่อ Checkpoint ทำงาน  ดังนั้นจึงไม่ต้องแบ็คอัพแบบ Transaction Log Backup เพราะมันไม่มีอะไรให้แบ็คอัพนั่นเอง เป็นเพราะได้ถูก Truncate โดยการลบทรานแซคชั่นที่เสร็จสิ้นไปแล้วและเกิดก่อน Checkpoint ตัวล่าสุดทิ้งไปจนหมด เหลือเพียงทรานแซคชั่นที่ยังไม่เสร็จสิ้นเอาไว้ในไฟล์ Log เท่านั้น   
 

แต่หากเลือกใช้ Full Recovery Model ไฟล์ Log ก็จะมีขนาดเพิ่มขึ้นไปเรื่อยๆ เพราะไม่มีการกำหนดให้ไฟล์ถูก Truncate ตามเหตุการณ์ใดอีก ดังนั้น Microsoft จึงได้ออกแบบกฎเกณฑ์การ Truncate ไฟล์ Log เอาไว้ว่าเมื่อใดที่มีการแบ็คอัพแบบ Transaction Log Backup เกิดขึ้น ซึ่งก็คือการแบ็คอัพทุกทรานแซคชั่นในไฟล์ Log ที่เสร็จสิ้นไปแล้วและเกิดก่อน Checkpoint ตัวล่าสุดเอาไว้ จากนั้นก็ให้ Truncate ส่วนนี้ทิ้งเสีย เพราะมั่นใจได้แล้วว่ามีทรานแซคชั่นเหล่านั้นถูกเก็บไว้อย่างปลอดภัยและสามารถนำมาใช้ Restore เมื่อจำเป็นได้ 

ทีนี้จะเกิดอะไรขึ้น ถ้านำ Simple Recovery Model ไปใช้กับ บน Production Server   
เนื่องจากหากใช้ Simple Recovery Model จะไม่สามารถแบ็คอัพแบบ Transaction Log Backup ได้ ตามที่กล่าวไปแล้วก่อนหน้านี้ ดังนั้นถ้าระบบเกิดล่มไป แม้ว่าระบบสามารถใช้ Checkpoint ช่วยทำ Automatic Recovery ได้ แต่หากไฟล์ข้อมูลเกิดความเสียหายขึ้น จะไม่สามารถ Restore ข้อมูลกลับมา จนถึงเวลาที่ระบบเสียหายได้เลย ข้อมูลที่ถูก Restore กลับมาได้ เป็นเพียงข้อมูลที่ถูกแบ็คอัพไว้โดย Full Database Backup และ Differential Database เท่านั้น เป็นสาเหตุให้ข้อมูลอาจสูญหายได้

จึงสรุปอย่างง่ายๆ ว่า หากจะใช้ Full Recovery Model ก็ต้องมีการแบ็คอัพแบบ Transaction Log Backup เป็นระยะไฟล์ Log ก็จะถูก Truncate เป็นระยะเช่นกัน และขนาดไฟล์ Log ก็สามารถควบคุมไม่ให้ขยายใหญ่ขึ้นเกินความจำเป็นได้ แต่เมื่ออยู่ในขณะกำลังพัฒนาฐานข้อมูล ก็ไม่จำเป็นต้องมาแบ็คอัพแบบ Transaction Log Backup ให้วุ่นวาย จึงใช้เป็น Simple Recovery  Model จะดีกว่าเพราะมีการทำ “truncate log on checkpoint” นั่นเอง

ในบทความตอนที่ 2 นี้ ผู้อ่านจะเห็นคำว่า Checkpoint บ่อย ๆ  Checkpoint คืออะไร ? และ เนื่องจากในคำตอบที่ 2 ของลูกค้า ไม่ได้ใช้การแบ็คอัพแบบ Transaction Log Backup

ดังนั้น คำถามถัดไปที่ผู้เขียนถามต่อ คือ มีวิธีการอื่นอีกหรือ ถ้าไม่ได้ใช้การแบ็คอัพแบบ Transaction Log Backup แล้วคุณใช้อะไรช่วยในการ Truncate กัน ? 
มาดูคำตอบของคำถามนี้ และ ความหมายของ Checkpoint กัน โดยติดตามต่อใน Recovery Model อลเวง ตอนที่ 3 ครับ

หลักสูตรที่เกี่ยวข้อง https://www.9experttraining.com/microsoft-sql-server-database-administration-training-course

บทความโดย
อาจารย์ภัคพงศ์ กฤตวัฒน์
วิทยากรดูแลและออกแบบหลักสูตร
กลุ่มวิชา SQL Server/Window Server

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.