لماذا يتسبب النسخ المتماثل SAN في تلف قاعدة بيانات عشوائية؟

Question

وجود مشكلة غريبة مع تقنية استرداد الكوارث نحاول تنفيذها. البيئة في كل من datacenters هي نفس وجود VMware و Sanalogic Dell، وهي نفس الإصدارات.

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

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

سمعت عن أشخاص ينفذون هذا الإجراء بنجاح وهو المهمة الأخيرة في المشروع لمعرفة ذلك قبل أن نتمكن من إغلاق ميثاق المشروع.

كنت آمل حقا أن نتمكن من استخدام ميزات SQL Server مدمجة مثل النسخ المتطابق أو AO-AGS.

إصدارات SQL هي 2008 R2 و 2012. نحن بصدد تثبيت بعض خوادم SQL 2014 الجديدة تماما. أيضا، كلها قياسية، وليس مؤسسة.

أي مدخلات أو أشياء يمكن أن أحاول أن تكون سعيدة، شكرا مقدما !!

تحرير # 1 8/6/15 12:50 PM CST - فيما يلي بعض رسائل الخطأ التي عثر عليها في عارض الأحداث Windows، والتي هي أكثر أو أقل ما الذي تم إنتاجه DBCC.

• EventID 605 - فشل محاولة جلب الصفحة المنطقية (1: 22620) في قاعدة البيانات 26. ينتمي إلى وحدة التخصيص 72057594239385600 بعدم 72057594249412608
• EventID 824 - اكتشف SQL Server خطأ في الإدخال / الإخراج المستند إلى الاتساق من المنطقي: صفيحة غير صحيحة (من المتوقع 1: 1230؛ الفعلي 0: 0). حدث خلال قراءة الصفحة (1: 1230) في معرف قاعدة البيانات 58 عند الإزاحة 0x0000000099c000 في File 'd: \ mydatabase.mdf'. قد توفر رسائل إضافية في سجل خطأ SQL Server أو سجل أحداث النظام مزيدا من التفاصيل. هذه حالة خطأ شديدة تهدد سلامة قاعدة البيانات ويجب أن تكون صحيحة على الفور. إكمال فحص تناسق قاعدة بيانات كاملة (DBCC Checkdb).
• EventID 7886 - فشلت عملية قراءة على كائن كبير أثناء إرسال البيانات إلى العميل. سبب شائع لهذا هو إذا كان التطبيق يعمل في مستوى العزلة غير الملتزم به. سيتم إنهاء هذا الاتصال.
• EventID 608 - لم يتم العثور على إدخال كتالوج لمعرف القسم 72057594383564800 في قاعدة البيانات 23. البيانات الوصفية غير متناسقة. قم بتشغيل DBCC CheckDB للتحقق من تلف البيانات الوصفية.

تحرير # 2 8/6/15 2:24 PM CST - المعلومات المستلمة التي استعادة ملفات .BAK لقواعد البيانات في وضع المشتبه فيه إصلاح الأمر.

Answer 1

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

يمكنك إظهار فريق OPS أنه لا، لا يقوم SQL Server ببيانات فاسدة بشكل عشوائي مثل هذا. يمكنك استعادة النسخ الاحتياطية إلى خادم آخر، النسخ المتطابق للإعداد، وكل هذا يحدث مع عدم وجود تلف. في اللحظة التي نقوم بها النسخ المتماثل على مستوى سان يحدث ذلك. إذا كان خادم SQL تسبب في الفساد مثل هذا لن يكون حوله. يحتوي SQL Server على الملايين تقريبا من خطوط التعليمات البرمجية التي تتعامل مع الفساد وإصلاح الفساد وتقليل إمكانات الفساد. أنت لا تحصل على هذه المشكلة في أي بيئة أخرى وتسبع فقط مع النسخ المتماثل SAN، صحيح؟

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

تحرير: إذا كانت البرامج الثابتة قديمة أو غير متطابقة، احصل على سياسة من فريق OPS الذي يدير SAN الذي ينص على أنهم سيحتفظون بالبرامج الثابتة عبر كومة الآلات التي يديرونها حتى الآن. إذا لم تكن هذه SLA موجودة، فيجب عليك ملاحظة منه إلى مديريك لأنك تعرضت للكثير من القضايا الأخرى إلى جانب هذا واحد.

أنا أفترض أنك تستخدم النسخ المتماثل على مستوى سان بلوك.

قد يكون في كثير من الأحيان أيضا عدم تطابق في الإعدادات. ربما أحجام كتلة مختلفة، إلخ. ولكن يجب أن يكون San OS قادرا على اكتشاف هذه المشكلات عادة.