1. บทนำสู่ SQL Server การขนส่งท่อนซุง
1.1 คืออะไร SQL Server การขนส่งไม้ซุง?
SQL Server การส่งบันทึกธุรกรรม (Log Shipping) เป็นโซลูชันการกู้คืนระบบอัตโนมัติที่ช่วยรักษาสำเนาสำรองที่พร้อมใช้งาน (Warm Standby) ของฐานข้อมูลที่ใช้งานจริง เทคโนโลยีนี้จะถ่ายโอนข้อมูลสำรองบันทึกธุรกรรมจากฐานข้อมูลหลักบนเซิร์ฟเวอร์หลักไปยังฐานข้อมูลรองหนึ่งฐานหรือมากกว่าบนเซิร์ฟเวอร์รองที่แยกต่างหาก เพื่อให้มั่นใจว่าฐานข้อมูลรองของคุณยังคงซิงโครไนซ์กับฐานข้อมูลหลัก ป้องกันการสูญเสียข้อมูลและความล้มเหลวของเซิร์ฟเวอร์
1.2 วัตถุประสงค์และประโยชน์ของการขนส่งท่อนซุง
การส่งบันทึกข้อมูล (Log shipping) มีประโยชน์อย่างยิ่งหลายประการในการบริหารจัดการฐานข้อมูล:
- บทบาทหลักของมันคือการกู้คืนระบบในกรณีเกิดภัยพิบัติ โดยทำหน้าที่เป็นเป้าหมายสำรองที่เชื่อถือได้เมื่อเซิร์ฟเวอร์หลักของคุณไม่สามารถใช้งานได้เนื่องจากความล้มเหลวของฮาร์ดแวร์ ความเสียหายของซอฟต์แวร์ หรือเหตุการณ์ร้ายแรงที่ส่งผลกระทบต่อศูนย์ข้อมูลของคุณ
- นอกจากนี้ยังประหยัดค่าใช้จ่ายอีกด้วย โซลูชันที่มีความพร้อมใช้งานสูงต่างจากฟีเจอร์ระดับองค์กรที่ต้องใช้ใบอนุญาตราคาแพง การส่งบันทึกข้อมูลใช้งานได้กับ... SQL Server รุ่นมาตรฐาน ทำให้องค์กรที่มีงบประมาณจำกัดสามารถเข้าถึงได้
- ฐานข้อมูลสำรองในโหมดสแตนด์บายให้คุณค่าเพิ่มเติมมากกว่าแค่การกู้คืนจากภัยพิบัติ ผู้ดูแลระบบฐานข้อมูลสามารถใช้ฐานข้อมูลเหล่านี้สำหรับการรายงานแบบอ่านอย่างเดียว และลดภาระงานการสืบค้นข้อมูลจากเซิร์ฟเวอร์หลักได้
- คุณสมบัติการกู้คืนแบบหน่วงเวลาช่วยป้องกันการแก้ไขข้อมูลโดยไม่ตั้งใจ โดยการกำหนดค่าการหน่วงเวลาการกู้คืน คุณจะสร้างช่วงเวลาในการกู้คืนจากข้อผิดพลาดของผู้ใช้ก่อนที่การเปลี่ยนแปลงที่ก่อให้เกิดความเสียหายจะส่งผลกระทบต่อฐานข้อมูลสำรองของคุณ
2. SQL Server ส่วนประกอบและขั้นตอนการทำงานของการขนส่งโลจิสติกส์
การขนส่งไม้ซุงประกอบด้วยส่วนประกอบดังต่อไปนี้:
- เซิร์ฟเวอร์หลักและฐานข้อมูลหลัก: เซิร์ฟเวอร์หลักแสดงถึงระบบการใช้งานจริงของคุณ SQL Server อินสแตนซ์ที่ใช้งานฐานข้อมูลหลัก
- พื้นที่จัดเก็บสำรอง: ตำแหน่งกลางสำหรับจัดเก็บและถ่ายโอนข้อมูลสำรองบันทึกธุรกรรมจากเซิร์ฟเวอร์หลักไปยังเซิร์ฟเวอร์รอง
- เซิร์ฟเวอร์รองและฐานข้อมูลรอง: เซิร์ฟเวอร์รองทำหน้าที่เป็นที่เก็บสำเนาสำรอง (warm standby) ของฐานข้อมูลหลักของคุณ
- เซิร์ฟเวอร์ตรวจสอบ (ไม่บังคับ): เซิร์ฟเวอร์นี้จะติดตามประวัติและสถานะของการสำรองข้อมูล คัดลอก และกู้คืนข้อมูลทั้งหมดในโครงสร้างการส่งบันทึกข้อมูลของคุณ
- งานของเอเจนต์: รวมถึงงานสำรองข้อมูล คัดลอก กู้คืน และแจ้งเตือน ซึ่งทำให้กระบวนการส่งบันทึกข้อมูลทั้งหมดเป็นไปโดยอัตโนมัติ
ขั้นตอนการทำงานของระบบอัตโนมัติมีดังนี้:
- กระบวนการสำรองข้อมูลจะทำงานบนเซิร์ฟเวอร์หลักและสร้างสำเนาสำรองบันทึกธุรกรรมของฐานข้อมูลหลักบนพื้นที่จัดเก็บข้อมูลสำรอง
- กระบวนการคัดลอกจะทำงานบนเซิร์ฟเวอร์รองแต่ละเครื่อง และถ่ายโอนไฟล์สำรองข้อมูลบันทึกจากโฟลเดอร์สำรองข้อมูลไปยังเซิร์ฟเวอร์รอง
- กระบวนการกู้คืนจะทำงานบนเซิร์ฟเวอร์รองแต่ละเครื่อง และนำสำเนาสำรองบันทึกธุรกรรมไปใช้กับฐานข้อมูลรอง
- ระบบแจ้งเตือนจะทำงานบนเซิร์ฟเวอร์ตรวจสอบ และตรวจสอบว่าการสำรองข้อมูลและการกู้คืนเสร็จสมบูรณ์ภายในกรอบเวลาที่ยอมรับได้หรือไม่
3. คุณสมบัติเบื้องต้นและข้อกำหนด
3.1 SQL Server ข้อกำหนดเวอร์ชัน
การขนส่งท่อนซุงมีให้บริการมาตั้งแต่ปี SQL Server ตั้งแต่ปี 2000 และยังคงได้รับการสนับสนุนในเวอร์ชันต่อๆ มาทั้งหมด SQL Server ตั้งแต่ปี 2005 ถึง 2025 การสนับสนุนอย่างต่อเนื่องยาวนานนี้แสดงให้เห็นถึงความเสถียรและความสำคัญอย่างต่อเนื่องของเทคโนโลยีนี้
3.2 SQL Server ข้อกำหนดของฉบับพิมพ์
การส่งบันทึกข้อมูลใช้งานได้กับ Standard, Workgroup, Enterprise และ Developer editions ของ SQL Serverการรองรับเวอร์ชันที่ครอบคลุมนี้ทำให้การส่งบันทึกข้อมูลสามารถเข้าถึงได้สำหรับองค์กรที่ไม่มีใบอนุญาต Enterprise Edition ซึ่งแตกต่างจากคุณสมบัติอื่นๆ เช่น เสมอในกลุ่มความพร้อมใช้งาน ที่ต้องใช้รุ่น Enterprise หรือ Evaluation
หมายเหตุ: Express Edition ไม่รองรับการส่งบันทึกข้อมูล (log shipping)
3.3 ข้อกำหนดของแบบจำลองการกู้คืนฐานข้อมูล
การส่งบันทึกข้อมูล (Log shipping) จำเป็นต้องใช้รูปแบบการกู้คืนแบบเต็ม (Full recovery model) หรือรูปแบบการกู้คืนแบบบันทึกข้อมูลจำนวนมาก (Bulk-logged recovery model) ในฐานข้อมูลหลัก รูปแบบการกู้คืนแบบง่าย (Simple recovery model) ไม่ได้รับการสนับสนุนเนื่องจาก... SQL Server ระบบจะตัดทอนไฟล์บันทึกธุรกรรมโดยอัตโนมัติ ทำให้ห่วงโซ่บันทึกต่อเนื่องที่จำเป็นสำหรับการส่งบันทึกขาดตอนไป
สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับรูปแบบการฟื้นฟู โปรดดูที่หน้าของเรา คู่มือที่ครอบคลุมเกี่ยวกับ SQL Server การสำรองข้อมูล.
4. การกำหนดค่าการส่งบันทึกข้อมูลโดยใช้ SSMS
ก่อนกำหนดค่าการส่งไฟล์บันทึกธุรกรรม โปรดเตรียมโฟลเดอร์แชร์สำรองข้อมูลที่จะใช้จัดเก็บและถ่ายโอนไฟล์บันทึกธุรกรรม
- บนเซิร์ฟเวอร์หลักหรือเซิร์ฟเวอร์ไฟล์เฉพาะ ให้สร้างโฟลเดอร์ (เช่น ซีดี:\สำรองข้อมูล)
- คลิกขวาที่โฟลเดอร์และเลือก อสังหาริมทรัพย์
- คลิก ใช้งานร่วมกัน แถบ
- คลิก การแบ่งปันขั้นสูง
- ตรวจสอบ แชร์โฟลเดอร์นี้
- คลิก สิทธิ์ และเงินช่วยเหลือ ควบคุมทั้งหมด อนุญาตให้ SQL Server บัญชีบริการ บริการ NT\MSSQLSERVER
- คลิก OK เพื่อนำไปใช้.
- บันทึกเส้นทางเครือข่าย (UNC) (เช่น \\ชื่อเซิร์ฟเวอร์\สำรองข้อมูล)
4.2 การเปิดใช้งานและการกำหนดค่าการส่งบันทึกข้อมูล
- คลิกขวาที่ฐานข้อมูลหลักแล้วเลือก อสังหาริมทรัพย์ .
- ตัว Vortex Indicator ได้ถูกนำเสนอลงในนิตยสาร คุณสมบัติของฐานข้อมูล กล่องโต้ตอบให้เลือกไฟล์ บันทึกธุรกรรมการจัดส่ง หน้าในแผงด้านซ้าย
- ตรวจสอบ เปิดใช้งานฐานข้อมูลนี้เป็นฐานข้อมูลหลักในการกำหนดค่าการส่งบันทึก (Log Shipping) เพื่อเปิดใช้งานการส่งบันทึกข้อมูล
- จากนั้นคุณสามารถกำหนดค่าการตั้งค่าการสำรองข้อมูล เซิร์ฟเวอร์รอง และเซิร์ฟเวอร์ตรวจสอบได้ในหน้าคุณสมบัตินี้ เราจะอธิบายรายละเอียดในหัวข้อถัดไป
4.2.1 กำหนดค่าการตั้งค่าการสำรองข้อมูล
- คลิก การตั้งค่าสำรอง ปุ่ม
- ตัว Vortex Indicator ได้ถูกนำเสนอลงในนิตยสาร การตั้งค่าการสำรองข้อมูลบันทึกธุรกรรม บทสนทนา ภายใต้ เส้นทางเครือข่ายไปยังโฟลเดอร์สำรองข้อมูล ช่องดังกล่าว ให้ป้อนเส้นทาง UNC (เช่น \\ชื่อเซิร์ฟเวอร์\สำรองข้อมูล)
- หากโฟลเดอร์สำรองข้อมูลอยู่บนเซิร์ฟเวอร์หลัก ให้ป้อนพาธในเครื่อง (เช่น ซีดี:\สำรองข้อมูล)
- กำหนดค่าการตั้งค่าอื่นๆ เช่น ระยะเวลาการเก็บรักษาข้อมูลสำรอง เกณฑ์การแจ้งเตือน งานสำรองข้อมูล และการบีบอัดข้อมูล
- คลิก OK เพื่อยืนยันการตั้งค่าและปิดหน้าต่างโต้ตอบ
4.2.2 การกำหนดค่าอินสแตนซ์เซิร์ฟเวอร์รองและฐานข้อมูล
- คลิก เพิ่ม ภายใต้ อินสแตนซ์เซิร์ฟเวอร์รองและฐานข้อมูล
- ตัว Vortex Indicator ได้ถูกนำเสนอลงในนิตยสาร การตั้งค่าฐานข้อมูลรอง โต้ตอบคลิก ติดตามเราได้ที่ เพื่อเชื่อมต่อกับอินสแตนซ์เซิร์ฟเวอร์รอง
- ตัว Vortex Indicator ได้ถูกนำเสนอลงในนิตยสาร ฐานข้อมูลรอง เลือกฐานข้อมูลที่มีอยู่แล้วจากเมนูแบบเลื่อนลง หรือพิมพ์ชื่อฐานข้อมูลใหม่
- ตัว Vortex Indicator ได้ถูกนำเสนอลงในนิตยสาร กำลังเริ่มต้นฐานข้อมูลรอง เลือก ใช่แล้ว สร้างสำเนาสำรองแบบเต็มของฐานข้อมูลหลัก แล้วกู้คืนไปยังฐานข้อมูลสำรอง (และสร้างฐานข้อมูลสำรองหากยังไม่มีอยู่)
- คลิก คัดลอกไฟล์ แถบ
- ตัว Vortex Indicator ได้ถูกนำเสนอลงในนิตยสาร โฟลเดอร์ปลายทางสำหรับไฟล์ที่คัดลอก (โดยปกติโฟลเดอร์นี้จะอยู่บนเซิร์ฟเวอร์สำรอง)ป้อนพาธภายในเครื่องของโฟลเดอร์ปลายทางบนเซิร์ฟเวอร์รอง
- ตรวจสอบให้แน่ใจว่าโฟลเดอร์นั้นมีอยู่จริงและ SQL Server บัญชีบริการมีสิทธิ์ในการเขียน
- คลิก OK เพื่อยืนยันการตั้งค่าและปิดหน้าต่างโต้ตอบ
4.2.3 การกำหนดค่าเซิร์ฟเวอร์มอนิเตอร์
- ตรวจสอบ ใช้เซิร์ฟเวอร์มอนิเตอร์อินสแตนซ์
- คลิก การตั้งค่า
- คลิก ติดตามเราได้ที่ เพื่อเชื่อมต่อกับอินสแตนซ์เซิร์ฟเวอร์มอนิเตอร์
- ชุด ลบประวัติหลังจาก เพื่อระบุระยะเวลาการเก็บรักษาเป็นชั่วโมง
- คลิก OK เพื่อยืนยันการตั้งค่าและปิดหน้าต่างโต้ตอบ
4.2.4 การตรวจสอบและดำเนินการกำหนดค่าให้เสร็จสมบูรณ์
- ตรวจสอบการตั้งค่าทั้งหมด บันทึกธุรกรรมการจัดส่ง หน้า
- ตรวจสอบการตั้งค่าการสำรองข้อมูล การกำหนดค่าเซิร์ฟเวอร์รอง และการตั้งค่าการตรวจสอบ
- คลิก OK เพื่อใช้การตั้งค่า
- ตัวช่วยสร้างจะสร้างงานที่จำเป็นทั้งหมดบนเซิร์ฟเวอร์หลัก เซิร์ฟเวอร์รอง และเซิร์ฟเวอร์ตรวจสอบ
- คลิก ปิดหน้านี้ เมื่อการกำหนดค่าเสร็จสมบูรณ์
5. ข้อดีและข้อเสียของการขนส่งไม้ซุง
5.1 ประโยชน์ของ SQL Server การขนส่งท่อนซุง
- โซลูชันที่คุ้มค่า: ทำงานร่วมกับ SQL Server รุ่นมาตรฐาน (Standard Edition) ช่วยลดข้อกำหนดด้านลิценส์ราคาแพงของรุ่นองค์กร (Enterprise Edition) ทำให้องค์กรที่มีงบประมาณจำกัดสามารถกู้คืนระบบจากภัยพิบัติได้อย่างน่าเชื่อถือ
- ตั้งค่าและบำรุงรักษาง่าย: วิซาร์ดการกำหนดค่าจะแนะนำผู้ดูแลระบบในการตั้งค่าด้วยตัวเลือกที่ชัดเจน ฐานข้อมูลส่วนใหญ่สามารถกำหนดค่าได้ภายใน 15-30 นาทีโดยไม่จำเป็นต้องมีการฝึกอบรมเฉพาะทาง
- รองรับเซิร์ฟเวอร์รองหลายเครื่อง: รองรับเซิร์ฟเวอร์สำรองจำนวนมากโดยไม่มีข้อจำกัดทางสถาปัตยกรรม ติดตั้งเซิร์ฟเวอร์สำรองหนึ่งเครื่องสำหรับกู้คืนข้อมูลในกรณีเกิดภัยพิบัติในพื้นที่ อีกเครื่องสำหรับใช้งานระยะไกล และเครื่องที่สามสำหรับการรายงาน
- ผลกระทบต่อเซิร์ฟเวอร์หลักน้อยที่สุด: ทำงานแบบอะซิงโครนัส ช่วยลดภาระการซิงโครไนซ์บนเซิร์ฟเวอร์หลัก เวลาในการยืนยันธุรกรรมยังคงไม่เปลี่ยนแปลง
- ใช้ข้อมูลสำรองบันทึกธุรกรรมที่มีอยู่แล้ว: การสำรองข้อมูล Log shipping เป็นการสำรองข้อมูลบันทึกธุรกรรมมาตรฐาน ซึ่งสามารถใช้สำหรับการกู้คืนข้อมูล ณ จุดเวลาใดเวลาหนึ่ง โดยไม่ขึ้นอยู่กับ Log shipping
- ตัวเลือกการกู้คืนแบบหน่วงเวลา: คุณสมบัติการหน่วงเวลาการกู้คืนให้การป้องกันการแก้ไขข้อมูลโดยไม่ตั้งใจ ซึ่งไม่มีใน โซลูชันการจำลองแบบเรียลไทม์.
- ไม่จำเป็นต้องใช้พื้นที่จัดเก็บข้อมูลร่วมกัน: ใช้พื้นที่จัดเก็บข้อมูลอิสระบนเซิร์ฟเวอร์แต่ละเครื่อง ช่วยลดความต้องการพื้นที่จัดเก็บข้อมูลร่วมกันและค่าใช้จ่ายที่เกี่ยวข้อง
- การสนับสนุนข้ามแพลตฟอร์ม: ใช้งานได้เหมือนกันทั้งบน Windows และ Linux SQL Server การปรับใช้
- ใช้งานได้หลากหลายโดเมน: ไม่จำเป็นต้องมีความสัมพันธ์ด้านความเชื่อถือระหว่างโดเมนหรือการผสานรวมกับ Active Directory
5.2 ข้อเสียและข้อจำกัดของการขนส่งไม้ซุง
- ไม่มีการสลับระบบอัตโนมัติเมื่อเกิดข้อผิดพลาด: ข้อจำกัดหลักคือความจำเป็นในการสลับระบบสำรองด้วยตนเอง ผู้ดูแลระบบต้องดำเนินการหลายขั้นตอนก่อนที่บริการจะกลับมาใช้งานได้อีกครั้ง
- ความล่าช้าในการซิงโครไนซ์ข้อมูล: ฐานข้อมูลสำรองมักจะมีความถี่ในการสำรองข้อมูลและกู้คืนข้อมูลน้อยกว่าฐานข้อมูลหลักเสมอ
- การกำหนดค่าระดับฐานข้อมูลเท่านั้น: กำหนดค่าที่ระดับฐานข้อมูล แทนที่จะเป็นระดับอินสแตนซ์ การปกป้องฐานข้อมูล 50 ฐาน ต้องใช้การกำหนดค่าแยกกัน 50 รายการ
- การแก้ไขสตริงการเชื่อมต่อด้วยตนเอง: แอปพลิเคชันต้องอัปเดตสตริงการเชื่อมต่อให้ชี้ไปยังเซิร์ฟเวอร์สำรองหลังจากเกิดการสลับไปใช้เซิร์ฟเวอร์สำรอง
- การขัดจังหวะฐานข้อมูลรอง: ฐานข้อมูลสำรองในโหมดสแตนด์บายจะตัดการเชื่อมต่อผู้ใช้ระหว่างการดำเนินการกู้คืน
- การจัดการฐานข้อมูลแยกต่างหาก: การกำหนดค่าฐานข้อมูลแต่ละรายการจะต้องได้รับการจัดการแยกกัน โดยไม่มีความสามารถในการจัดการแบบบูรณาการ
6. แนวปฏิบัติที่ดีที่สุดและกรณีศึกษา
6.1 เมื่อใดควรใช้การขนส่งแบบ Log Shipping
- การฟื้นฟูหลังภัยพิบัติด้วยงบประมาณจำกัด: โดดเด่นในฐานะโซลูชันการกู้คืนระบบหลังภัยพิบัติที่มีประสิทธิภาพด้านต้นทุน สำหรับองค์กรที่ไม่สามารถจ่ายค่าลิขสิทธิ์เวอร์ชัน Enterprise Edition ได้
- ข้อกำหนด RPO/RTO ระดับปานกลาง: แอปพลิเคชันที่ยอมรับการสูญเสียข้อมูลได้ 15-30 นาที และเวลาหยุดทำงาน 30-60 นาที นั้นสอดคล้องกับความสามารถของอุปกรณ์นี้อย่างสมบูรณ์แบบ
- เซิร์ฟเวอร์รายงานแบบอ่านอย่างเดียว: สร้างสำเนาแบบอ่านอย่างเดียวสำหรับเวิร์กโหลดการรายงานที่ยอมรับการตัดการเชื่อมต่อเป็นระยะๆ
- สภาพแวดล้อมเวอร์ชันมาตรฐาน: องค์กรต่างๆ ได้กำหนดมาตรฐานไว้แล้ว SQL Server รุ่น Standard Edition ไม่สามารถเข้าถึง Always On Availability Groups ได้ ทำให้การส่งบันทึกข้อมูล (log shipping) เป็นตัวเลือกที่ดีที่สุดที่มีอยู่
- โครงการย้ายเซิร์ฟเวอร์: ช่วยให้การย้ายเซิร์ฟเวอร์เป็นไปอย่างราบรื่น โดยรักษาสำเนาข้อมูลที่ซิงโครไนซ์กันไว้ตลอดช่วงเวลาเปลี่ยนผ่าน
- ข้อกำหนดข้อมูลที่ล่าช้า: กำหนดค่าการหน่วงเวลาการกู้คืนเพื่อรักษาฐานข้อมูลให้อยู่ที่จุดเวลาคงที่ในอดีตเพื่อวัตถุประสงค์ด้านการปฏิบัติตามกฎระเบียบหรือการตรวจสอบ
6.2 กรณีที่ไม่ควรใช้การขนส่งแบบ Log Shipping
- ข้อกำหนดด้านเวลาหยุดทำงานเกือบเป็นศูนย์: แอปพลิเคชันที่มีข้อกำหนด RTO ต่ำกว่า 15 นาที ไม่สามารถพึ่งพาการสลับระบบอัตโนมัติด้วยตนเองได้
- จำเป็นต้องมีการสลับระบบอัตโนมัติเมื่อเกิดข้อผิดพลาด: ไม่เหมาะสมเมื่อข้อกำหนดทางธุรกิจบังคับให้มีการสลับระบบอัตโนมัติโดยไม่ต้องมีการแทรกแซงจากผู้ดูแลระบบ
- จำเป็นต้องมีการซิงโครไนซ์แบบเรียลไทม์: แอปพลิเคชันที่ต้องการข้อมูลแบบเรียลไทม์หรือใกล้เคียงเรียลไทม์บนเซิร์ฟเวอร์สำรอง ไม่สามารถยอมรับความล่าช้าที่เกิดขึ้นจากการส่งบันทึกข้อมูลได้
- ความทนทานต่อการสูญเสียข้อมูลขั้นต่ำ: องค์กรที่มี RPO วัดเป็นวินาที หรือต้องการข้อมูลไม่สูญหายเลย จำเป็นต้องใช้โซลูชันแบบซิงโครนัส
6.3 แนวทางปฏิบัติที่ดีที่สุด
- การเพิ่มประสิทธิภาพความถี่ในการสำรองข้อมูล: ควรพิจารณาความถี่ในการสำรองข้อมูลให้เหมาะสมกับภาระงานของระบบและเป้าหมายในการกู้คืนข้อมูล เริ่มต้นด้วยช่วงเวลา 15 นาที แล้วปรับเปลี่ยนตามความต้องการจริง
- ข้อควรพิจารณาเกี่ยวกับเส้นทางเครือข่าย: ควรใช้เส้นทาง UNC แทนการแมปไดรฟ์สำหรับตำแหน่งสำรองข้อมูล และวางไฟล์สำรองข้อมูลไว้บนโครงสร้างพื้นฐานเครือข่ายที่เชื่อถือได้
- การตั้งค่าการตรวจสอบและการแจ้งเตือน: ตั้งค่าการแจ้งเตือนสำหรับความล้มเหลวของงานสำรองข้อมูล คัดลอก และกู้คืนทันทีหลังจากเสร็จสิ้นการตั้งค่าการส่งบันทึกข้อมูล
- ตารางการทดสอบปกติ: กำหนดตารางการทดสอบการสลับระบบเมื่อเกิดข้อผิดพลาดเป็นประจำทุกไตรมาสหรือครึ่งปี เพื่อตรวจสอบความถูกต้องของขั้นตอนและรักษาความพร้อมของผู้ดูแลระบบ
- การบำรุงรักษาเอกสาร: จัดทำคู่มือการใช้งานอย่างละเอียด โดยบันทึกรายละเอียดการกำหนดค่า ขั้นตอนการสลับระบบเมื่อเกิดข้อผิดพลาด และขั้นตอนการแก้ไขปัญหา
- ข้อควรพิจารณาด้านความปลอดภัย: ใช้บัญชีบริการเฉพาะที่มีสิทธิ์การเข้าถึงขั้นต่ำที่จำเป็น จำกัดสิทธิ์การเข้าถึงไฟล์ที่แชร์บนเครือข่ายอย่างเหมาะสม
- การจัดการพื้นที่ดิสก์: ตรวจสอบพื้นที่ดิสก์ในตำแหน่งสำรองข้อมูลอย่างต่อเนื่อง ตั้งค่าการแจ้งเตือนเมื่อพื้นที่เหลือน้อยกว่า 20%
- การกำหนดค่านโยบายการเก็บรักษาข้อมูล: ตั้งค่าระยะเวลาการเก็บรักษาข้อมูลสำรองให้นานกว่าระยะเวลาหน่วงในการซิงโครไนซ์ที่ยอมรับได้สูงสุดของคุณ
- คืนค่าหน่วงเวลาสำหรับการป้องกัน: กำหนดค่าการหน่วงเวลาในการกู้คืนเมื่อการป้องกันการแก้ไขโดยไม่ตั้งใจนั้นคุ้มค่ากับการเพิ่มความล่าช้าในการซิงโครไนซ์
7. การแก้ไขปัญหาทั่วไป
7.1 ความล้มเหลวของงานสำรองข้อมูล
- พื้นที่ดิสก์ไม่เพียงพอ: ตรวจสอบประวัติการทำงานเพื่อหาข้อผิดพลาดเกี่ยวกับพื้นที่ดิสก์ ตรวจสอบพื้นที่ว่างและพื้นที่ที่ใช้งานได้ โดยการลบข้อมูลสำรองเก่าหรือเปิดใช้งานการบีบอัด
- ปัญหาการอนุญาต: ตรวจสอบ SQL Server บัญชีบริการมีสิทธิ์ควบคุมเต็มรูปแบบทั้งในโฟลเดอร์ภายในเครื่องและโฟลเดอร์ที่แชร์บนเครือข่าย
- ฐานข้อมูลไม่สามารถกู้คืนได้อย่างสมบูรณ์: เปลี่ยนกลับไปใช้โหมดการกู้คืนแบบเต็ม และทำการสำรองข้อมูลแบบเต็มเพื่อเริ่มต้นการทำงานของลำดับบันทึกธุรกรรมอีกครั้ง
7.2 ความล้มเหลวในการคัดลอกงาน
- เส้นทางเครือข่ายไม่สามารถเข้าถึงได้: ทดสอบการเชื่อมต่อจากเซิร์ฟเวอร์สำรองโดยการกำหนดเส้นทางเครือข่ายด้วยตนเอง
- ปัญหาการตรวจสอบสิทธิ์: หากเซิร์ฟเวอร์อยู่ในโดเมนที่แตกต่างกัน ให้กำหนดข้อมูลประจำตัวที่ชัดเจนสำหรับการเข้าถึงไฟล์ที่แชร์บนเครือข่าย
- ปัญหาการล็อกไฟล์: ยกเว้นโฟลเดอร์สำรองข้อมูลจากการสแกนแบบเรียลไทม์ของโปรแกรมป้องกันไวรัส เพื่อป้องกันการล็อกไฟล์
7.3 การกู้คืนงานที่ล้มเหลว
- ไฟล์สำรองข้อมูลหายไป: ตรวจสอบว่าไฟล์มีอยู่ในโฟลเดอร์ปลายทางหรือไม่ และตรวจสอบประวัติการคัดลอกงาน
- ข้อผิดพลาดในการกู้คืนลำดับ: ระบุไฟล์สำรองข้อมูลบันทึกธุรกรรมที่หายไป และกู้คืนตามลำดับเพื่อซ่อมแซมลำดับบันทึกธุรกรรมให้สมบูรณ์
- ฐานข้อมูลอยู่ในสถานะผิดปกติ: หากมีผู้ใดกู้คืนฐานข้อมูลไปแล้ว ให้เริ่มต้นการส่งบันทึกข้อมูลใหม่โดยการกู้คืนข้อมูลสำรองแบบเต็มด้วยตัวเลือก NORECOVERY
- ความเสียหายของไฟล์ฐานข้อมูล: หากการกู้คืนข้อมูลล้มเหลวอย่างต่อเนื่องแม้ว่าจะดำเนินการตามลำดับและตั้งค่าอย่างถูกต้องแล้ว ไฟล์ฐานข้อมูลอาจเสียหาย ในกรณีเช่นนี้ คุณอาจต้องใช้เครื่องมือเฉพาะทาง เครื่องมือการกู้คืน SQL เพื่อดึงข้อมูลจากไฟล์ .MDF และ .NDF ที่เสียหาย ก่อนที่จะพยายามเริ่มต้นการส่งบันทึกข้อมูลใหม่อีกครั้ง
7.4 ปัญหาความล่าช้าในการซิงโครไนซ์
- ข้อจำกัดด้านแบนด์วิดท์ของเครือข่าย: เปิดใช้งานการบีบอัดข้อมูลสำรองเพื่อลดขนาดไฟล์และปริมาณการใช้แบนด์วิดท์
- ปริมาณธุรกรรมสูง: ลองพิจารณาเพิ่มความถี่ในการสำรองข้อมูลเพื่อสร้างไฟล์สำรองที่มีขนาดเล็กลงและจัดการได้ง่ายขึ้น
- ความถี่ในการกู้คืนไม่เพียงพอ: เพิ่มความถี่ในการกู้คืนข้อมูลให้ใกล้เคียงกับความถี่ในการสำรองข้อมูล และลดความล่าช้าให้น้อยที่สุด
7.5 ตรวจสอบปัญหาการเชื่อมต่อเซิร์ฟเวอร์ (SQL 2025)
- ข้อผิดพลาดของผู้ให้บริการ OLE DB: SQL Server การเข้ารหัสภาคบังคับตามค่าเริ่มต้นของปี 2025 ขัดแย้งกับเวอร์ชันเก่ากว่าที่ไม่มีการกำหนดค่าการเข้ารหัสที่เหมาะสม
- ความไม่ตรงกันของการตั้งค่าการเข้ารหัส: ตรวจสอบการกำหนดค่าเซิร์ฟเวอร์ที่เชื่อมโยงบนเซิร์ฟเวอร์ตรวจสอบ และตรวจสอบการตั้งค่าการเข้ารหัส
- แนวทางการแก้ไขปัญหาเฉพาะหน้า: ยกเลิกและสร้างการส่งบันทึกใหม่โดยใช้พารามิเตอร์ TLS 1.3 หรืออัปเกรดอินสแตนซ์ทั้งหมดเป็นเวอร์ชันดังกล่าว SQL Server 2025.
7.6 SQL Server ปัญหาเกี่ยวกับการบริการของตัวแทน
- บริการยังไม่เริ่ม: ตรวจสอบสถานะบริการ Agent และตั้งค่าให้เริ่มต้นทำงานโดยอัตโนมัติ
- ตารางงานถูกปิดใช้งาน: ตรวจสอบสถานะตารางงานและเปิดใช้งานตารางงานที่ถูกปิดใช้งาน
- ความล้มเหลวในขั้นตอนการทำงาน: ตรวจสอบประวัติการทำงานเพื่อระบุขั้นตอนที่ล้มเหลวและข้อความแสดงข้อผิดพลาดที่เฉพาะเจาะจง
8. คำถามที่พบบ่อย (FAQ)
ถาม: ฉันสามารถใช้การส่งบันทึกข้อมูล (log shipping) กับ Express Edition ได้หรือไม่?
A: ไม่ SQL Server Express Edition ไม่รองรับการส่งบันทึกข้อมูลเนื่องจากขาดคุณสมบัติบางอย่าง SQL Server ตัวแทน.
ถาม: ฉันควรตั้งค่าการสำรองข้อมูลไฟล์บันทึกบ่อยแค่ไหน?
A: ช่วงเวลา 15 นาทีที่เป็นค่าเริ่มต้นนั้นให้ความสมดุลที่เหมาะสม ปรับเปลี่ยนตามเป้าหมายจุดพักฟื้นของคุณ
ถาม: สามารถใช้ฐานข้อมูลรองสำหรับการรายงานได้หรือไม่?
A: ใช่แล้ว ฐานข้อมูลสำรองที่กำหนดค่าในโหมดสแตนด์บายจะอนุญาตให้เข้าถึงแบบอ่านอย่างเดียวระหว่างการดำเนินการกู้คืน
ถาม: จะเกิดอะไรขึ้นหากเซิร์ฟเวอร์หลักล้มเหลว?
A: ดำเนินการสลับระบบไปยังฐานข้อมูลสำรองด้วยตนเอง การสูญเสียข้อมูลจะเท่ากับความล่าช้าในการซิงโครไนซ์ ณ เวลาที่เกิดความล้มเหลว
ถาม: ฉันสามารถมีเซิร์ฟเวอร์รองหลายเครื่องได้หรือไม่?
A: ใช่แล้ว Log Shipping รองรับเซิร์ฟเวอร์รองได้ไม่จำกัดจำนวน โดยแต่ละเซิร์ฟเวอร์สามารถกำหนดค่าได้อย่างอิสระ
ถาม: ฉันจะคำนวณค่าความหน่วงในการซิงค์ได้อย่างไร?
A: เปรียบเทียบเวลาประทับของบันทึกธุรกรรมที่กู้คืนครั้งล่าสุดกับเวลาปัจจุบันโดยใช้ตารางตรวจสอบการส่งบันทึก (Log Shipping Monitoring Tables)
ถาม: การส่งบันทึกข้อมูล (Log Shipping) สามารถใช้งานข้ามโดเมนที่แตกต่างกันได้หรือไม่?
A: ใช่ค่ะ มันใช้งานได้ในโดเมนต่างๆ หรือในสภาพแวดล้อมของกลุ่มงานโดยไม่จำเป็นต้องสร้างความสัมพันธ์แบบไว้วางใจ
ถาม: โหมด "ไม่กู้คืน" กับโหมด "สแตนด์บาย" ต่างกันอย่างไร?
A: โหมดการกู้คืนใดๆ ก็ตามจะทำให้ไม่สามารถเข้าถึงฐานข้อมูลได้ โหมดสแตนด์บายจะอนุญาตให้เรียกดูข้อมูลแบบอ่านอย่างเดียวได้ระหว่างการกู้คืน
ถาม: ฉันสามารถหยุดการส่งบันทึกข้อมูลชั่วคราวได้หรือไม่?
A: ใช่แล้ว ให้ปิดใช้งานการสำรองข้อมูล การคัดลอก และการกู้คืน เพื่อหยุดการซิงโครไนซ์ชั่วคราว ในขณะที่ยังคงรักษาการตั้งค่าไว้
ถาม: ฉันจะลบการตั้งค่าการส่งบันทึกข้อมูลได้อย่างไร?
ตอบ: ในไฟล์ บันทึกธุรกรรมการจัดส่ง หน้าคุณสมบัติ:
- ยกเลิกการเลือก เปิดใช้งานฐานข้อมูลนี้เป็นฐานข้อมูลหลักในการกำหนดค่าการส่งบันทึก (Log Shipping)
- คลิก OK เพื่อลบการตั้งค่าและลบงาน
ถาม: ฉันสามารถเปลี่ยนฐานข้อมูลรองเป็นโหมดอ่าน-เขียนได้หรือไม่?
A: ใช่ ให้ดำเนินการคำสั่ง RESTORE DATABASE WITH RECOVERY แต่การทำเช่นนี้จะทำให้กระบวนการส่งบันทึกข้อมูล (log shipping) หยุดชะงัก
ถาม: ฉันสามารถตั้งค่าระยะเวลาหน่วงสูงสุดสำหรับการกู้คืนได้เท่าไร?
A: ไม่มีข้อจำกัดตายตัว คุณสามารถตั้งค่าการหน่วงเวลาได้ตั้งแต่ไม่กี่นาทีจนถึงหลายวัน ขึ้นอยู่กับความต้องการด้านการป้องกันของคุณ
ถาม: การส่งไฟล์บันทึกข้อมูลมีผลต่อกลยุทธ์การสำรองข้อมูลอย่างไร?
A: โปรแกรมนี้จะสร้างไฟล์สำรองข้อมูลบันทึกธุรกรรมที่สามารถนำไปใช้ได้ทั้งสำหรับการส่งบันทึก (log shipping) และการกู้คืนข้อมูล ณ จุดเวลาใดเวลาหนึ่ง
ถาม: ฉันสามารถใช้ Log Shipping สำหรับการย้ายเซิร์ฟเวอร์ได้หรือไม่?
A: ใช่ครับ ตั้งค่าการส่งบันทึกข้อมูลไปยังเซิร์ฟเวอร์ใหม่ ซิงโครไนซ์ข้อมูล จากนั้นทำการสลับการทำงานไปยังเซิร์ฟเวอร์เก่าตามแผนในระหว่างการบำรุงรักษา
ถาม: มีเครื่องมือตรวจสอบใดบ้างที่ใช้งานร่วมกับ Log Shipping ได้?
A: SQL Server Management Studio มีระบบรายงานในตัว ส่วนเครื่องมือจากผู้ให้บริการภายนอก เช่น SQL Monitor และ SolarWinds จะช่วยเพิ่มประสิทธิภาพในการตรวจสอบ
9. บทสรุปและข้อเสนอแนะ
9.1 สรุปประเด็นสำคัญ
SQL Server การส่งบันทึกข้อมูล (Log Shipping) ช่วยให้การกู้คืนระบบหลังภัยพิบัติมีความน่าเชื่อถือและคุ้มค่า โดยผ่านการสำรองและกู้คืนบันทึกธุรกรรมแบบอัตโนมัติ เทคโนโลยีนี้ใช้งานได้กับ Standard Edition ต้องการโครงสร้างพื้นฐานน้อยที่สุด และรองรับเซิร์ฟเวอร์สำรองหลายเครื่อง
การส่งบันทึกข้อมูล (Log shipping) เหมาะสำหรับเป้าหมายการกู้คืนระดับปานกลางที่ยอมรับการสลับระบบสำรองด้วยตนเองได้ ข้อจำกัดที่สำคัญ ได้แก่ ความจำเป็นในการสลับระบบสำรองด้วยตนเอง ความล่าช้าในการซิงโครไนซ์ และขอบเขตการกำหนดค่าระดับฐานข้อมูล
เทคโนโลยีนี้สามารถทำงานร่วมกับกลยุทธ์การสำรองข้อมูลที่มีอยู่ได้อย่างลงตัว รองรับการรายงานแบบอ่านอย่างเดียวผ่านโหมดสแตนด์บาย และให้การป้องกันการกู้คืนล่าช้าจากการเปลี่ยนแปลงโดยไม่ตั้งใจ
9.2 การเลือกสิ่งที่ถูกต้องเพื่อสิ่งแวดล้อมของคุณ
ประเมินการส่งบันทึกข้อมูลเทียบกับข้อกำหนดเฉพาะของคุณก่อนนำไปใช้งาน พิจารณาถึงเป้าหมายจุดกู้คืน เป้าหมายเวลากู้คืน ข้อจำกัดด้านงบประมาณ และระดับความซับซ้อนในการดำเนินงานที่ยอมรับได้
องค์กรที่ใช้ SQL Server สำหรับรุ่น Standard Edition ที่มีข้อกำหนดด้านการกู้คืนข้อมูลระดับปานกลาง ควรพิจารณาใช้ Log Shipping อย่างจริงจัง ส่วนองค์กรที่มีข้อกำหนด RTO ที่เข้มงวดต่ำกว่า 15 นาที ควรประเมินใช้ Always On Availability Groups
พิจารณาแนวทางแบบผสมผสาน โดยการนำการขนส่งไม้ซุงมาใช้ร่วมกับเทคโนโลยีอื่นๆ เพื่อเพิ่มประสิทธิภาพด้านต้นทุน ในขณะเดียวกันก็ตอบสนองความต้องการที่หลากหลาย
9.3 ขั้นตอนต่อไปและแหล่งข้อมูลเพิ่มเติม
เริ่มต้นด้วยการทดลองใช้งานในวงจำกัดเพื่อเก็บเกี่ยวประสบการณ์ จัดทำเอกสารประกอบอย่างครบถ้วน รวมถึงรายละเอียดการกำหนดค่า ขั้นตอนการสำรองข้อมูล และคู่มือการแก้ไขปัญหา
กำหนดเวลาทดสอบการสลับระบบเมื่อเกิดข้อผิดพลาดเป็นประจำ เพื่อตรวจสอบความถูกต้องของขั้นตอนและรักษาความพร้อมของผู้ดูแลระบบ ติดตามข่าวสารล่าสุดอยู่เสมอ SQL Server การอัปเดตและการปรับปรุง
อ้างอิง
- เอกสารอย่างเป็นทางการจาก Microsoft: เกี่ยวกับการขนส่งท่อนซุง (SQL Server)
- เอกสารอย่างเป็นทางการจาก Microsoft: กำหนดค่าการส่งบันทึก (SQL Server)
เกี่ยวกับผู้เขียน
หยวน เซิง เป็นผู้ดูแลฐานข้อมูลอาวุโส (DBA) ที่มีประสบการณ์มากกว่า 10 ปีใน SQL Server สภาพแวดล้อมและการจัดการฐานข้อมูลองค์กร เขาประสบความสำเร็จในการแก้ไขปัญหาการกู้คืนฐานข้อมูลหลายร้อยกรณีในองค์กรด้านบริการทางการเงิน การดูแลสุขภาพ และการผลิต
หยวนมีความเชี่ยวชาญด้าน SQL Server การกู้คืนฐานข้อมูล โซลูชันความพร้อมใช้งานสูง และการเพิ่มประสิทธิภาพการทำงาน ประสบการณ์ภาคปฏิบัติอันกว้างขวางของเขาครอบคลุมการจัดการฐานข้อมูลหลายเทราไบต์ การนำ Always On Availability Groups มาใช้ และการพัฒนากลยุทธ์การสำรองและกู้คืนข้อมูลอัตโนมัติสำหรับระบบธุรกิจที่สำคัญต่อภารกิจ
ด้วยความเชี่ยวชาญทางเทคนิคและแนวทางปฏิบัติ Yuan มุ่งเน้นที่การสร้างคู่มือที่ครอบคลุมซึ่งจะช่วยให้ผู้ดูแลระบบฐานข้อมูลและผู้เชี่ยวชาญด้านไอทีแก้ไขปัญหาที่ซับซ้อน SQL Server ท้าทายอย่างมีประสิทธิภาพ เขาคอยติดตามข่าวสารล่าสุดอยู่เสมอ SQL Server การเปิดตัวและเทคโนโลยีฐานข้อมูลที่พัฒนาอย่างต่อเนื่องของ Microsoft ทดสอบสถานการณ์การกู้คืนเป็นประจำเพื่อให้แน่ใจว่าคำแนะนำของเขาสะท้อนถึงแนวทางปฏิบัติที่ดีที่สุดในโลกแห่งความเป็นจริง
มีคำถามเกี่ยวกับ SQL Server การกู้คืนหรือต้องการคำแนะนำในการแก้ไขปัญหาฐานข้อมูลเพิ่มเติมหรือไม่? หยวนยินดีต้อนรับ ข้อเสนอแนะและข้อเสนอแนะ เพื่อปรับปรุงทรัพยากรทางเทคนิคเหล่านี้