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

ในบทความตอนที่แล้ว มีคำว่า Checkpoint หลายจุด เช่น
ถ้าเป็น Simple Recovery Model จะมีการ “Truncate log on checkpoint”

ดังนั้นบทความนี้จึงขออธิบายความหมายของ Checkpoint โดยย่อ ๆ ดังนี้ครับ

Checkpoint คือจุดอ้างอิงที่เกิดขึ้นเป็นระยะๆ ที่ถูกบันทึกลงในไฟล์ Log เพื่อเป็นจุดอ้างอิงให้กับ 2 กระบวนการหลัก ซึ่งได้แก่

1.กระบวนการ Automatic Recovery  เป็นกระบวนการฟื้นฟูระบบกลับคืนมาหากระบบเกิดล่มไปแต่รีบูต (Reboot) กลับคืนมาได้ เมื่อ SQL Server กำลังเปิดให้บริการกระบวนการ Automatic Recovery จะดำเนินการจนเสร็จสิ้นเสียก่อนที่จะปล่อยให้ผู้ใช้เข้าใช้งานฐานข้อมูล

2.สนับสนุน WAL (write ahead log) Protocol เป็นโปรโตคอลที่รับประกันว่าเมื่อมีการ Insert , Update หรือ Delete ข้อมูลเข้าสู่ฐานข้อมูล ข้อมูลเหล่านั้นจะถูกบันทึกลงบนแหล่งจัดเก็บข้อมูลแบบ Non-Volatile Memory
อาทิเช่น ฮาร์ดดิสก์ นั่นเอง ผู้เขียนเน้นว่า WAL Protocol  นั้นรับประกันว่าข้อมูลต้องถูกเขียนลงบนดิสก์ แต่ไม่ได้บอกว่าเขียนลงในไฟล์ข้อมูลแต่อย่างใด ขอแค่เขียนลงตรงไหนก็ได้ที่ Non-Volatile Memory ก็รับประกันได้แล้วว่าข้อมูลจะไม่หายไปไหนเมื่อไฟเกิดดับแล้วระบบล่ม ในกรณีของ Microsoft SQL Server จะเขียนลงบนไฟล์ Transaction Log (ในกรณีของ Oracle จะเรียกว่า Online Redo Log)

ซึ่งบทความถัด ๆๆ ไป จะเป็นรายละเอียดการทำงานและความสำคัญของ ไฟล์ Transaction Log, จุด Checkpoint, กระบวนการ Automatic Recovery และ WAL Protocol  รอติดตามนะครับ

ต่อมาว่าด้วยเรื่อง Backup กันต่อ เนื่องจาก Full Recovery Model ต้องแบ็คอัพแบบ Transaction Log Backup  แต่ลูกค้าไม่ใช้วิธีนี้  จึงทำให้ผู้เขียนถามคำถามที่ 3  ขึ้นมา

คำถามที่ 3 มีวิธีการอื่นอีกหรือ ถ้าไม่ได้ใช้การแบ็คอัพแบบ Transaction Log Backup แล้วคุณใช้อะไรช่วยในการ Truncate ครับ ?

คำตอบที่ 3 “ง่ายมากครับพวกผมก็เปลี่ยนจาก Full Recovery Model ไปเป็น Simple Recovery Model แล้วทิ้งไว้สักครู่ ไฟล์ Log ก็จะถูก Truncate แล้วจึงเปลี่ยนกลับไปเป็น Full Recovery Model”

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

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

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

ยังเหลืออีก 1 คำถาม ติดตามต่อใน Recovery Model อลเวง ตอนที่ 4 ครับ

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