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

ก่อนที่จะกล่าวเพิ่มเติมถึง  การ Truncate กับ VLFs   ผู้อ่านต้องเข้าใจเกี่ยวกับ Transaction Log เสียก่อนว่า
ไฟล์ Transaction Log ใช้บันทึกข้อมูล Transaction ตามที่ผู้เขียนเล่าให้ฟังแล้วว่าก็คือบรรดากลุ่มคำสั่งในการ Insert, Update และ Delete ข้อมูลนั่นเอง
และเป็นด่านแรกในการบันทึกข้อมูลลงดิสก์ในระบบฐานข้อมูล (ซึ่งเกิดก่อนการบันทึกลง Data File เสียอีกตามหลักการของ WAL Protocol ดูเพิ่มเติมใน Recovery Model อลเวง ตอนที่ 3)

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

การ Truncate ไฟล์ Transaction Log คือ การลบ VLFs ที่ใช้แล้ว และกลายเป็น non-active ทิ้งไปเสีย
การทำแบบนี้ก็เหมือนกับการฉีกไฟล์ Transaction Log บางส่วนทิ้งไป ทำให้ไฟล์ Transaction Log ขาดข้อมูลก่อนหน้าไปเรื่อยๆ
หากการฉีกทิ้งนี้เป็นการฉีกทิ้งไปเลย เมื่อถึงคราวที่จำเป็นต้อง Restore และ Recovery กลับไปยังช่วงเวลาที่ถูกฉีกทิ้งไปจะทำไม่ได้ (ซึ่งก็คือการเปิดใช้ Simple Recovery Model นั่นเอง)
แต่หากการฉีกทิ้งนั้นเป็นการฉีกแล้วไปเก็บเอาไว้ หากจำเป็นต้องกลับมาอ่านเพื่อ Restore และ Recovery ก็ยังสามารถทำได้เพียงแต่เพิ่มขั้นตอนนิดหน่อย แต่ก็ถือว่าปลอดภัยกว่า (ซึ่งก็คือการเปิดใช้ Full Recovery Model หรือ Bulk-Logged Recovery Model นั่นเอง)
โดยใน Full Recovery Model หรือ Bulk-Logged Recovery Model ส่วนของ VLFs ที่ใช้แล้ว และกลายเป็น non-active จะถูก Truncate ทิ้งได้ก็ต่อเมื่อมีการ Backup ในส่วนของ VLFs นั้นเสร็จสิ้นแล้ว
ซึ่งก็คือการ Transaction Log Backup นั่นเอง ดังนั้นการ Backup Transaction Log จะช่วยส่งผลต่อขนาดของไฟล์ Transaction Log File (.ldf) ด้วย ด้วยเหตุผลที่กล่าวมา

จากรูปเป็นการคือรายละเอียดการ Backup ฐานข้อมูล TestTLOG โดยผลลัพธ์แรกเป็นรายละเอียดของ FULL Backup
และผลลัพธ์ที่ 2-5 เป็นรายละเอียดของ Transaction Log Backup จะเห็นว่า LSN ของไฟล์ Transaction Log Backup จะเรียงต่อกัน
(สังเกตจาก Last LSN ของ Backup ก่อนหน้าจะเป็น First LSN ของการ Backup ตัวต่อไป) จึงเป็นเหตุผลว่าทำไมเวลาผู้อ่านจะ Restore ต้องเรียงตามลำดับก่อนหลังของ Transaction Log Backup ด้วย
และห้าม recovery กลางคัน เพราะหาก recovery ตรงไหนการ restore ก็จะสิ้นสุดลงตรงนั้นทันที ยกเว้นว่าตั้งใจให้เป็นเช่นนั้น หากยัง Restore ไปไม่ถึง Transaction Log Backup ตัวสุดท้าย
แต่ผู้อ่านไม่ต้องกังวลว่าจะทำให้เกิดความยุ่งยากและสับสนหากผู้อ่านได้ใช้หลักการของ Backup Media Set ที่ Microsoft SQL Server จัดเตรียมไว้ให้
(ผู้เขียนเปิดให้มีการอภิปรายเรื่องนี้โดยละเอียดกับผู้เข้าฝึกอบรม และทดลองจริงผ่านแบบฝึกหัดในขณะฝึกอบรม)

ดังนั้นกระบวนการทำงานกับ Transaction Log ก็จะมีความเกี่ยวข้องกับการตั้งค่า Recovery Model (ซึ่งติดตามได้จากบทความ Recovery อลเวง ทั้ง 4 ตอนได้) การ Backup Transaction Log จึงมีความสำคัญ และสัมพันธ์กับการกำหนดค่าดังกล่าว ว่าจะเสมือนกับการฉีกไฟล์ในส่วนที่เป็น Non-Active ซึ่งจะให้สามารถกู้กลับมาได้ถึงวินาทีสุดท้ายที่ Backup ก็จะต้องวางแผนและ กำหนดค่า Recovery Model ให้ถูกต้องด้วย

จากบทความ Microsoft SQL Server กับ Transaction Log Management ทั้ง 3 ตอนทำให้เราได้รู้จักกับ Transaction Log มากขึ้นพร้อมทั้งการบริหารจัดการ เข้าใจการทำงานในระดับไฟล์ ความสัมพันธ์ระหว่างการ Backup และ Recovery Model ด้วย เพื่อให้การทำงานกับฐานข้อมูล Microsoft SQL Server มีประสิทธิภาพ และนำไปใช้ในงานจริงได้ น่าจะเป็นประโยชน์สำหรับทุกๆ ท่าน และโปรดคอยติดตามบทความดีๆ ได้อีกที่ https://www.9experttraining.com/articles ครับ