أود من خلال هذا المنشور القصير تبديد سوء فهم يتعلق بتحليل قواعد بيانات AWR التي تعمل على Oracle Exadata. منذ ما يقرب من 10 سنوات، كنت أواجه السؤال باستمرار: ما مساهمة برنامج Exadata في الإنتاجية؟ أو باستخدام كلمات تمت صياغتها حديثًا: ما مدى فعالية "الخبير" في عمل قاعدة بيانات معينة؟
في كثير من الأحيان، في رأيي، تتم الإجابة على هذا السؤال الصحيح بشكل غير صحيح بالرجوع إلى إحصائيات AWR. وهو يقدم طريقة انتظار النظام، التي تتعامل مع وقت الاستجابة كمجموع وقت تشغيل المعالجات (وحدات المعالجة المركزية DB) ووقت الانتظار للفئات المختلفة.
مع ظهور Exadata، ظهرت توقعات النظام المحددة المتعلقة بتشغيل برنامج Exadata في إحصائيات AWR. كقاعدة عامة، تبدأ أسماء حالات الانتظار هذه بكلمة "خلية" (يُطلق على خادم تخزين Exadata اسم خلية)، وأكثرها شيوعًا هي فترات الانتظار ذات الأسماء التي لا تحتاج إلى شرح "فحص الجدول الذكي للخلية"، و"خلية متعددة الكتل" القراءة الفعلية" و"القراءة الفعلية للخلية المفردة".
في معظم الحالات، تكون حصة انتظار Exadata هذه في إجمالي وقت الاستجابة صغيرة، وبالتالي لا تندرج حتى في قسم Top10 Foreground Events حسب إجمالي وقت الانتظار (في هذه الحالة، تحتاج إلى البحث عنها في قسم انتظار المقدمة قسم الفعاليات). وبصعوبة كبيرة، وجدنا مثالاً على AWR اليومي من عملائنا، حيث تم إدراج توقعات Exadata في قسم Top10 وبلغ إجماليها حوالي 5٪:
الحدث/الفعالية
ينتظر
إجمالي وقت الانتظار (ثانية)
متوسط الانتظار
%DB الوقت
انتظر الصف
وحدة المعالجة المركزية قاعدة البيانات
115.2K
70.4
SQL*صافي المزيد من البيانات من dblink
670,196
5471.5
8.16ms
3.3
شبكة
قراءة مادية لخلية واحدة
5,661,452
3827.6
676.07us
2.3
الإدخال/الإخراج للمستخدم
مزامنة إعادة توازن ASM
4,350,012
3481.3
800.30us
2.1
أخرى
القراءة الفعلية للخلية متعددة الكتل
759,885
2252
2.96ms
1.4
الإدخال/الإخراج للمستخدم
قراءة المسار المباشر
374,368
1811.3
4.84ms
1.1
الإدخال/الإخراج للمستخدم
رسالة SQL * Net من dblink
7,983
1725
216.08ms
1.1
شبكة
مسح الجدول الذكي للخلية
1,007,520
1260.7
1.25ms
0.8
الإدخال/الإخراج للمستخدم
المسار المباشر قراءة درجة الحرارة
520,211
808.4
1.55ms
0.5
الإدخال/الإخراج للمستخدم
ar: TM - الخلاف
652
795.8
1220.55ms
0.5
تطبيق
غالبًا ما يتم استخلاص الاستنتاجات التالية من إحصائيات AWR:
1. إن مساهمة سحر Exadata في أداء قاعدة البيانات ليست عالية - فهي لا تتجاوز 5٪، وقاعدة البيانات "تتوسع" بشكل سيء.
2. إذا تم نقل قاعدة البيانات هذه من Exadata إلى بنية "الخادم + المصفوفة" الكلاسيكية، فلن يتغير الأداء كثيرًا. لأنه حتى لو تبين أن هذه المصفوفة أبطأ بثلاث مرات من نظام تخزين Exadata (وهو أمر نادرًا ما يكون ممكنًا بالنسبة لجميع مصفوفات Flash الحديثة)، فعند ضرب 5% في ثلاثة نحصل على زيادة في حصة انتظار الإدخال/الإخراج إلى 15% - قاعدة البيانات سوف تنجو بالتأكيد من هذا!
كلا هذين الاستنتاجين غير دقيقين، علاوة على ذلك، فإنهما يشوهان فهم الفكرة وراء برنامج Exadata. لا توفر Exadata عمليات إدخال/إخراج سريعة فحسب، بل إنها تعمل بشكل مختلف جذريًا مقارنة بالخادم الكلاسيكي + بنية المصفوفة. إذا كانت عملية قاعدة البيانات "مكيفة" حقًا، فسيتم نقل منطق SQL إلى نظام التخزين. تقوم خوادم التخزين، بفضل عدد من الآليات الخاصة (في المقام الأول فهارس تخزين Exadata، ولكن ليس فقط)، بالعثور على البيانات الضرورية بنفسها وإرسال قاعدة البيانات إلى الخوادم. إنهم يقومون بذلك بكفاءة تامة، لذا فإن حصة Exadata النموذجية المنتظرة في إجمالي وقت الاستجابة تكون صغيرة.
كيف ستتغير هذه المشاركة خارج Exadata؟ كيف سيؤثر ذلك على أداء قاعدة البيانات ككل؟ الاختبار سوف يجيب بشكل أفضل على هذه الأسئلة. على سبيل المثال، يمكن أن يتحول انتظار "فحص الجدول الذكي للخلية" خارج Exadata إلى فحص كامل للجدول ثقيل بحيث يستغرق الإدخال/الإخراج وقت الاستجابة بالكامل ويتدهور الأداء بشكل كبير. ولهذا السبب، من الخطأ، عند تحليل AWR، اعتبار النسبة الإجمالية لتوقعات Exadata بمثابة مساهمة سحرها في الأداء، بل والأكثر من ذلك استخدام هذه النسبة للتنبؤ بالأداء خارج Exadata. لفهم مدى دقة عمل قاعدة البيانات، تحتاج إلى دراسة إحصائيات AWR في قسم "إحصائيات نشاط المثيل" (هناك الكثير من الإحصائيات بأسماء لا تحتاج إلى شرح) ومقارنتها مع بعضها البعض.
ولفهم كيف ستشعر قاعدة البيانات خارج Exadata، من الأفضل إجراء استنساخ لقاعدة البيانات من نسخة احتياطية على البنية المستهدفة وتحليل أداء هذا الاستنساخ تحت التحميل. أصحاب Exadata، كقاعدة عامة، لديهم هذه الفرصة.
المؤلف: أليكسي ستروشينكو، رئيس قسم قاعدة بيانات Jet Infosystems
المصدر: www.habr.com