SQL Server ฐานข้อมูลในโหมดการกู้คืน: การแก้ไข 10 ครั้ง [2026]

SQL Server ฐานข้อมูลอยู่ในโหมดกู้คืนใช่ไหม? รับ 10 วิธีแก้ไขที่พิสูจน์แล้วตอนนี้! วิธีแก้ปัญหาทีละขั้นตอน ตั้งแต่การแก้ไขง่ายๆ ไปจนถึงการซ่อมแซมขั้นสูง

1 ความเข้าใจ SQL Server โหมดการกู้คืนฐานข้อมูล

1.1 โหมดการกู้คืนคืออะไร SQL Server

เมื่อ SQL Server ฐานข้อมูลแสดงสถานะ “กำลังกู้คืน” หมายความว่า SQL Server กำลังดำเนินการกู้คืนข้อมูลขัดข้องหรือกู้คืนธุรกรรมเพื่อให้มั่นใจถึงความสอดคล้องของฐานข้อมูล กระบวนการอัตโนมัตินี้จะรักษาความสมบูรณ์ของข้อมูลด้วยการเล่นซ้ำธุรกรรมที่ยืนยันแล้วและย้อนกลับธุรกรรมที่ยังไม่ได้ยืนยัน

โหมดการกู้คืนมักเกิดขึ้นหลังจากการปิดระบบโดยไม่คาดคิด ไฟฟ้าดับ หรือระหว่างการกู้คืนฐานข้อมูล แม้ว่านี่จะเป็นกลไกการป้องกันตามปกติ แต่ปัญหาจะเกิดขึ้นเมื่อ SQL Server ฐานข้อมูลในการกู้คืนใช้เวลานานผิดปกติหรือปรากฏว่าติดขัด

1.2 สามขั้นตอนของการกู้คืนฐานข้อมูล

SQL Server การฟื้นตัวแบ่งออกเป็น 3 ระยะที่แตกต่างกัน:

1.2.1 ขั้นตอนการวิเคราะห์

SQL Server สแกนบันทึกธุรกรรมจากจุดตรวจสอบล่าสุดเพื่อระบุเพจที่สกปรกและธุรกรรมที่ใช้งานอยู่ ระบบจะสร้างตารางเพจที่สกปรก (DPT) และตารางธุรกรรมที่ใช้งานอยู่ (ATT) เพื่อติดตามสิ่งที่ต้องการกู้คืน

1.2.2 เฟสทำซ้ำ (Roll Forward)

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

1.2.3 เฟสย้อนกลับ (ย้อนกลับ)

ธุรกรรมใดๆ ที่ยังไม่ได้ยืนยันจะถูกย้อนกลับเพื่อรักษาความสอดคล้องของฐานข้อมูล เมื่อเสร็จสิ้น ฐานข้อมูลจะพร้อมใช้งานสำหรับการดำเนินงานตามปกติ

1.3 อาการทั่วไปและข้อความแสดงข้อผิดพลาด

เมื่อคุณ SQL Server เมื่อ db อยู่ในระหว่างการกู้คืน คุณจะเห็นโดยทั่วไป:

ชื่อฐานข้อมูลแสดง “(กำลังกู้คืน)” ใน SQL Server สตูดิโอการจัดการ
ความล้มเหลวในการเข้าสู่ระบบพร้อมข้อความ “กำลังกู้คืนฐานข้อมูล”
รายการบันทึกข้อผิดพลาดแสดงเปอร์เซ็นต์ความคืบหน้าในการกู้คืน
สถานะฐานข้อมูลแสดง "กำลังกู้คืน" เมื่อมีการสอบถาม

2. สาเหตุหลักของ SQL Server ปัญหาโหมดการกู้คืน

2.1 การดำเนินการคืนค่าที่ไม่สมบูรณ์

สาเหตุที่พบบ่อยที่สุดมักเกิดขึ้นเมื่อทำการกู้คืนจากไฟล์สำรองหลายไฟล์โดยใช้ โนรีโคเวรี่ ตัวเลือกที่ไม่มีตัวสุดท้าย พร้อมการกู้คืน คำสั่งนี้จะทำให้ฐานข้อมูลต้องรอการดำเนินการคืนค่าเพิ่มเติม

2.2 ปัญหาบันทึกธุรกรรม

ไฟล์บันทึกธุรกรรมขนาดใหญ่หรือไฟล์บันทึกเสมือน (VLF) จำนวนมากเกินไป จะทำให้การกู้คืนช้าลงอย่างมาก เมื่อ MS SQL กำลังกู้คืนข้อมูลที่มี VLF หลายพันไฟล์ กระบวนการนี้อาจใช้เวลาหลายชั่วโมงหรือหลายวันจึงจะเสร็จสมบูรณ์

2.3 ปัญหาที่เกี่ยวข้องกับระบบ

ความล้มเหลวของฮาร์ดแวร์ ไฟฟ้าดับ หรือพื้นที่ดิสก์ไม่เพียงพอ อาจขัดขวางการทำงานปกติของฐานข้อมูล ส่งผลให้กระบวนการกู้คืนข้อมูลระหว่างการเริ่มต้นใหม่ใช้เวลานาน

2.4 ความเสียหายของฐานข้อมูล

ไฟล์ฐานข้อมูลที่เสียหายจะทำให้การกู้คืนไม่สำเร็จ ทำให้ฐานข้อมูลติดอยู่ในโหมดการกู้คืนอย่างไม่มีกำหนด

3. ขั้นตอนการวินิจฉัยก่อนทำการซ่อมแซม

3.1 การตรวจสอบ SQL Server บันทึกข้อผิดพลาด

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

จุดเปิด SQL Server สตูดิโอการจัดการ
นำทางไปยัง การจัดการ -> SQL Server ท่อน
ตรวจสอบรายการล่าสุดสำหรับชื่อฐานข้อมูลของคุณ
มองหาตัวบ่งชี้ระยะการฟื้นตัว (ระยะที่ 1, 2 หรือ 3 จาก 3)

3.2 การติดตามความคืบหน้าการฟื้นฟู

ใช้มุมมองการจัดการแบบไดนามิกเพื่อติดตามการดำเนินการกู้คืนที่ใช้งานอยู่:

SELECT session_id, command, blocking_session_id, wait_type, wait_time, wait_resource
FROM sys.dm_exec_requests
WHERE command = 'DB STARTUP';

3.3 การตรวจสอบสถานะฐานข้อมูล

ตรวจสอบสถานะฐานข้อมูลปัจจุบันเพื่อทำความเข้าใจสถานะการกู้คืน:

SELECT name, state_desc
FROM sys.databases
WHERE name = 'YourDatabaseName';

4. แก้ไข #1: รอให้การกู้คืนตามธรรมชาติเสร็จสิ้น

บางครั้งความอดทนคือทางออกที่ดีที่สุดเมื่อคุณ SQL Server ฐานข้อมูลกำลังอยู่ในระหว่างการกู้คืน วิธีนี้ใช้ได้เมื่อการกู้คืนดำเนินไปตามปกติ แต่ใช้เวลานานกว่าที่คาดไว้

4.1 เมื่อใดควรอดทน

อนุญาตให้เสร็จสมบูรณ์ตามธรรมชาติเมื่อ:

บันทึกข้อผิดพลาดแสดงความคืบหน้าอย่างต่อเนื่องโดยมีการประมาณเวลาที่ลดลง
ไม่มีการรายงานข้อผิดพลาดการทุจริต
ฐานข้อมูลเพิ่งประสบกับธุรกรรมขนาดใหญ่
จำนวน VLF สามารถจัดการได้ (ต่ำกว่า 1,000)

4.2 การติดตามความคืบหน้าการฟื้นฟู

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

5. การแก้ไข #2: ใช้ RESTORE DATABASE WITH RECOVERY

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

5.1 การทำความเข้าใจคำสั่ง

การขอ กู้คืนฐานข้อมูลด้วยการกู้คืน คำสั่งนี้จะทำให้กระบวนการกู้คืนเสร็จสมบูรณ์โดยการย้อนกลับธุรกรรมที่ยังไม่ได้ยืนยันและนำฐานข้อมูลออนไลน์

5.2 ขั้นตอนการดำเนินการ

จุดเปิด SQL Server สตูดิโอการจัดการ
เชื่อมต่อกับของคุณ SQL Server ตัวอย่าง
คลิก ใหม่ > สอบถามด้วยการเชื่อมต่อปัจจุบัน
ดำเนินการ: RESTORE DATABASE [YourDatabaseName] WITH RECOVERY;
รอการยืนยันการเสร็จสิ้น

คำเตือน: ใช้คำสั่งนี้เฉพาะในกรณีที่คุณแน่ใจว่าไม่มีการดำเนินการคืนค่าเพิ่มเติมรออยู่

6. แก้ไข #3: แก้ไขปัญหาบันทึกธุรกรรม

ปัญหาบันทึกธุรกรรมเป็นสาเหตุหลักที่ทำให้ระยะเวลาการกู้คืนข้อมูลยาวนานขึ้น การแก้ไขนี้ช่วยแก้ไขปัญหาบันทึกเต็ม VLF มากเกินไป และปัญหาพื้นที่บันทึกที่ยังคง SQL Server ในการกู้คืน

6.1 การสำรองข้อมูลบันทึกธุรกรรม

เพิ่มพื้นที่ว่างในการบันทึกโดยการสร้างการสำรองข้อมูลบันทึกธุรกรรม:

จุดเปิด SQL Server สตูดิโอการจัดการ
คลิกขวาที่ฐานข้อมูลของคุณ -> งาน -> Back Up
เปลี่ยนแปลง ประเภทการสำรองข้อมูล ไปยัง บันทึกธุรกรรม
ระบุปลายทางการสำรองข้อมูล
คลิก OK ที่จะดำเนินการ

6.2 การจัดการไฟล์บันทึกเสมือน (VLF)

ตรวจสอบจำนวน VLF ด้วย:

DBCC LOGINFO('YourDatabaseName');

หากคุณมี VLF มากกว่า 1,000 ให้ลดลงเหลือ:

การสำรองข้อมูลบันทึกธุรกรรม
การลดขนาดไฟล์บันทึก: DBCC SHRINKFILE(LogFileName, TRUNCATEONLY);
การขยายไฟล์บันทึกเป็นชิ้นใหญ่ (1GB หรือมากกว่า)

6.3 การลดขนาดไฟล์บันทึกอย่างปลอดภัย

ย่อขนาดบันทึกเฉพาะในช่วงเวลาการบำรุงรักษาเมื่อไม่มีธุรกรรมใดๆ กำลังทำงานอยู่ ควรสำรองข้อมูลฐานข้อมูลก่อนย่อขนาดเสมอ

7. แก้ไข #4: เรียกใช้ DBCC CHECKDB และซ่อมแซม

ความเสียหายของฐานข้อมูลอาจทำให้การกู้คืนไม่สำเร็จ DBCC CHECKDB เป็นคำสั่งในตัวที่สามารถระบุและซ่อมแซมปัญหาความเสียหายเล็กน้อยที่ทำให้ MS SQL อยู่ในโหมดการกู้คืน

7.1 การตรวจสอบความเสียหายของฐานข้อมูล

เริ่มต้นด้วยวิธีการมาตรฐานในการตรวจสอบความสมบูรณ์ของฐานข้อมูล ลองใช้คำสั่ง DBCC CHECKDB โดยตรงก่อน:

ดำเนินการ: DBCC CHECKDB('YourDatabaseName') WITH NO_INFOMSGS;
ตรวจสอบผลลัพธ์เพื่อหาข้อผิดพลาดด้านความสอดคล้อง
บันทึกข้อความทุจริตใด ๆ

หาก DBCC CHECKDB ล้มเหลว หากมีข้อผิดพลาดเช่น "ฐานข้อมูลกำลังถูกกู้คืน กำลังรอจนกว่าการกู้คืนจะเสร็จสิ้น" หมายความว่าฐานข้อมูลกำลังอยู่ในโหมดกู้คืนและกำลังบล็อกการเข้าถึง ในกรณีนี้ ให้ดำเนินการต่อไปตามส่วนที่ 7.3 เพื่อใช้โหมดฉุกเฉิน

7.2 ตัวเลือกการซ่อมแซมสำหรับฐานข้อมูลที่สามารถเข้าถึงได้

หาก DBCC CHECKDB ทำงานได้สำเร็จและพบความเสียหาย ให้ใช้ขั้นตอนการซ่อมแซมเหล่านี้:

ตั้งค่าฐานข้อมูลเป็นโหมดผู้ใช้เดี่ยว: ALTER DATABASE [YourDatabaseName] SET SINGLE_USER;
พยายามซ่อมแซมอย่างปลอดภัย: DBCC CHECKDB('YourDatabaseName', REPAIR_REBUILD);
หากไม่สำเร็จ ให้ใช้: DBCC CHECKDB('YourDatabaseName', REPAIR_ALLOW_DATA_LOSS);
กลับสู่ผู้ใช้หลายราย: ALTER DATABASE [YourDatabaseName] SET MULTI_USER;

7.3 การใช้โหมดฉุกเฉินเมื่อไม่สามารถเข้าถึงฐานข้อมูลได้

จำเป็นต้องใช้โหมดฉุกเฉินเฉพาะเมื่อฐานข้อมูลค้างอยู่ในระหว่างการกู้คืนและปฏิเสธความพยายาม DBCC CHECKDB ตามปกติ โหมดฉุกเฉินนี้จะทำเครื่องหมายฐานข้อมูลเป็น "อ่านอย่างเดียว" และปิดใช้งานการบันทึกข้อมูล ใช้วิธีการนี้เมื่อการเข้าถึงมาตรฐานล้มเหลว:

ตั้งค่าโหมดฉุกเฉิน: ALTER DATABASE [YourDatabaseName] SET EMERGENCY;
ตั้งค่าผู้ใช้รายเดียว: ALTER DATABASE [YourDatabaseName] SET SINGLE_USER;
ดำเนินการตรวจสอบความสมบูรณ์: DBCC CHECKDB('YourDatabaseName') WITH NO_INFOMSGS;
หากพบการทุจริต ให้ดำเนินการซ่อมแซมอย่างปลอดภัยก่อน: DBCC CHECKDB('YourDatabaseName', REPAIR_REBUILD);
หากล้มเหลว ให้ใช้การซ่อมแซมพร้อมการสูญเสียข้อมูล: DBCC CHECKDB('YourDatabaseName', REPAIR_ALLOW_DATA_LOSS);
ตั้งค่าผู้ใช้หลายราย: ALTER DATABASE [YourDatabaseName] SET MULTI_USER;
ตั้งค่าออนไลน์: ALTER DATABASE [YourDatabaseName] SET ONLINE;

สำคัญ: โหมดฉุกเฉินจะข้ามกระบวนการกู้คืนปกติ และควรใช้เฉพาะเมื่อฐานข้อมูลไม่สามารถเข้าถึงได้โดยสิ้นเชิงเท่านั้น ลองใช้วิธี DBCC CHECKDB มาตรฐานก่อนเสมอ ก่อนที่จะยกระดับเป็นโหมดฉุกเฉิน

คุณสามารถค้นหา คู่มือที่ครอบคลุมยิ่งขึ้นเกี่ยวกับวิธีใช้ DBCC CHECKDB.

8. แก้ไข #5: กู้คืนจากการสำรองข้อมูล

เมื่อวิธีการอื่นล้มเหลวหรือความสมบูรณ์ของข้อมูลไม่น่าเชื่อถือ การกู้คืนจากข้อมูลสำรองที่สะอาดมักเป็นวิธีแก้ปัญหาที่น่าเชื่อถือที่สุด SQL Server ฐานข้อมูลในประเด็นการกู้คืน

8.1 เมื่อใดจึงควรเลือกการกู้คืนข้อมูลสำรอง

พิจารณาการกู้คืนข้อมูลสำรองเมื่อ:

การกู้คืนดำเนินมาเป็นเวลา 24 ชั่วโมงโดยไม่มีความคืบหน้า
ข้อผิดพลาดจากการทุจริตขัดขวางการซ่อมแซมที่ประสบความสำเร็จ
คุณมีข้อมูลสำรองล่าสุดที่ผ่านการตรวจสอบแล้ว
การสูญเสียข้อมูลนับตั้งแต่การสำรองข้อมูลครั้งล่าสุดเป็นที่ยอมรับได้

8.2 กระบวนการคืนค่าทีละขั้นตอน

จุดเปิด SQL Server สตูดิโอการจัดการ
คลิกขวาที่ ฐานข้อมูล -> กู้คืนฐานข้อมูล
เลือก อุปกรณ์ ภายใต้แหล่งที่มา
คลิก เพิ่ม และเรียกดูไฟล์สำรองของคุณ
เลือกการสำรองข้อมูลและคลิก OK
Choose เขียนทับฐานข้อมูลที่มีอยู่ หากมีความจำเป็น
คลิก OK เพื่อเริ่มต้นการบูรณะ

8.3 การกู้คืนจุดในเวลา

เพื่อลดการสูญเสียข้อมูลให้น้อยที่สุด ให้ใช้การสำรองข้อมูลบันทึกธุรกรรมเพื่อกู้คืนไปยังจุดเวลาที่กำหนด ตรวจสอบให้แน่ใจว่าคุณมีการสำรองข้อมูลบันทึกอย่างต่อเนื่องตั้งแต่การสำรองข้อมูลแบบเต็มไปจนถึงจุดกู้คืนที่ต้องการ

8.4 ข้อมูลอ้างอิง

คุณสามารถเรียนรู้ข้อมูลเพิ่มเติมได้จาก คำแนะนำที่ครอบคลุมเกี่ยวกับวิธีการสำรองข้อมูลและคืนค่า SQL Server ฐานข้อมูล.

9. แก้ไข #6: ปิดใช้งานคุณสมบัติปิดอัตโนมัติ

คุณสมบัติฐานข้อมูลการปิดอัตโนมัติอาจทำให้เกิดวงจรการกู้คืนซ้ำ ทำให้ดูเหมือนว่า SQL Server db อยู่ในระหว่างการกู้คืนอย่างต่อเนื่อง การปิดใช้งานคุณสมบัตินี้จะช่วยแก้ไขปัญหาได้

9.1 ทำความเข้าใจปัญหาการปิดอัตโนมัติ

เมื่อเปิดใช้งานการปิดอัตโนมัติ SQL Server ปิดฐานข้อมูลหลังจากการเชื่อมต่อครั้งสุดท้ายสิ้นสุดลง แล้วเปิดฐานข้อมูลใหม่อีกครั้งเพื่อเชื่อมต่อใหม่ การเปิดซ้ำๆ นี้จะกระตุ้นกระบวนการกู้คืนทุกครั้ง

9.2 การปิดใช้งานการปิดอัตโนมัติ

จุดเปิด SQL Server สตูดิโอการจัดการ
คลิกขวาที่ฐานข้อมูลของคุณ -> อสังหาริมทรัพย์
เลือก ตัวเลือก จากแผงด้านซ้าย
ชุด ปิดอัตโนมัติ ไปยัง เท็จ
คลิก OK เพื่อใช้การเปลี่ยนแปลง

หรือใช้ T-SQL:

ALTER DATABASE [YourDatabaseName] SET AUTO_CLOSE OFF;

10. วิธีแก้ไข #7: รีสตาร์ทเครื่อง SQL Server บริการ

การรีสตาร์ทบริการสามารถแก้ไขปัญหาขั้นตอนการกู้คืนที่ค้างอยู่ได้ แต่ควรใช้ด้วยความระมัดระวัง เนื่องจากจะเริ่มการกู้คืนใหม่ตั้งแต่ต้น วิธีนี้ใช้ได้ผลเมื่อ SQL Server เมื่อฟื้นขึ้นมาก็ปรากฏว่าแข็งไปหมด

10.1 เมื่อการรีสตาร์ทบริการช่วยได้

เริ่มบริการใหม่เมื่อ:

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

10.2 ขั้นตอนการรีสตาร์ทอย่างปลอดภัย

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

หมายเหตุ: การรีสตาร์ทจะทำให้การกู้คืนเริ่มต้นใหม่ตั้งแต่ต้น ซึ่งอาจทำให้ระยะเวลาการกู้คืนโดยรวมนานขึ้น

11. แก้ไข #8: ซ่อมแซมฐานข้อมูลโดยการแยกและแนบใหม่

สำหรับกรณีรุนแรง ให้แยกและแนบฐานข้อมูลใหม่:

แยกฐานข้อมูล: EXEC sp_detach_db 'YourDatabaseName';
แนบไฟล์ MDF เท่านั้น: CREATE DATABASE [YourDB] ON (FILENAME = 'C:\Path\YourDB.mdf') FOR ATTACH_REBUILD_LOG;
นี่จะสร้างบันทึกธุรกรรมใหม่

คำเตือน: วิธีนี้อาจทำให้ข้อมูลสูญหาย ควรใช้เฉพาะเมื่อตัวเลือกอื่นหมดลงแล้วเท่านั้น

12. แก้ไข #9: จัดการปัญหาการมิเรอร์ฐานข้อมูล

การกำหนดค่าการมิเรอร์ฐานข้อมูลอาจทำให้เกิดปัญหาการกู้คืนเฉพาะ การแก้ไขนี้แก้ไขปัญหาเฉพาะของการมิเรอร์ที่ทำให้ฐานข้อมูลอยู่ในสถานะการกู้คืน

12.1 ปัญหาการกู้คืนเฉพาะการมิเรอร์

ฐานข้อมูลมิเรอร์อาจติดขัดระหว่างการกู้คืนเนื่องจากปัญหาการเชื่อมต่อของพาร์ทเนอร์หรือปัญหาปลายทาง ทั้งฐานข้อมูลหลักและฐานข้อมูลมิเรอร์สามารถแสดงสถานะการกู้คืนได้

12.2 โซลูชันการกู้คืนมิเรอร์

รีสตาร์ทเอนด์พอยต์การจำลอง:

ค้นหาชื่อจุดสิ้นสุด: SELECT * FROM sys.endpoints WHERE type = 4;
จุดสิ้นสุดการหยุด: ALTER ENDPOINT [EndpointName] STATE = STOPPED;
จุดเริ่มต้น: ALTER ENDPOINT [EndpointName] STATE = STARTED;

หากการรีสตาร์ทปลายทางล้มเหลว ให้ยกเลิกการเชื่อมต่อการจำลองข้อมูล:

ดำเนินการ: ALTER DATABASE [DatabaseName] SET PARTNER OFF;
วิ่ง: RESTORE DATABASE [DatabaseName] WITH RECOVERY;
กำหนดค่าการมิเรอร์ใหม่เมื่อฐานข้อมูลออนไลน์

13. การแก้ไข #10: ใช้เครื่องมือการกู้คืนระดับมืออาชีพ

เครื่องมือการกู้คืนของบริษัทอื่นให้ความสามารถในการซ่อมแซมขั้นสูงเมื่อติดตั้งในตัว SQL Server วิธีการเหล่านี้ล้มเหลว เครื่องมือเหล่านี้มักจะสามารถกู้คืนข้อมูลจากฐานข้อมูลที่เสียหายอย่างรุนแรงได้

13.1 DataNumen SQL Recovery

DataNumen SQL Recovery มีอัตราการฟื้นตัวสูง พร้อมด้วยตัวเลือกที่ครอบคลุม

ขั้นตอนการใช้งานมีดังต่อไปนี้:

หยุด SQL Server บริการ.
สร้างสำเนาของไฟล์ฐานข้อมูลในโหมดการกู้คืน รวมทั้งไฟล์ MDF หลักและไฟล์ NDF รอง
เริ่มต้น SQL Server บริการ.
เริ่มต้น DataNumen SQL Recovery.
เลือกสำเนาแทนไฟล์ต้นฉบับเป็นแหล่งที่มาของฐานข้อมูลที่จะกู้คืน
คลิก “เริ่มการกู้คืน” และทำตามคำแนะนำเพื่อกู้คืนฐานข้อมูล
หลังจากกระบวนการกู้คืนฐานข้อมูลการกู้คืนใหม่จะปรากฏขึ้นใน SQL Server ซึ่งมีข้อมูลที่กู้คืนมาทั้งหมด

13.2 เมื่อใดควรพิจารณาใช้เครื่องมือของบุคคลที่สาม

ใช้เครื่องมือระดับมืออาชีพเมื่อ:

ตัวเลือกการซ่อมแซมในตัวล้มเหลวหรือรายงานการทุจริตอย่างกว้างขวาง
ไม่มีการสำรองข้อมูลล่าสุด
ข้อมูลสำคัญต้องได้รับการกู้คืนแม้จะมีการทุจริต
วิธีการกู้คืนมาตรฐานส่งผลให้สูญเสียข้อมูลจำนวนมาก

14. แนวทางปฏิบัติที่ดีที่สุดในการป้องกัน

14.1 งานบำรุงรักษาตามปกติ

ปฏิบัติตามแนวทางปฏิบัตินี้เพื่อป้องกัน SQL Server ฐานข้อมูลในประเด็นการกู้คืน:

กำหนดการสำรองข้อมูลแบบเต็มและบันทึกเป็นประจำ: รักษาห่วงโซ่การสำรองข้อมูลให้สมบูรณ์
ตรวจสอบจำนวน VLF: รักษา VLF ไว้ต่ำกว่า 100 เพื่อประสิทธิภาพที่ดีที่สุด
การกำหนดขนาดไฟล์บันทึกแผน: ปรับขนาดบันทึกล่วงหน้าเพื่อหลีกเลี่ยงการเติบโตอัตโนมัติที่มากเกินไป
เรียกใช้ DBCC CHECKDB ปกติ: ตรวจจับการทุจริตในระยะเริ่มต้น

14.2 การตรวจสอบและการแจ้งเตือน

ตั้งค่าการตรวจสอบเชิงรุก:

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

14.3 ฮาร์ดแวร์และโครงสร้างพื้นฐาน

สร้างความมั่นใจให้กับโครงสร้างพื้นฐานที่เชื่อถือได้:

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

15. การแก้ไขปัญหาสถานการณ์ที่ซับซ้อน

15.1 ปัญหาฐานข้อมูลหลายรายการ

เมื่อฐานข้อมูลหลายรายการติดอยู่ในการกู้คืน:

ตรวจสอบปัญหาทั่วทั้งระบบ (พื้นที่ดิสก์, หน่วยความจำ)
กำหนดลำดับความสำคัญของฐานข้อมูลที่สำคัญสำหรับการกู้คืน
พิจารณาปัญหาฮาร์ดแวร์ที่ส่งผลต่ออินสแตนซ์ทั้งหมด
ตรวจสอบการเปลี่ยนแปลงหรืออัปเดตระบบล่าสุด

15.2 ข้อควรพิจารณาเกี่ยวกับฐานข้อมูลขนาดใหญ่

สำหรับฐานข้อมูลขนาดมากกว่า 1TB:

คาดว่าจะใช้เวลาฟื้นตัวนานกว่าปกติ (อาจเป็นหลายวัน)
ให้แน่ใจว่ามีการจัดสรรหน่วยความจำเพียงพอ
พิจารณาการตั้งค่าการประมวลผลแบบขนาน
ตรวจสอบพื้นที่ tempdb ระหว่างการกู้คืน

15.3 เมื่อใดควรติดต่อฝ่ายสนับสนุนของ Microsoft

ติดต่อฝ่ายสนับสนุนของ Microsoft สำหรับ:

ระบบการผลิตที่สำคัญที่ไม่มีตัวเลือกสำรอง
ที่ต้องสงสัยว่า SQL Server ข้อบกพร่องของซอฟต์แวร์
สภาพแวดล้อมขององค์กรที่ต้องการการกู้คืนที่รับประกัน
สถานการณ์ที่ซับซ้อนแบบ Always On หรือคลัสเตอร์

16. คำถามที่พบบ่อย

ถาม: ควรใช้เวลานานเท่าใด SQL Server การกู้คืนฐานข้อมูลโดยปกติใช้เวลาเท่าไหร่?

ตอบ: เวลาในการกู้คืนขึ้นอยู่กับขนาดฐานข้อมูล ปริมาณธุรกรรม และประสิทธิภาพของฮาร์ดแวร์ โดยทั่วไปฐานข้อมูลขนาดเล็กจะกู้คืนได้ภายในไม่กี่นาที ในขณะที่ฐานข้อมูลขนาดใหญ่ที่มีบันทึกธุรกรรมจำนวนมากอาจใช้เวลาหลายชั่วโมง เวลาโดยประมาณที่แสดงในบันทึกข้อผิดพลาดมักไม่แม่นยำ ดังนั้นควรเน้นที่เปอร์เซ็นต์ความคืบหน้าแทน

ถาม: ฉันสามารถหยุดได้ไหม SQL Server ระหว่างการกู้คืนโดยไม่สูญเสียข้อมูล?

ก. หยุด SQL Server โดยทั่วไปแล้ว การกู้คืนข้อมูลระหว่างการดำเนินการนี้จะปลอดภัย แต่จะเริ่มกระบวนการกู้คืนใหม่ตั้งแต่ต้นเมื่อบริการเริ่มต้นทำงานอีกครั้ง ซึ่งจะทำให้เวลาในการกู้คืนโดยรวมนานขึ้น แต่จะไม่ทำให้ข้อมูลสูญหายเพิ่มเติมไปกว่าที่เกิดขึ้นระหว่างเหตุการณ์ครั้งแรก

ถาม: ความแตกต่างระหว่าง “In Recovery” และ “Recovery Pending” คืออะไร?

A: “กำลังฟื้นตัว” หมายถึง SQL Server กำลังดำเนินการกู้คืนข้อมูลอยู่ “กำลังดำเนินการกู้คืน” แสดงว่ากระบวนการกู้คืนล้มเหลวในการเริ่มต้น ซึ่งมักเกิดจากไฟล์หาย สิทธิ์การเข้าถึงไม่เพียงพอ หรือปัญหาพื้นที่ดิสก์ไม่เพียงพอ ซึ่งต้องแก้ไขก่อนจึงจะสามารถดำเนินการกู้คืนต่อไปได้

คุณสามารถค้นหาข้อมูลโดยละเอียดเพิ่มเติมเกี่ยวกับ "การกู้คืนที่รอดำเนินการ" ได้ใน คู่มือฉบับสมบูรณ์.

ถาม: ฉันจะสูญเสียข้อมูลหรือไม่ หากฉันใช้ REPAIR_ALLOW_DATA_LOSS?

ตอบ: ใช่ REPAIR_ALLOW_DATA_LOSS อาจลบข้อมูลที่เสียหายเพื่อกู้คืนความสอดคล้องของฐานข้อมูล ลองใช้ REPAIR_REBUILD ก่อนเสมอ ซึ่งจะแก้ไขปัญหาเชิงโครงสร้างโดยไม่สูญเสียข้อมูล ใช้ REPAIR_ALLOW_DATA_LOSS เป็นทางเลือกสุดท้ายเฉพาะเมื่อคุณไม่มีตัวเลือกการกู้คืนอื่นๆ

ถาม: ฉันสามารถเข้าถึงฐานข้อมูลอื่นได้ในขณะที่กำลังกู้คืนฐานข้อมูลหนึ่งหรือไม่

A: ใช่ ฐานข้อมูลอื่น ๆ บนเดียวกัน SQL Server อินสแตนซ์จะยังคงสามารถเข้าถึงได้ระหว่างการกู้คืน มีเพียงฐานข้อมูลที่กำลังกู้คืนเท่านั้นที่ไม่สามารถใช้งานได้ อย่างไรก็ตาม การดำเนินการกู้คืนอาจส่งผลกระทบต่อประสิทธิภาพโดยรวมของเซิร์ฟเวอร์

ถาม: อะไรเป็นสาเหตุที่ทำให้ฐานข้อมูลติดอยู่ในโหมดการกู้คืน?

A: สาเหตุที่พบบ่อย ได้แก่ การดำเนินการกู้คืนข้อมูลโดยใช้ NORECOVERY ที่ไม่สมบูรณ์, ไฟล์บันทึกเสมือน (VLF) มากเกินไป, ธุรกรรมขนาดใหญ่ที่ยังไม่ได้คอมมิต, ฐานข้อมูลเสียหาย, พื้นที่ดิสก์ไม่เพียงพอ และปัญหาฮาร์ดแวร์ ฐานข้อมูลที่เปิดใช้งาน AUTO CLOSE อาจดูเหมือนเข้าสู่โหมดการกู้คืนอยู่ตลอดเวลา

ถาม: ฉันจะรู้ได้อย่างไรว่าการฟื้นตัวมีความก้าวหน้าหรือติดขัด?

ก. จอภาพ SQL Server บันทึกข้อผิดพลาดสำหรับข้อความแสดงความคืบหน้าการกู้คืนจะแสดงเปอร์เซ็นต์ความสำเร็จ ใช้ sys.dm_exec_requests เพื่อตรวจสอบคำสั่ง DB STARTUP ที่ใช้งานอยู่ หากเปอร์เซ็นต์เพิ่มขึ้นเมื่อเวลาผ่านไป แสดงว่าการกู้คืนกำลังดำเนินไป หากไม่มีรายการบันทึกใหม่เป็นเวลาหลายชั่วโมง อาจบ่งชี้ว่ากระบวนการติดขัด

ถาม: การรีสตาร์ทปลอดภัยหรือไม่ SQL Server บริการระหว่างการกู้คืน?

A: การรีสตาร์ทนั้นปลอดภัย แต่ควรใช้ด้วยความระมัดระวัง การรีสตาร์ทจะเริ่มกระบวนการกู้คืนใหม่ตั้งแต่ต้น ซึ่งอาจทำให้เวลาในการกู้คืนเพิ่มขึ้นเป็นสองเท่า ควรรีสตาร์ทเฉพาะในกรณีที่กระบวนการกู้คืนค้างสนิทโดยไม่มีความคืบหน้าเป็นเวลาหลายชั่วโมง หรือหากคุณสงสัยว่ากระบวนการนั้นติดขัดจริงๆ

ถาม: ความแตกต่างระหว่างโหมดปิดอัตโนมัติและโหมดการกู้คืนคืออะไร

A: การปิดอัตโนมัติ (AUTO CLOSE) จะปิดฐานข้อมูลโดยอัตโนมัติเมื่อไม่มีการเชื่อมต่อใดๆ แล้วเปิดฐานข้อมูลขึ้นมาใหม่เพื่อสร้างการเชื่อมต่อใหม่ การเปิดซ้ำๆ เช่นนี้จะทำให้กระบวนการกู้คืนข้อมูลแต่ละครั้งเกิดขึ้นสั้นๆ ทำให้ดูเหมือนว่าฐานข้อมูลกำลังอยู่ในระหว่างการกู้คืนข้อมูลอยู่ตลอดเวลา การปิดใช้งานการปิดอัตโนมัติ (AUTO CLOSE) จะช่วยแก้ไขปัญหานี้

ถาม: การสำรองข้อมูลบันทึกธุรกรรมสามารถช่วยในระหว่างการกู้คืนได้หรือไม่

A: การสำรองข้อมูลบันทึกธุรกรรม (Transaction log backups) สามารถช่วยเพิ่มพื้นที่ว่างสำหรับบันทึกธุรกรรมได้ หากไดรฟ์สำหรับบันทึกธุรกรรมเต็ม ซึ่งอาจทำให้การกู้คืนดำเนินต่อไปได้ อย่างไรก็ตาม คุณไม่สามารถสำรองข้อมูลบันทึกธุรกรรมของฐานข้อมูลที่อยู่ในโหมดการกู้คืนได้ การสำรองข้อมูลบันทึกธุรกรรมจึงมีประโยชน์มากกว่าสำหรับการป้องกันและบำรุงรักษาหลังการกู้คืน

ถาม: ฉันควรติดต่อฝ่ายสนับสนุนของ Microsoft เมื่อใด

ก: ติดต่อฝ่ายสนับสนุนของ Microsoft สำหรับระบบการผลิตที่สำคัญซึ่งวิธีการกู้คืนในตัวล้มเหลวเมื่อคุณสงสัย SQL Server ข้อบกพร่องของซอฟต์แวร์ สำหรับสถานการณ์ Always On หรือคลัสเตอร์ที่ซับซ้อน หรือเมื่อสภาพแวดล้อมขององค์กรต้องการการกู้คืนข้อมูลที่รับประกันด้วยเวลาหยุดทำงานน้อยที่สุด

ถาม: ฉันจะป้องกันไม่ให้ฐานข้อมูลติดขัดในระหว่างการกู้คืนได้อย่างไร

ก. ดำเนินการสำรองข้อมูลแบบเต็มและบันทึกตามปกติ ตรวจสอบและจัดการจำนวน VLF ตรวจสอบพื้นที่ดิสก์ให้เพียงพอ ใช้ขั้นตอนการปิดระบบที่ถูกต้อง รักษาความน่าเชื่อถือของฮาร์ดแวร์ ปิดการใช้งานการปิดอัตโนมัติบนฐานข้อมูลการผลิต และรันการดำเนินการ DBCC CHECKDB ตามปกติเพื่อตรวจจับความเสียหายในระยะเริ่มต้น

ถาม: VLF คืออะไร และเหตุใดจึงส่งผลต่อการฟื้นตัว?

ตอบ: ไฟล์บันทึกเสมือน (VLF) คือเซกเมนต์ภายในไฟล์บันทึกธุรกรรม VLF จำนวนมาก (มากกว่า 1,000) จะทำให้การกู้คืนช้าลงอย่างมากเนื่องจาก SQL Server ต้องประมวลผลแต่ละรายการแยกกัน การกำหนดขนาดไฟล์บันทึกและการตั้งค่าการเติบโตที่เหมาะสมจะช่วยรักษาจำนวน VLF ที่เหมาะสม

ถาม: ฉันสามารถคืนค่าจากการสำรองข้อมูลในขณะที่ฐานข้อมูลกำลังอยู่ในระหว่างการกู้คืนได้หรือไม่

A: คุณไม่สามารถกู้คืนฐานข้อมูลที่อยู่ในโหมดการกู้คืนได้ คุณต้องรอให้การกู้คืนเสร็จสมบูรณ์ หรือหยุด SQL Server บริการ หรือคืนค่าเป็นชื่อฐานข้อมูลอื่น สำหรับกรณีเร่งด่วน โปรดพิจารณาคืนค่าเป็นชื่อฐานข้อมูลใหม่ แล้วจึงเปลี่ยนชื่อเมื่อปัญหาการกู้คืนได้รับการแก้ไขแล้ว

17. บทสรุปและขั้นตอนถัดไป

17.1 สรุปแนวทางแก้ไขปัญหาหลัก

เมื่อคุณ SQL Server ฐานข้อมูลอยู่ในระหว่างการกู้คืน โปรดเริ่มด้วยวิธีการเหล่านี้ตามลำดับ:

ตรวจสอบบันทึกข้อผิดพลาดและติดตามความคืบหน้า
รอจนกว่าจะเสร็จสมบูรณ์ตามธรรมชาติหากความคืบหน้ามั่นคง
ใช้ RESTORE WITH RECOVERY สำหรับการคืนค่าที่ไม่สมบูรณ์
แก้ไขปัญหาบันทึกธุรกรรม
เรียกใช้ DBCC CHECKDB หรือเครื่องมือระดับมืออาชีพสำหรับการทุจริต
พิจารณาการกู้คืนข้อมูลสำรองสำหรับกรณีที่รุนแรง

ส่วนมาก SQL Server การกู้คืนฐานข้อมูลในสถานการณ์การกู้คืนสามารถแก้ไขได้ภายในไม่กี่ชั่วโมงโดยใช้วิธีการที่ได้รับการพิสูจน์แล้วเหล่านี้ สำหรับสถานการณ์ที่ซับซ้อน อย่าลังเลที่จะใช้เทคนิคขั้นสูงหรือเครื่องมือระดับมืออาชีพ

17.2 แหล่งข้อมูลเพิ่มเติม

สำหรับความช่วยเหลือเพิ่มเติม:

ไมโครซอฟท์ SQL Server เอกสาร
SQL Server ฟอรัมชุมชน
บล็อกการบริหารฐานข้อมูลและทรัพยากรทางเทคนิค
บริการกู้คืนฐานข้อมูลระดับมืออาชีพ

การบำรุงรักษาและการตรวจสอบอย่างสม่ำเสมอช่วยป้องกันปัญหาการกู้คืนข้อมูลส่วนใหญ่ได้ โปรดปฏิบัติตามแนวทางการป้องกันที่ระบุไว้ในคู่มือนี้เพื่อลดโอกาสการเกิดปัญหาการกู้คืนข้อมูล MS SQL ในอนาคต

เกี่ยวกับผู้เขียน

หยวน เซิง เป็นผู้ดูแลฐานข้อมูลอาวุโส (DBA) ที่มีประสบการณ์มากกว่า 10 ปีใน SQL Server สภาพแวดล้อมและการจัดการฐานข้อมูลองค์กร เขาประสบความสำเร็จในการแก้ไขปัญหาการกู้คืนฐานข้อมูลหลายร้อยกรณีในองค์กรด้านบริการทางการเงิน การดูแลสุขภาพ และการผลิต

หยวนมีความเชี่ยวชาญด้าน SQL Server การกู้คืนฐานข้อมูล โซลูชันความพร้อมใช้งานสูง และการเพิ่มประสิทธิภาพการทำงาน ประสบการณ์ภาคปฏิบัติอันกว้างขวางของเขาครอบคลุมการจัดการฐานข้อมูลหลายเทราไบต์ การนำ Always On Availability Groups มาใช้ และการพัฒนากลยุทธ์การสำรองและกู้คืนข้อมูลอัตโนมัติสำหรับระบบธุรกิจที่สำคัญต่อภารกิจ

ด้วยความเชี่ยวชาญทางเทคนิคและแนวทางปฏิบัติ Yuan มุ่งเน้นที่การสร้างคู่มือที่ครอบคลุมซึ่งจะช่วยให้ผู้ดูแลระบบฐานข้อมูลและผู้เชี่ยวชาญด้านไอทีแก้ไขปัญหาที่ซับซ้อน SQL Server ท้าทายอย่างมีประสิทธิภาพ เขาคอยติดตามข่าวสารล่าสุดอยู่เสมอ SQL Server การเปิดตัวและเทคโนโลยีฐานข้อมูลที่พัฒนาอย่างต่อเนื่องของ Microsoft ทดสอบสถานการณ์การกู้คืนเป็นประจำเพื่อให้แน่ใจว่าคำแนะนำของเขาสะท้อนถึงแนวทางปฏิบัติที่ดีที่สุดในโลกแห่งความเป็นจริง

มีคำถามเกี่ยวกับ SQL Server การกู้คืนหรือต้องการคำแนะนำในการแก้ไขปัญหาฐานข้อมูลเพิ่มเติมหรือไม่? หยวนยินดีต้อนรับ ข้อเสนอแนะและข้อเสนอแนะ เพื่อปรับปรุงทรัพยากรทางเทคนิคเหล่านี้

SQL Server ฐานข้อมูลในโหมดการกู้คืน: 10 การแก้ไขที่พิสูจน์แล้ว [คู่มือปี 2026]