كيفية إصلاح قاعدة بيانات SQL عالقة في وضع الاسترداد

قواعد بيانات خادم SQL تدخل أحيانًا وضع “In Recovery”، والذي قد يفاجئ مسؤولي قواعد البيانات. يحدث هذا الحالة أثناء إعادة التشغيل، أو استعادة قاعدة البيانات، أو إغلاق غير متوقع، حيث يعيد خادم SQL تشغيل أو التراجع عن المعاملات غير المكتملة للحفاظ على سلامة البيانات. على الرغم من أن هذه العملية عادة ما تكون تلقائية، يمكن أحيانًا أن تستغرق وقتًا أطول من المتوقع — أو حتى تبدو معلقة — مما يجعل المسؤولين غير متأكدين من كيفية المتابعة.

إذا واجهت هذه المشكلة، لا داعي للقلق. ستساعدك هذه المقالة على فهم ما يحدث خلف الكواليس وستعلمك كيفية الاستجابة. ها هو نظرة سريعة على ما ستتعلمه:

• ماذا يعني وضع “In Recovery” — لماذا تدخل قاعدة البيانات الخاصة بك في هذه الحالة وما الذي يقوم به خادم SQL في الخلفية.
• المراحل الثلاثة للانتعاش — تفصيل واضح لمراحل التحليل، وإعادة العمليات، والتراجع التي يتبعها خادم SQL أثناء الانتعاش.
• الأسباب الشائعة للتأخير — من السجلات الكبيرة للملفات الظاهرية الزائدة (VLFs)، انظر ما قد يبطئ العملية.
• كيفية العودة عبر الإنترنت — تعلم الخطوات العملية لاستعادة قاعدة البيانات الخاصة بك إلى حالة متسقة، من انتظار الوضع إلى استخدام أدوات إصلاح SQL.
• متى تلجأ إلى المساعدة المتقدمة — ما الذي يجب فعله إذا بدت عملية الاسترداد معلقة ولا تحدث أي تقدم.

بحلول نهاية هذا الدليل، ستكون لديك فهم قوي لعملية الانتعاش في خادم SQL والأدوات التي يمكنك استخدامها لإعادة قاعدة البيانات الخاصة بك عبر الإنترنت بأسرع ما يمكن.

فهم “In Recovery” Mode في خادم SQL

عند إعادة تشغيل SQL Server أو عند استعادة قاعدة بيانات من النسخ الاحتياطي، يدخل وضع “In Recovery” للحفاظ على سلامة البيانات. خلال هذه المرحلة، يعيد SQL Server تشغيل أو يلغي المعاملات غير المكتملة لمنع تلف البيانات وضمان الاتساق التحويلي.

بعد إعادة تشغيل SQL Server، تنتقل قاعدة البيانات إلى وضع “In Recovery”. قد ترى أيضًا قاعدة بيانات SQL Server في حالة الاسترداد عند بدء تشغيلها أو عند استعادتها من النسخ الاحتياطي.

الشكل 1- وضع قاعدة بيانات SQL “In Recovery”

حالة “الاستعادة” للقاعدة البيانات تعني أن القاعدة تقوم بعملية استعادة وسوف تصبح عبر الإنترنت تلقائيًا بمجرد اكتمال العملية. ومع ذلك، قد تواجه أن الاستعادة بطيئة، وأن القاعدة البيانات معلقة في حالة استعادة. قد تظل قاعدة البيانات الخاصة بك في حالة الاستعادة، حيث تخضع قواعد بيانات SQL لثلاث مراحل من الاستعادة، والتي قد تستغرق وقتًا يعتمد على حجم ملفات قاعدة البيانات الخاصة بك.

المراحل الثلاث لاستعادة قاعدة بيانات SQL

عادة، عندما لا تتم إغلاق قاعدة البيانات بشكل صحيح عند إعادة تشغيل SQL Server، تخضع لعملية استعادة الانهيار، لضمان استمرار توازن قاعدة البيانات. هناك ثلاث مراحل من الاستعادة التي يجب أن تمر بها DB SQL:

المرحلة 1: التحليل

تبدأ هذه المرحلة من “آخر نقطة فحص حتى نهاية سجل المعاملات.” إنشاء جدول ‘Dirty Page Table’ (DPT) الذي يساعد في تحديد جميع الصفحات القذرة في وقت الانهيار. أيضًا، يتم إنشاء جدول ‘Active Transaction Table’ (ATT) لتحديد المعاملات غير المؤكدة عند توقف خادم SQL.

المرحلة 2: إعادة التنفيذ

في هذه المرحلة، يقوم خادم SQL بإعادة تنفيذ جميع التغييرات التي حدثت بعد النقطة الفحصية وقبل الانهيار. في جوهره، في مرحلة إعادة التنفيذ، يجب إعادة تنفيذ جميع المعاملات التي تم تأكيدها ولم تُكتب بعد إلى ملف بيانات SQL (.mdf/.ldf) عبر النقطة الفحصية.

المرحلة 3: التراجع

إذا كانت هناك أي معاملات غير مؤكدة في وقت استعادة قاعدة البيانات، يجب تراجعها في مرحلة التراجع لجلب قاعدة البيانات إلى حالة متسقة.

ماذا تفعل إذا كانت قاعدة البيانات الخاصة بك محتجزة في وضع الاستعادة؟

تحقق من سجل أخطاء خادم SQL لرؤية أول رسالة في قاعدة البيانات التي قد تبدو مماثلة لـ:

Starting up database ‘DatabaseName’

هذا يعني أن ملفات قاعدة البيانات مفتوحة، وقد بدأت عملية الاستعادة. في وقت لاحق، يجب أن ترى خادم SQL يخضع لـ 3 مراحل من عملية الاستعادة. إذا كنت تبحث عن إرشادات حول كيفية نسخ احتياطية واستعادة قاعدة البيانات الخاصة بك، تحقق من دليل النسخ الاحتياطي واستعادة قواعد بيانات SQL Azure.

تُظهر المرحلة 1 من استعادة قاعدة البيانات أدناه:

Recovery of database ‘DatabaseName’ (9) is 0% complete (approximately 95 seconds remain). Phase 1 of 3. This is an informational message only. No user action is required.

​

Recovery of database ‘DatabaseName’ (9) is 3% complete (approximately 90 seconds remain). Phase 1 of 3. This is an informational message only. No user action is required.

بعد الانتهاء من المرحلة 1، سيخضع خادم SQL لمرحلتي 2 و 3 من الاسترداد:

Recovery of database ‘DatabaseName’ (9) is 5% complete (approximately 85 seconds remain). Phase 2 of 3. This is an informational message only. No user action is required…

​

Recovery of database ‘DatabaseName’ (9) is 95% complete (approximately 40 seconds remain). Phase 2 of 3. This is an informational message only. No user action is required.

​

Phase 3 of 3. This is an informational message only. No user action is required.

بمجرد اكتمال المرحلتين 2 و 3، سترى شيئًا مشابهًا لما يلي:

3807 transactions rolled forward in database ‘DatabaseName’ (9). This is an informational message only. No user action is required.

​

0 transactions rolled back in database ‘DatabaseName’ (9). This is an informational message only. No user action is required.

​

Recovery is writing a checkpoint in database ‘DatabaseName’ (9). This is an informational message only. No user action is required.

​

Recovery completed for database DatabaseName (database ID 9) in 30 second(s) (analysis 1289 ms, redo 29343 ms, undo 72 ms.) This is an informational message only. No user action is required.

في سجل الأخطاء، انتبه إلى الرسالة ‘لا توجد إجراءات مطلوبة للمستخدم’. هذا يشير إلى أن قاعدة البيانات في حالة استرداد. ومع ذلك، قد يستغرق الاسترداد وقتًا أطول من المتوقع، وسيكون قاعدة البيانات عالقة في وضع الاسترداد.

الأسباب وراء تعليق قاعدة بيانات SQL في وضع “في حالة استرداد”

فيما يلي الأسباب التي قد تؤدي إلى تعليق قاعدة بيانات SQL في وضع الاسترداد:

• تتم إلغاء تنفيذ معاملة تعمل لفترة طويلة
• حجم ملف سجل المعاملات كبير
• هناك الكثير من الملفات الافتراضية الصغيرة (VLFs) داخل سجل معاملات قاعدة البيانات
• كان هناك خطأ في خادم SQL، والذي تم إصلاحه الآن.

ما يمكنك فعله لجلب قاعدة البيانات إلى حالة متسقة؟

حل وسط 1: انتظر اكتمال استرداد البيانات

الحل الأكثر وضوحًا لإعادة قاعدة البيانات عبر الإنترنت هو أن تكون صبورًا وتنتظر اكتمال عملية الاسترداد؛ يمكن أن يستغرق ذلك ساعات أو أيام. إذا كان الاسترداد يستغرق وقتًا طويلًا أكثر من المتوقع لقاعدة بيانات في خادم SQL 2008 أو 2008 R2، فقد تساعد تطبيق إصلاحات Microsoft.

ملاحظة: تجنب تشغيل أمر الاستعادة لجعل قاعدة البيانات متاحة على الإنترنت في حالة متسقة، حيث إن SQL Server يحاول بالفعل تنفيذ نفس المهمة. وبدء تشغيل ‘RESTORE with..Recovery’ يعني أن قاعدة البيانات ستخضع لنفس الخطوات مرة أخرى.

حل 2: استخدم أداة احترافية لإصلاح قاعدة بيانات SQL

إذا اكتملت عملية الاستعادة ولكنها فشلت في جعل قاعدة البيانات في حالة متسقة، فإن استخدام أداة إصلاح SQL متخصصة قد يساعد في استعادة قاعدة البيانات إلى حالتها الأصلية.

• Stellar Repair for MS SQL — أداة متخصصة تساعد في استعادة قواعد بيانات SQL إلى حالتها الأصلية بعد التلف أو الفشل.
• ApexSQL Recover — تساعد هذه الأداة في استعادة بيانات قاعدة بيانات SQL Server المحذوفة أو المقصوصة أو التالفة.
• dbForge SQL Complete — بينما هي في الأساس إضافة لـ IDE، توفر ميزات مفيدة للتعامل مع الأخطاء وحل المشكلات.
• Redgate SQL Data Recovery — تقدم Redgate مجموعة من أدوات SQL Server، بما في ذلك ميزات استعادة البيانات.
• SysTools SQL Recovery Tool — معروفة باستعادة ملفات قاعدة بيانات SQL التالفة أو المعطلة (.MDF و .NDF) وإعادتها إلى حالة قابلة للاستخدام.
• Kernel for SQL Database Recovery — يمكن لهذه الأداة استعادة واسترجاع قواعد بيانات SQL Server من كل من التلف والإيقاف غير المتوقع.
• Aryson SQL Database Recovery — أداة أخرى يمكنها إصلاح واستعادة ملفات MDF و NDF في SQL Server.

خاتمة

في هذا المقال، تناولنا معنى عدم قدرة قاعدة بيانات SQL على الخروج من وضع “In Recovery”، والمراحل الثلاث الحرجة للإسترداد (التحليل، الإعادة، والتراجع)، وما يمكنك فعله لإعادة القاعدة بيانات للعمل مرة أخرى. كما ناقشنا الأسباب المحتملة، من سجلات معاملات كبيرة إلى الكثير من الملفات السجلية الافتراضية (VLFs).

إذا كانت قاعدة بيانات SQL الخاصة بك ما زالت عالقة في وضع الاسترداد، تذكر أن الصبر هو العنصر الأساسي. تجنب تشغيل أمر RESTORE، حيث يعيد هذا العملية الاسترداد. بالنسبة للمشاكل الخطيرة التي تفشل فيها التدخل اليدوي، يُنصح بالنظر في استخدام أداة اصلاح قاعدة بيانات SQL احترافية لاستعادة بياناتك.

إذا وجدت هذا الدليل مفيدًا، شاركه مع فريقك أو اترك تعليقًا مع تجاربك في استعادة قاعدة البيانات SQL.