كانت مساحة القرص غير الكافية على خوادم قاعدة البيانات هي السبب وراء إنتاج سيارات تويوتا تحن حتى التوقف لمدة 36 ساعة في 14 مصنعًا في اليابان في أواخر أغسطس.
ولكن كيف تنشأ مثل هذه الحالة؟ ما هو محتمل جدًا هنا هو الفشل في تخطيط سعة قاعدة البيانات و لتوفير مساحة تخزين كافية.
وهذا نشاط قد يقع في كثير من الأحيان تحت رادار كبار المسؤولين، ولكن إذا سارت الأمور على نحو خاطئ، فسوف تكون النتيجة محسوسة بشدة. إن أي تقديرات لما فقده الإنتاج في 14 مصنعًا لشركة تويوتا لمدة يوم ونصف يجب أن تكون ضخمة جدًا.
اذا ماذا حصل؟ اخماد تويوتا بيان صحفي التي ذكرت أن الهجوم السيبراني ليس هو المسؤول. وبدلاً من ذلك، قالت: “لقد حدث خلل في النظام بسبب عدم توفر بعض الخوادم المتعددة التي تعالج طلبات قطع الغيار”، وهو جزء مهم من نظام الإنتاج البسيط/في الوقت المناسب. التي تشتهر بها تويوتا. “[R]تم إجراء أعمال الصيانة الدورية في 27 أغسطس، أي اليوم السابق لحدوث العطل. أثناء إجراء الصيانة، تم حذف وتنظيم البيانات المتراكمة في قاعدة البيانات، وحدث خطأ بسبب عدم وجود مساحة كافية على القرص، مما أدى إلى توقف النظام.
ومضى البيان الصحفي ليقول: “بما أن هذه الخوادم كانت تعمل على نفس النظام، فقد حدث فشل مماثل في وظيفة النسخ الاحتياطي”.
المفتاح هنا هو ما يبدو وكأنه فشل في تخطيط سعة قاعدة البيانات. قد تكون هذه هي المشكلة المحتملة إذا تم “حذف وتنظيم” البيانات الموجودة في قاعدة البيانات (وهذا يعني “إعادة تنظيمها”) لأن حذف البيانات لا يؤدي إلى ملف قاعدة بيانات أصغر، بل قد يؤدي إلى نموه.
بالإضافة إلى ذلك، يبدو أيضًا أنه تم التغاضي عن الإجراء الأساسي لتخفيف المخاطر المتمثل في فصل الإنتاج والتخزين الاحتياطي، ولكننا سنترك ذلك جانبًا في الوقت الحالي.
يعد تحديد حجم قاعدة البيانات – التنبؤ باحتياجات تخزين قاعدة البيانات – وتخطيط السعة، وهي ممارسة التوفير المستمر لسعة التخزين المطلوبة، من المهارات الأساسية لـ مديري قواعد البيانات.
يعد تخطيط السعة أكثر تعقيدًا مما قد يتخيله الشخص العادي لأن حجم ملفات قاعدة البيانات لا ينمو ويتقلص حسب الحاجة دون مزيد من التأثيرات.
في البداية، قاعدة البيانات (العلائقية) ليست مجرد قاعدة بيانات. تتكون “قاعدة البيانات” من ملف قاعدة بيانات يتم فيه تحديد الصفوف والأعمدة المخصصة والجداول المتعددة والمتصلة. ولكن، هناك أيضًا ملفات مؤقتة، مثل ملفات TempDB الخاصة بـ SQL Server. هناك أيضًا فهارس للسماح بالوصول السريع إلى صفوف معينة مستخدمة بشكل متكرر، وملفات السجل التي تسجل جميع أنشطة قاعدة البيانات، والنسخ الاحتياطية التي تم إنشاؤها بواسطة قاعدة البيانات والتطبيقات المرتبطة بها.
كما أن أنظمة قواعد بيانات الموردين المختلفة لها تطبيقات مختلفة لهذه العناصر الأساسية ويمكن أن تشغل أحجامًا مختلفة من سعة التخزين لنفس حجم قاعدة البيانات الاسمية.
20000 عقدة (مضيف، خادم، وما إلى ذلك)، حجم ملف قاعدة البيانات 20 جيجابايت في خادم SQL، على سبيل المثال، يتطلب 46 جيجابايت عند أخذ ملفات السجل وملفات TempDB والنسخ الاحتياطية في الاعتبار. سيشغل حجم ملف قاعدة البيانات المكافئ في Oracle وPostgreSQL 90 جيجابايت و26 جيجابايت على التوالي.
مشكلة عمليات الحذف في قاعدة البيانات – والتي حددتها تويوتا كسبب لمشاكلها – هي أن حذف قاعدة البيانات لا يقلل من حجم الملف. إذا تمت إزالة صف، فلن تتم إزالة المساحة المخصصة له. لقد تم وضع علامة عليها على أنها غير مستخدمة. يتم تعيين حجم قاعدة البيانات عندما يتم تكوينها في الأصل وإعادة تعيينها بشكل دوري طوال عمرها الافتراضي، ولكن الشيء الأساسي هو تخصيص المساحة والبقاء على هذا النحو، وذلك في المقام الأول للتأكد من أن احتياجات التخزين لا تطغى فجأة على نوبات ضخمة من الانكماش والنمو. إنها إلى حد كبير وصية جوهرية في عالم DBA وهي أن قواعد البيانات لا تتقلص أبدًا.
ملفات السجل والملفات المؤقتة
ثم هناك ملفات السجل والملفات المؤقتة، والتي يمكن أن تتضخم فجأة في الحجم مع ارتفاع كبير في المعاملات، كما هو الحال أثناء عمليات الحذف وإعادة التنظيم التي أشارت إليها تويوتا وأثناء الصيانة بشكل عام. ليس لدينا طريقة لمعرفة ما إذا كان هذا ما حدث بالفعل لتويوتا، لكنه احتمال نظري.
علاوة على ذلك هناك إمكانات تكرار ولقطات لإضافتها إلى متطلبات سعة التخزين. وفي الوقت نفسه، يمكن أن تؤدي زيادة استخدام القرص إلى أوقات وصول أطول ويمكن أن تزيد تكوينات RAID من نمو حجم التخزين.
هناك دلالة أخرى لتفسير تويوتا (المحدود) تشير إلى بعض الإخفاقات الأساسية المحتملة الأخرى. يتضمن ذلك أن الملفات المؤقتة ربما لم تكن موجودة على محركات أقراص منفصلة، وهو ما يعد من أفضل الممارسات الموصى بها، وأن النسخ الاحتياطية كانت على نفس محركات الأقراص مثل بيانات الإنتاج (غير مستحسن)، وحتى تخزين قاعدة بيانات نظام الإنتاج كان على وحدة تخزين خادم متصلة مباشرة. لا نعرف ما إذا كان هذا هو الحال الأخير – ربما كان على خادم مناسب تمامًا أو بنية تحتية شديدة التقارب، من الناحية النظرية – ولكن تخزين SAN المشترك عالي الأداء مناسب تمامًا لعمليات نشر قواعد البيانات المهمة.
بشكل عام، كان علينا أن نتكهن قليلاً هنا. لقد كان تواصل تويوتا صريحًا للغاية، ولكن هناك الكثير مما لا نعرفه. خلاصة القول هي أن الشركة فشلت بطريقة ما في التخطيط بشكل صحيح للنمو في حجم قاعدة البيانات لبعض الأنظمة المهمة، وهذا درس يمكن للكثير من المؤسسات أن تتعلمه.
