Recovery Model อลเวง ตอนจบ

จากที่ได้แนะนำเรื่อง Recovery Model ซึ่งผ่านมาแล้วด้วยกัน 4 ตอน โดยมีตั้งแต่ www.9ExpertTraining.com/articles/recovery-model-อลเวง-ตอนที่-1 เป็นต้นมา 
ในบทความนี้เราจะมาสรุปเรื่องราวที่น่าสนใจเกี่ยวกับ Recovery Model ดังนี้

ควรใช้งาน Full Recovery Model กับฐานข้อมูลที่ใช้งานจริงๆ บน Production Server แล้วกำหนดให้มีกระแบ็คอัพแบบ Transaction Log Backup เป็นระยะๆ เพื่อให้ไฟล์ Log ถูก Truncate เป็นระยะๆ ด้วย อีกทั้งยังมีแบ็คอัพเก็บไว้ใช้ Restore ได้คราวจำเป็นอีกด้วย 

ส่วน Bulk-Logged Recovery Model ที่ไม่เคยพูดถึงเลยนั้น ก็ทำงานตามชื่อ “Bulk” (ปริมาณมากๆ) ของมันนั่นเอง 
งานแบบไหนที่ต้องถือเป็น Bulk ก็อาทิเช่น การ Import ข้อมูลจำนวนหนึ่งล้านเรคคอร์ด (Records) เข้าสู่ฐานข้อมูลเป็นต้น 
การทำเช่นนั้น จะเป็นการทำคำสั่ง insert into หนึ่งล้านบรรทัด ไฟล์ Log จะถูกบันทึกอย่างรวดเร็ว แม้ว่าจะมีการตั้งให้ไฟล์ Log ลดขนาดเองอัตโนมัติก็ตาม แต่ปริมาณข้อมูลที่เข้ามามากๆ ทำให้กระบวนการขยายขนาดทำงานไม่ทันสุดท้ายก็จะเกิดคอขวด ถ้าประกาศทั้งหนึ่งล้านบรรทัดนั้นเป็นหนึ่งทรานแซคชั่น (Transaction) รายการที่เขียนลงไฟล์ Log ไปแล้วก็จะ Rollback ทิ้งทั้งหมด 

บางครั้งแล้วการ Import ข้อมูลมากมายขนาดนี้ เราก็อาจต้องสั่งให้หยุดการบันทึกลงไฟล์ Log ชั่วคราวโดยการเปลี่ยนจาก Full Recovery Model มาเป็น Bulk-Logged Recovery Model จนการ import ข้อมูลเสร็จสิ้น จึงเปลี่ยนกลับไปเป็น Full Recovery Model อีกครั้ง 



***ติดตามบทความถัดไป Microsoft SQL Server กับ Transaction Log Management ***

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