قصة عيد الميلاد

نريد أن نشارك القصة التي حدثت في أحد مشاريعنا للعام الجديد. جوهر المشروع هو أنه يعمل على أتمتة عمل الأطباء في المؤسسات الطبية. أثناء زيارة المريض ، يكتب الطبيب المعلومات إلى المسجل ، ثم يتم نسخ الصوت. بعد عملية النسخ - أي تحويل التسجيل الصوتي إلى نص - يتم تكوين مستند طبي وفقًا للمعايير ذات الصلة وإرساله مرة أخرى إلى العيادة ، حيث جاء التسجيل الصوتي ، حيث يتلقى الطبيب المرسل ، ويتحقق منه ويوافق عليه. بعد اجتياز الاختبارات الإلزامية ، يتم إرسال المستند إلى المرضى النهائيين.

يمكن تقسيم جميع المؤسسات الطبية التي تستخدم المنتج إلى مجموعتين كبيرتين:

• الاستضافة في مركز بيانات عميلنا ، وهو مسؤول بشكل كامل عن وظائف التطبيق ، سواء للبرامج والأجهزة. على سبيل المثال ، في حالة نفاد مساحة القرص ، أو عدم وجود أداء كافٍ للخادم على وحدة المعالجة المركزية ؛
• ذاتية الاستضافة: يضعون جميع المعدات في المنزل مباشرةً وهم مسؤولون عن أدائها بأنفسهم. يزودهم عملائنا بالتطبيق ودعمه.

هذه هي الطريقة التي يتفاعل بها فريقنا مع الخوادم الطرفية التي يتم استضافتها مباشرة في سحابة عملائنا.



لدينا إمكانية الوصول إلى هذه الخوادم للقيام بجميع الأعمال المجدولة والصيانة المطلوبة.

المجموعة الثانية - العملاء المستضافون ذاتيا - بالنسبة لهم ، تعمل سحابة العميل كبوابة يمكننا من خلالها الاتصال بهذه الخوادم. في هذه الحالة ، لدينا حقوق محدودة ، غالبًا لا يمكننا إجراء أي عمليات بسبب إعدادات الأمان. نحن نتصل بالخوادم من خلال RDP ، بروتوكول سطح المكتب البعيد على نظام التشغيل Windows OS. بطبيعة الحال ، كل هذا يعمل من خلال VPN.

يجب أن يؤخذ في الاعتبار أن كل خادم يمثل في الرسم التخطيطي هو في الواقع مزيج من خادم التطبيقات وخادم قاعدة البيانات. على خادم قاعدة البيانات ، على التوالي ، يتم تثبيت MS SQL Server DBMS وخدمة التقارير SSRS. علاوة على ذلك ، يختلف إصدار MSSQL Server في جميع العيادات: 2008 ، 2012 ، 2014. بالإضافة إلى الإصدارات نفسها ، يتم تثبيت حزم الخدمات المختلفة والتصحيحات في كل مكان. بشكل عام ، حديقة حيوان كاملة.

على خادم التطبيق ، قمنا بتثبيت خادم الويب IIS و ElasticSearch. ElasticSearch هو محرك بحث يقوم أيضًا بتنفيذ بحث النص الكامل.
الجوهر الرئيسي من حيث منتجاتنا هو "الوظيفة". العمل عبارة عن كيان تجريدي يربط جميع المعلومات المتعلقة باستقبال مريض معًا. تتضمن هذه المعلومات:

• بيانات عن الطبيب ؛
• بيانات المريض
• بيانات حول الزيارة ؛
• ملف صوتي (خطاب الطبيب) ؛
• وثائق (عدة إصدارات) ؛
• تاريخ معالجة العمل ؛
• معلومات الفرع ، الخ

يعرض هذا المخطط مخطط قاعدة بيانات مبسطة يمكنك من خلاله رؤية العلاقات بين الجداول الرئيسية. هذا هو الجزء الأساسي فقط ، في الواقع ، تحتوي قاعدة البيانات على أكثر من 200 جدول.



قليلا عن العيادة التي وقع فيها الحادث:

• 1500-2000 عمل يوميًا ؛
• 1000 مستخدم نشط (أطباء + أمناء) ؛
• مستضافة ذاتيا.

DB:

• الحجم: 800+ جيجا بايت (750 كيلو بايت + أعمال و 2 مليون + وثائق) ؛
• DBMS: MS SQL Server 2008 R2؛
• نموذج الاسترداد: بسيط.

هنا أريد أن أقدم بعض الشرح. هناك 3 نماذج استرداد في SQL Server: بسيطة ، مجمعة تسجيل ، والكامل. لن أتحدث عن الثالث الآن ، وسأشرح عن الأول والثاني. الفرق الرئيسي هو أننا في النموذج البسيط لا نقوم بتخزين محفوظات المعاملة في السجل - بمجرد الالتزام بالمعاملة ، سيتم حذف السجل من سجل المعاملات. عند استخدام وضع الاسترداد الكامل ، يتم تخزين محفوظات تغييرات البيانات بالكامل في سجل المعاملات. ماذا يعطينا هذا؟ في حالة حدوث بعض الحالات غير المتوقعة ، عندما نحتاج إلى استعادة قاعدة البيانات من النسخ الاحتياطية ، يمكننا العودة ليس فقط إلى نسخة احتياطية محددة ، ولكن يمكننا العودة إلى أي نقطة في الوقت المناسب ، وحتى معاملة محددة ، أي أننا قمنا بتخزينها في النسخ الاحتياطية ، وليس فقط حالة معينة من قاعدة البيانات في وقت النسخ الاحتياطي ، ولكن هناك أيضا تاريخ كامل من تغييرات البيانات.

أعتقد أنه لا يستحق شرح أن الوضع البسيط يستخدم فقط في التطوير ، على خوادم الاختبار واستخدامه في الإنتاج غير مقبول. بأي حال من الأحوال على الإطلاق.

لكن العيادة ، على ما يبدو ، كانت لديها أفكارها الخاصة حول هذا الموضوع ؛)

ابدأ

بعد أيام قليلة من العام الجديد ، يستعد الجميع للعطلة ، وشراء الهدايا ، وتزيين أشجار عيد الميلاد ، وقضاء حفلات الشركات وينتظرون عطلة نهاية أسبوع طويلة.

22 ديسمبر (الجمعة) يوم واحد

14:31 قال العميل إنه لم يتلق التقرير اليومي التالي. يصل التقرير إلى البريد مرتين يوميًا وفقًا لجدول زمني ؛ وهو ضروري للتحكم في إرسال البيانات إلى نظام تكامل خارجي ، وهو أمر غير مهم للغاية.

يمكن أن يكون هناك عدة أسباب:

1. مشاكل في SMTP ، لم يتم تسليم الرسائل ببساطة (لقد غيروا كلمة المرور ، على سبيل المثال ، ولم يخبروا أي شخص) ؛
2. مشاكل على جانب الخادم من التقارير ؛
3. حدث شيء لقاعدة البيانات.

16:03 تقوم العيادة في بعض الأحيان بتغيير كلمة المرور إلى SMTP ، دون تحذير أي شخص من ذلك ، وبالتالي ، وبعد إكمال المهام الحالية ، نقوم بفحص التقرير يدويًا بهدوء عن طريق تشغيله من خلال واجهة الويب - حصلنا على خطأ يشير إلى وجود مشاكل في قاعدة البيانات.

مثال على الخطأ الذي تلقيناه عند بدء التقرير.

SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0x9876641f; actual: 0xa3255fbf). It occurred during a read of page (1:876) in database ID 7 at offset 0x000000006d8000 in file 'D:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\ServerLive.mdf'. 

يشير هذا إلى أن قاعدة البيانات تحتوي على صفحات تالفة. كان لدينا شعور طفيف بالقلق.

20:53 من أجل تقييم مدى الضرر ، نقوم بتشغيل فحص قاعدة بيانات باستخدام الأمر DBCC CHECKDB الخاص. بناءً على حجم الضرر ، يمكن أن يستغرق الأمر test بعض الوقت ، لذلك نقوم بتشغيل الأمر في الليل. نحن محظوظون هنا أن هذا قد حدث بعد ظهر يوم الجمعة ، وهذا هو ، كان لدينا على الأقل كل أيام العطلة لحل هذه المشكلة.

في تلك اللحظة ، كان الوضع على النحو التالي:

23 ديسمبر (السبت) اليوم الثاني

10:02 في الصباح ، نجد أن التحقق من قاعدة البيانات باستخدام CHECKDB مرن - كان هذا بسبب نقص مساحة القرص الحرة ، لأن أثناء عملية التحقق ، يتم استخدام قاعدة بيانات tempdp المؤقتة بنشاط ، وفي بعض الأحيان نفدت مساحة القرص الحرة.

لذلك ، نقرر بدلاً من التحقق من قاعدة البيانات بأكملها لبدء فحص جدول على الفور. للقيام بذلك ، استخدم الأمر DBCC CHECKTABLE .

10:46 قررنا البدء بجدول JobHistory ، والذي ربما يكون تالفًا ، لأنه تم استخدامه لإنشاء التقرير. يحافظ هذا الجدول ، كما يوحي الاسم ، على تاريخ جميع الأعمال ، أي انتقال العمل بين المراحل.

تشغيل DBCC CHECKTABLE ('dbo.JobHistory') .

التحقق من هذا الجدول يكشف الجداول التالفة في قاعدة البيانات ، والتي كان من المتوقع من حيث المبدأ.

12:00 في الوقت الحالي ، إذا كانت قاعدة البيانات تستخدم نموذج الاسترداد الكامل ، فيمكننا استعادة الصفحات التالفة من النسخة الاحتياطية ، وسيكون ذلك كله ، لكن قاعدة البيانات الخاصة بنا كانت في وضع بسيط. لذلك ، يظل الخيار الوحيد لإصلاح التلف هو بدء تشغيل نفس الأمر باستخدام المعلمة الخاصة REPAIR_ALLOW_DATA_LOSS . هذا قد يؤدي إلى فقدان البيانات.

نبدأ. ينتهي الفحص مرة أخرى بخطأ - لقد حصلنا على خطأ بأن استعادة هذا الجدول مستحيلة حتى تتم استعادة الجداول ذات الصلة. يشير جدول المحفوظات إلى جدول العمل (الوظائف) بالمفتاح الخارجي ، وبالتالي ، فإننا نستنتج أن هناك أيضًا تلفًا في جدول العمل الرئيسي (الوظائف).

13:30 الخطوة التالية هي التحقق من جدول الوظائف ، في نفس الوقت - نأمل أن يكون الضرر في الفهرس ، وليس في البيانات. في هذه الحالة ، سيكون كافياً إعادة بناء الفهرس لاستعادة البيانات.

17:33 بعد فترة قصيرة ، نجد أن خادمنا غير متاح عبر RDP. ربما تم إيقاف تشغيله ، ولم يكتمل التحقق ، وتم تعليق العمل. نعلم العيادة أن الخادم غير متاح ، يرجى رفعه.

القلق المعتدل يأخذ أشكالًا محددة جدًا.

24 ديسمبر (الأحد) اليوم الثالث

14:31 الأقرب إلى العشاء ، يتم رفع الخادم ، ونحن إعادة تشغيل الاختيار جدول الوظائف.
DBCC CHECKTABLE ('dbo.Jobs')

16:05 لم يكتمل التحقق ، الخادم غير متوفر. مرة اخرى

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

بسبب الأعياد ، كان التواصل بيننا وبين العميل بطيئًا - كنا نتوقع إجابات على الأسئلة لعدة ساعات.

25 ديسمبر (الاثنين - عيد الميلاد) اليوم الرابع

16:00 في اليوم التالي الذي تم فيه رفع الخادم ، يكون لدى العميل عيد الميلاد ، ونبدأ مرة أخرى في التحقق من الجدول ، لكن هذه المرة نستبعد الفهارس من الفحص ، ونترك فحص البيانات فقط. وبعد مرور بعض الوقت ، لا يتوفر الخادم مرة أخرى.

ما الذي يحدث؟

في هذه اللحظة ، تبدأ الأفكار في الزحف إلى أن هذه ليست مجرد صدفة ، وهناك شك في أنه قد يكون هناك ضرر على مستوى الحديد (سقط القرص الصلب). نفترض أن هناك قطاعات تالفة على القرص وعندما يحاول الفحص قراءة البيانات من هذه القطاعات ، يتعطل النظام. نبلغ عملائنا عن افتراضنا.

يدير العميل فحص القرص على الجهاز المضيف.

17:19 ذكرت خدمة تكنولوجيا معلومات العيادة أن ملف الجهاز الظاهري معطوب - هذا سيء! (
لا يمكننا العمل بعد ، ونحن ننتظر إشارة عند حل المشكلة ويمكننا مواصلة عملنا.

26 ديسمبر (الثلاثاء) يوم 5

14:05 تطلق خدمة عيادة تقنية المعلومات عملية أخرى لاستعادة القرص. قيل لنا أنه يمكننا تشغيل CHECKTABLE بالتوازي للتحقق من الجدول. نبدأ الاختبار مرة أخرى - تعطل الجهاز الظاهري مرة أخرى ، ونعلم العميل أن ملف الجهاز الظاهري لا يزال تالفًا.

في هذه الأيام ، تكون جميع الاتصالات مع العميل بطيئة للغاية مع تأخر زمني كبير بسبب الأعياد.

27 ديسمبر (الأربعاء) يوم 6

14:00 نبدأ فحص القرص باستخدام Windows - checkdisk داخل الجهاز الظاهري - لم يتم اكتشاف أي مشاكل.
قاعدة البيانات في الوضع البسيط ، لذا فإن فرص إصلاح قاعدة البيانات الحالية باستخدام أدوات DBMS تميل إلى الصفر ، لأن لا يمكننا استرداد الصفحات التالفة الفردية.
لقد بدأنا في النظر في خيار التراجع واستعادة قاعدة البيانات من النسخة الاحتياطية.
نتحقق من النسخ الاحتياطية لقاعدة البيانات ونكتشف أن النسخ الاحتياطية لم تُصنع باستخدام وسائل إدارة قواعد البيانات ، وكان آخر نسخة احتياطية في عام 2014 ، أي لا توجد نسخ احتياطية من قاعدة البيانات. لماذا لم يفعلوا ذلك مسألة منفصلة ، تقع على عاتق العيادة مسؤولية ضمان كفاءة وسلامة قاعدة البيانات.

هناك احتمال كبير أنه لن يعمل على استعادة قاعدة البيانات الحالية ، نبدأ في النظر في خيارات أخرى للتراجع.

دعونا نتناول بمزيد من التفصيل الموقف مع النسخ الاحتياطية في العيادة.

الوضع مع النسخ الاحتياطي:

• لا توجد نسخ احتياطية لقاعدة البيانات (!!!)
• لا توجد لقطات للجهاز الظاهري (!؟)
• ولكن هناك نسخ احتياطية على القرص (كاملة + المؤتمر الوطني العراقي)

قاعدة البيانات على القرص D ، على التوالي ، قاموا بعمل نسخ احتياطية كاملة أسبوعية ونسخ احتياطي تزايدي يومي.

• كل يوم جمعة في الساعة 20:00 نسخة احتياطية كاملة
• كل يوم النسخ الاحتياطي التزايدي
• هناك نسخة احتياطية كاملة من 15 و 22
• هناك نسخ احتياطية اليومية حتى 21st

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

في الوقت نفسه ، أرسلت العيادة طلبًا إلى مورد الحديد (HP) تم وضع علامة "عاجل" عليه.

28 ديسمبر (الخميس) يوم 7

13:13 تبدأ خدمة IT Clinic في إعداد جهاز افتراضي جديد ، على النحو التالي لا يمكن إصلاح التلف في ملف الجهاز الظاهري القديم.

19:09 يتوفر جهاز ظاهري جديد مع تثبيت SQL Server.
والخطوة التالية هي استعادة قاعدة البيانات من النسخ الاحتياطي للقرص. بادئ ذي بدء ، قررنا العودة إلى اليوم الثاني والعشرين ، إذا كانت المشكلة لا تزال قائمة ، فعدنا إلى 21 ، 20 وما إلى ذلك ، حتى نصل إلى حالة عمل.

كان اليوم الثامن والعشرين في الفناء ، كنا في حفلة الشركات ، وهنا يخبروننا أن العيادة تعاني من مشاكل في استعادة النسخ الاحتياطية ، لأن النسخ الاحتياطية خالية!

هذا هو الخبر!

عند استعادة نسخة احتياطية من محرك الأقراص D من 21 ، اتضح أنه فارغ ، مثل أي شخص آخر. تم الحصول على نسخ احتياطية مباشرة من أداة التقطيع - يبدو أنها موجودة ، لكن في نفس الوقت لم تكن كذلك. ليس من الواضح تمامًا كيف حدث هذا على الإطلاق ، ولكن بقدر ما استطعنا فهمه ، فإن النقطة المهمة هي عدم وجود مساحة كافية على القرص لتخزين النسخ الاحتياطية للقرص. لقد خصصوا 500 غيغابايت من النسخ الاحتياطية للتخزين ، ولكن وقت وقوع الحادث ، كانت قاعدة البيانات تزن بالفعل 800 غيغابايت ، وبالتالي ، من حيث المبدأ ، لا يمكن أن تكون النسخة الاحتياطية ناجحة. أي تم إجراء النسخ الاحتياطي بشكل منتظم وفقًا للجدول الزمني ، ولكن نظرًا لنقص المساحة ، انتهى الأمر إلى حدوث خطأ ، وبالتالي كانت فارغة ، ولم يكن لدى خدمة تكنولوجيا المعلومات في العيادة فكرة التحقق من أن كل شيء على ما يرام. لا تفعل ذلك.

29 ديسمبر (الجمعة) يوم 8

13:11 مناقشة المزيد من الإجراءات. الخيارات الممكنة:

• محاولة نسخ ملفات قاعدة البيانات (ملفات .ldf + .two) - فرص النجاح منخفضة للغاية ؛
• محاولة النسخ الاحتياطي لقاعدة البيانات مرة أخرى فرصة ضئيلة جداً؛
• تكوين النسخ المتماثل - قد تعمل.

تم تخصيص محرك أقراص بسعة 1 تيرابايت على الخادم الجديد ، ومن الواضح أنه لا يكفي إذا حاولنا النسخ الاحتياطي والاستعادة منه ، لأننا في أسوأ الحالات ، بدون ضغط ، سوف تشغل النسخ الاحتياطية مساحة كبيرة مثل مساحة قاعدة البيانات الأصلية ، أي 800 جيجا بايت
الرجاء إضافة أماكن على الخادم الجديد ومتابعة نسخ ملفات قاعدة البيانات.
تم إنشاء قاعدة بيانات على الخادم الجديد وتمت استعادة مخطط قاعدة البيانات - سيسمح ذلك على الأقل بمعالجة عمل جديد. ستكون العيادة قادرة على الأقل على قبول مرضى جدد باستخدام مثل هذا النظام.

14:36 لذلك ، ننتقل إلى الخيار رقم واحد ، على الرغم من أننا لا نتوقع الكثير من النجاح.
أوقف SQL Server ، وابدأ في نسخ ملف البيانات (mdf) وسجل (ldf).

16:13 بعد نصف ملف السجل ، تم نسخه بنجاح (48 جيجا بايت) ، وتم بالفعل نسخ 50 جيجابايت من ملف البيانات (بقي 795 من 846 غيغابايت). بهذه السرعة ، سيستغرق إكمال النسخة حوالي 12 ساعة.

16:30 تم إيقاف تشغيل خادم قاعدة البيانات القديم أثناء نسخ الملف ، وهو أمر متوقع تمامًا.

17:09 لذلك ، ننتقل إلى الخيار التالي - إعداد النسخ المتماثل ، بينما يمكننا تحديد البيانات التي سيتم نسخها ، أي أنه يمكننا أولاً استبعاد الجداول التالفة عمداً ونسخ البيانات غير التالفة أولاً ، ثم نقل الجداول الإشكالية في الأجزاء. لكن هذا الخيار ، لسوء الحظ ، لا يعمل أيضًا ، لأنه لا يمكننا حتى إنشاء منشور مع جداول معينة بسبب تلف قاعدة البيانات.
نحن ندرس أيضًا خيارات نقل البيانات.

20:01 نتيجة لذلك ، بدأنا ببساطة في نقل البيانات من الخادم القديم إلى الخادم الجديد عن طريق الاستيراد والتصدير بترتيب الأولوية.

21:35 أولاً ، البيانات الأكثر أهمية ، ثم الأرشفة والأقل أهمية (حوالي 300 جيجابايت). في موجة التصدير الأولى ، بقي أقل من 300 جيجابايت من البيانات. جدول المستندات (300 جيجابايت) مستبعد أيضًا. نبدأ عملية النسخ في الليل.

30 ديسمبر (السبت) يوم 9

15:00 نواصل نقل البيانات. جدول الوظائف غير متاح على الإطلاق. تم نسخ معظم الجداول في هذا الوقت.
لكن بدون الوظائف ، كل هذا لا فائدة منه ، لأنه الرابط الرئيسي بين جميع البيانات ويمنحهم المعنى والقيمة من وجهة نظر العمل. بدون ذلك ، لدينا فقط مجموعة بيانات متباينة لا يمكننا استخدامها.

أيضًا ، في هذه المرحلة ، تم إكمال استرداد مخطط قاعدة البيانات.

عواقب الحادث:

في هذه المرحلة ، لدينا خسارة هائلة في البيانات الحية.
أي بشكل رسمي ، لدينا بعض البيانات في قاعدة البيانات ، ولكن في الواقع ، لا توجد طريقة لاستخدامها أو توصيلها ، حتى نتمكن من التحدث عن الفقدان الكامل للبيانات.
فقدت البيانات على أكثر من 750،000 قبول المريض.

هذا محزن حقا!

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

بدأنا في التفكير فيما يمكننا القيام به في هذا الموقف. بدأوا في الفرز بين النظام والعظام للعثور على أدلة.

15:16 من خلال تحليل جميع جوانب النظام ، نفهم أنه يمكننا محاولة استخراج البيانات المفقودة من فهرس ElasticSearch. الشيء هو أنه بسبب التكوين غير الصحيح لفهارس البحث المرنة ، فإنه لا يخزن فقط الحقول التي يتم بها إجراء البحث عن النص الكامل ، ولكن بشكل عام كل شيء ، وهذا هو ، في الواقع ، هناك نسخة كاملة من البيانات ، ويمكننا استخراج البيانات من الناحية النظرية حول الأعمال ووضعها مرة أخرى إلى قاعدة البيانات الخاصة بنا. من المأمول أن تظل البيانات قادرة على الاسترداد.

خطأ يمكنك وضع نصب تذكاري عليه!



18:00 تمت كتابة الأداة المساعدة بسرعة لاستخراج البيانات ، وبعد بضع ساعات نتأكد من أن النهج يعمل ويمكن استعادة البيانات.

20:00 بدأت استعادة العمل من ElasticSearch بمساعدة أداة مكتوبة. النهج الذي نجح ، يمكننا استعادة البيانات على العمل. بالتوازي ، نبدأ في استخراج أحدث إصدارات الوثيقة لكل عمل.

31 ديسمبر (الأحد - رأس السنة الجديدة) يوم 10

14:09 خلال الليل ، تم استعادة 188 811 عمل.

20:13 نظرًا لنجاحنا ، قررت العيادة تأجيل نقل الخادم إلى خدمة HP من أجل منحنا الوقت لاستخراج الحد الأقصى من البيانات من الخادم القديم.
مع مثل هذه الأخبار ، احتفلنا بالعام الجديد))

01 يناير (الاثنين) اليوم الحادي عشر

11:23 الاستعداد لبدء النظام بعد الحادث:

• إعادة تكوين IIS على خادم التطبيقات ؛
• إعادة تكوين جميع الخدمات اللازمة للعمل مع خادم قاعدة البيانات الجديد ؛
• مشغلات ، الإجراءات المخزنة ، وظائف المستعادة.

14:28 ثم بدأوا في نسخ جدول الوثائق ، والذي تم تخطيه بسبب الحجم الكبير أثناء النقل الأولي.
- يغلق خادم DB القديم مرة أخرى. من الواضح أن جدول المستندات تالف أيضًا ، حيث يتم تخزين جميع معلومات المريض. لحسن الحظ ، إنه غير تالف تمامًا ، يمكننا تقديم طلبات إليه ، وعندما يعيد طلب إلينا سجلًا تالفًا ، في تلك اللحظة تعطل الخادم وإيقافه. يمكننا استخراج بعض البيانات.

وفقًا لذلك ، فإننا نشير إلى العميل ، ويقومون برفع الخادم ، وفي موازاة ذلك نستمر في إعداد قاعدة البيانات الجديدة لإطلاق النظام.

18:01 استعادة جميع قيود النزاهة بعد نقل الجزء الرئيسي من البيانات.

22:02 استعادة القيود مكتملة. لقد قمنا ببساطة بنقل البيانات الخام إلى الحد الأقصى. وجود قيود النزاهة من شأنه أن يعقد مهمتنا إلى حد كبير.

02 يناير (الثلاثاء) يوم 12

05:52 تم إيقاف تشغيل خادم DB القديم مرة أخرى أثناء نسخ المستند. لقد تربى على الفور حتى نتمكن من مواصلة العمل.

09:00 كان من الممكن تجميع حوالي 200000 مستند (20٪ تقريبًا)
بدأنا باستخدام طرق استرداد مختلفة: الفرز حسب أعمدة مختلفة للحصول على البيانات من نهاية أو بداية الجدول ، حتى نتعثر على جزء تالف من الجدول.

13:42 بدأت نسخ أعمال الأرشفة في الجدول - لحسن الحظ ، لم تتم إتلافها.

17:08 استعادة جميع أعمال الأرشفة (491 380 قطعة).

النظام جاهز لبدء التشغيل: يمكن للمستخدمين إنشاء عمل جديد ومعالجته.

لسوء الحظ ، نظرًا للتلف الجزئي لجدول المستندات ، لا يمكنك نقل جميع البيانات منه ، كما هو الحال مع الجداول الأخرى ، لأن الجدول معطوب جزئيًا. لذلك ، عند محاولة استرداد جميع البيانات ، يتعطل الطلب عند محاولة قراءة الصفحات التالفة. لذلك ، نقوم باستخراج البيانات بشكل عمودي باستخدام أنواع مختلفة وحجم العينة:

• الفرز حسب حقول مختلفة (ID ، DateTime) ؛
• فرز تصاعدي ، تنازلي ؛
• العمل مع مجموعات صغيرة من الخطوط (1000 ، 100) ؛
• جلب وظائف عن طريق الهوية.

03 يناير (الأربعاء) يوم 13

08:58 تابع عملية استعادة الوثائق. تمت استعادة المستندات فقط للعمل النشط غير المكتمل. عند هذه النقطة ، 1000 يعمل (نشط) بدون مستندات.

11:38 تم ترحيل جميع وظائف SQL

13:17 5 يعمل بدون مستندات ، 231 لا يعمل ، لكن يوجد ملف صوتي ، تحتاج إلى إعادة المزامنة.

04 يناير (الخميس) يوم 14

بدأ الاسترداد اليدوي والتحقق من العمل المتبقي.
يعمل النظام ، ومراقبة وإصلاح الأخطاء عبر الإنترنت.

05 يناير (الجمعة) يوم 15

الإبلاغ عن الترحيل إلى SSRS المخطط لها.
نقل إلى خادم جديد غير ممكن ، لأن قامت العيادة بتثبيت إصدار أقدم من SQL Server ولن تعمل على نقل قاعدة البيانات من الخادم القديم.

خيارات:

• ترقية SQL Server من 2008 إلى 2008 R2 ؛
• تكوين كل شيء من الصفر.

تقرر انتظار تحديث SQL Server.

09:21 بدأت عملية استعادة الخلفية للوثائق الخاصة بالعمل المكتمل - العملية طويلة وستستغرق عدة أيام.

13:28 تغيير أولوية استعادة الوثائق من قبل الإدارات.

18:18 منحت العيادة إمكانية الوصول إلى SMTP وإعداد البريد

النتيجة:

• تمت استعادة جميع البيانات تقريبًا (تم فقد 5 وظائف فقط) ؛
• صدرت توصيات بشأن صيانة قواعد البيانات لمنع مثل هذه الحالات ؛
• يتم تكوين النسخ الاحتياطية لقاعدة البيانات باستخدام SQL Server؛
• رصد إضافي للنسخ الاحتياطية من جانبنا ، والتنبيهات في حالة الفشل.