استكشاف أخطاء Azure SQL Database وأداء مثيل Azure SQL المُدار وإصلاحها باستخدام Intelligent Insights
ينطبق على:
قاعدة بيانات Azure SQL مثيل Azure SQL المُدار
توفر هذه الصفحة معلومات حول Azure SQL Database ،SQL ومشكلات أداء مثيل Azure SQL المُدار التي تم اكتشافها من خلال سجل مورد Intelligent Insights. يمكن دفق المقاييس وسجلات الموارد إلى سجلات Azure Monitor، أو مراكز الأحداث، أو Azure Storageأو حل جهة خارجية لإمكانيات التنبيه وإعداد التقارير المخصصة DevOps.
ملاحظة
للحصول على دليل سريع لتحرّي الخلل وإصلاحه في الأداء باستخدام Intelligent Insights، راجع المخطط الانسيابي الموصى به لتحرّي الخلل وإصلاحه في هذا المستند.
تعد Intelligent insights ميزة معاينة غير متوفرة في المناطق التالية: غرب أوروبا، وشمال أوروبا، وغرب الولايات المتحدة 1، وشرق الولايات المتحدة 1.
أنماط أداء قاعدة البيانات القابلة للكشف
يكتشف Intelligent Insights تلقائياً مشكلات الأداء بناءً على أوقات انتظار تنفيذ الاستعلام أو الأخطاء أو المهلات. كشفت مخرجات Intelligent Insights عن أنماط أداء لسجل الموارد. لُخصت أنماط الأداء القابلة للكشف في الجدول أدناه.
| أنماط الأداء القابلة للكشف | Azure SQL Database | مثيل Azure SQL المُدار |
|---|---|---|
| الوصول إلى حدود الموارد | بلغ استهلاك الموارد المتاحة (DTUs)، أو سلاسل عمليات تشغيل قاعدة البيانات، أو جلسات تسجيل الدخول إلى قاعدة البيانات المتاحة على الاشتراك الخاضع للمراقبة، حدود مواردها. هذا مؤثر على الأداء. | يصل استهلاك موارد وحدة المعالجة المركزية إلى حدود مواردها. هذا مؤثر على أداء قاعدة البيانات. |
| زيادة حمولة العمل | كُشفت زيادة حمولة العمل أو التراكم المستمر لحمولة العمل على قاعدة البيانات. هذا مؤثر على الأداء. | كُشفت زيادة حمولة العمل. هذا مؤثر على أداء قاعدة البيانات. |
| ضغط الذاكرة | يجب على العمال الذين طلبوا منح ذاكرة انتظار مخصصات الذاكرة لفترات زمنية ذات دلالة إحصائية، أو وجود تراكم متزايد للعاملين الذين طلبوا منح ذاكرة. هذا مؤثر على الأداء. | ينتظر العمال الذين طلبوا منح الذاكرة تخصيصات الذاكرة لفترة زمنية ذات دلالة إحصائية. هذا مؤثر على أداء قاعدة البيانات. |
| قفل | تم الكشف عن القفل المفرط لقاعدة البيانات الذي يؤثر على الأداء. | تم الكشف عن القفل المفرط لقاعدة البيانات الذي يؤثر على أداء قاعدة البيانات. |
| زيادة MAXDOP | تم تغيير خيار الدرجة القصوى للتوازي (MAXDOP) ما يؤثر على كفاءة تنفيذ الاستعلام. هذا مؤثر على الأداء. | تم تغيير خيار الدرجة القصوى للتوازي (MAXDOP) ما يؤثر على كفاءة تنفيذ الاستعلام. هذا مؤثر على الأداء. |
| تنازع Pagelatch | تحاول سلاسل رسائل متعددة بشكل متزامن الوصول إلى نفس صفحات المخزن المؤقت للبيانات الموجودة في الذاكرة، ما يؤدي إلى زيادة أوقات الانتظار والتسبب في اختلاف ترتيب الصفحات. هذا مؤثر على الأداء. | تحاول سلاسل رسائل متعددة بشكل متزامن الوصول إلى نفس صفحات المخزن المؤقت للبيانات الموجودة في الذاكرة، ما يؤدي إلى زيادة أوقات الانتظار والتسبب في اختلاف ترتيب الصفحات. هذا مؤثر على أداء قاعدة البيانات. |
| الفهرس مفقود | اكتشف فهرس مفقود مؤثر على الأداء. | اكتشف فهرس مفقود مؤثر على أداء قاعدة البيانات. |
| استعلام جديد | اكتشف استعلام جديد مؤثر على الأداء العام. | اكتشف استعلام جديد مؤثر على الأداء العام لقاعدة البيانات. |
| زيادة في إحصائية الانتظار | كُشفت زيادة أوقات انتظار قاعدة البيانات المؤثرة على الأداء. | كُشفت زيادة أوقات انتظار قاعدة البيانات المؤثرة على أداء قاعدة البيانات. |
| تنازع TempDB | تحاول مؤشرات ترابط متعددة الوصول إلى نفس مورد TempDB فتسبب حدوث اختناق. هذا مؤثر على الأداء. | تحاول مؤشرات ترابط متعددة الوصول إلى نفس مورد TempDB فتسبب حدوث اختناق. هذا مؤثر على أداء قاعدة البيانات. |
| نقص تجمع DTU مرن | يؤثر النقص في وحدات eDTU المتوفرة في المسبح المرن على الأداء. | غير متاح لـ Azure SQL Managed Instance لأنه يستخدم نموذج vCore. |
| تراجع الخطة | كُشفت خطة جديدة أو تغيير في حمولة العمل لخطة موجودة. هذا مؤثر على الأداء. | كُشفت خطة جديدة أو تغيير في حمولة العمل لخطة موجودة. هذا مؤثر على أداء قاعدة البيانات. |
| تغيير قيمة التكوين على نطاق قاعدة البيانات | كُشف تغيير التكوين في قاعدة البيانات المؤثرة على أداء قاعدة البيانات. | كُشف تغيير التكوين في قاعدة البيانات المؤثرة على أداء قاعدة البيانات. |
| عميل بطيء | عميل التطبيق البطيء غير قادر على استهلاك الإخراج من قاعدة البيانات بالسرعة الكافية. هذا مؤثر على الأداء. | عميل التطبيق البطيء غير قادر على استهلاك الإخراج من قاعدة البيانات بالسرعة الكافية. هذا مؤثر على أداء قاعدة البيانات. |
| تخفيض مستوى التسعير | خفضت إجراءات خفض مستوى التسعير من الموارد المتاحة. هذا مؤثر على الأداء. | خفضت إجراءات خفض مستوى التسعير من الموارد المتاحة. هذا مؤثر على أداء قاعدة البيانات. |
تلميح
لتحسين الأداء المستمر لقواعد البيانات، قم بتمكين الضبط التلقائي. تراقب ميزة الذكاء المدمجة قاعدة البيانات الخاصة بك باستمرار، وتضبط الفهارس تلقائياً، وتطبق تصحيحات خطة تنفيذ الاستعلام.
يصف القسم التالي أنماط الأداء القابلة للاكتشاف بمزيد من التفصيل.
الوصول إلى حدود الموارد
ماذا يحدث
يجمع نمط الأداء القابل للاكتشاف بين مشكلات الأداء المتعلقة بالوصول إلى حدود الموارد المتاحة، وحدود العمال، وحدود الجلسات. بعد اكتشاف مشكلة الأداء، يشير حقل وصف سجل التشخيص إلى كون مشكلة الأداء مرتبطة بحدود المورد أو العامل أو الجلسة.
يُشار عادةً إلى الموارد الموجودة في Azure SQL Database إلى موارد DTU، أو vCore، ويُشار إلى الموارد الموجودة في Azure SQL Managed Instance باسم موارد vCore. يُتعرف على نمط الوصول إلى حدود الموارد عندما يكون تدهور أداء الاستعلام المكتشف ناتجاً عن الوصول إلى أي من حدود الموارد المقاسة.
يشير مورد حدود الجلسة إلى عدد عمليات تسجيل الدخول المتزامنة المتاحة إلى قاعدة البيانات. يُتعرف على نمط الأداء عندما تصل التطبيقات المتصلة بقواعد البيانات إلى عدد عمليات تسجيل الدخول المتزامنة المتاحة إلى قاعدة البيانات. إذا حاولت التطبيقات استخدام جلسات عمل أكثر مما هو متاح في قاعدة بيانات؛ يتأثر أداء الاستعلام.
يعد الوصول إلى حدود العمال حالة محددة للوصول إلى حدود الموارد نظراً إلى عدم احتساب العمال المتاحين في استخدام DTU أو vCore. يمكن أن يؤدي الوصول إلى حدود العاملين في قاعدة البيانات إلى زيادة أوقات الانتظار الخاصة بالمورد، ما يؤدي إلى تدهور أداء الاستعلام.
استكشاف الأخطاء وإصلاحها
تجزئات استعلام مخرجات سجل التشخيص للاستعلامات التي أثرت على الأداء والنسب المئوية لاستهلاك الموارد. يمكنك استخدام هذه المعلومات كنقطة بداية لتحسين عبء عمل قاعدة البيانات. على وجه الخصوص، يمكنك تحسين الاستعلامات التي تؤثر على تدهور الأداء عن طريق إضافة الفهارس. أو يمكنك تحسين التطبيقات من خلال توزيع أحمال العمل بشكل متساوٍ. إن كنت غير قادر على تقليل حمولات العمل أو إجراء تحسينات، ففكر في زيادة مستوى تسعير اشتراك قاعدة البيانات لديك لزيادة مقدار الموارد المتاحة.
إذا وصلت إلى حدود الجلسات المتاحة، يمكنك تحسين تطبيقاتك عن طريق تقليل عدد عمليات تسجيل الدخول إلى قاعدة البيانات. إن كنت غير قادر على تقليل عدد عمليات تسجيل الدخول من تطبيقاتك إلى قاعدة البيانات، ففكر في زيادة مستوى تسعير اشتراك قاعدة البيانات. أو يمكنك تقسيم قاعدة البيانات ونقلها إلى قواعد بيانات متعددة لتوزيع حمولة العمل بشكل أكثر توازناً.
لمزيد من الاقتراحات حول حل حدود الجلسات، راجع كيفية التعامل مع حدود الحد الأقصى لعمليات تسجيل الدخول. راجع نظرة عامة على حدود الموارد على الخادم للحصول على معلومات حول الحدود على الخادم ومستويات الاشتراك.
زيادة حمولة العمل
ماذا يحدث
يحدد نمط الأداء المشكلات الناتجة عن زيادة حمولة العمل، أو يحدد تراكم حمولة العمل في شكله الأكثر خطورة.
يكتشف من خلال مجموعة من المقاييس المتعددة. يكتشف المقياس الأساسي المقاس زيادة في حمولة العمل مقارنة بخط الأساس لحمولة العمل السابق. يعتمد الشكل الآخر من الكشف على قياس زيادة كبيرة في مؤشرات ترابط العاملين النشطة التي تكون كبيرة بما يكفي للتأثير على أداء الاستعلام.
في شكله الأكثر خطورة، قد تتراكم حمولة العمل باستمرار بسبب عدم قدرة قاعدة البيانات على التعامل مع حمولة العمل. والنتيجة هي حجم حمولة العمل المتزايد باستمرار، وهو حالة تراكم حمولة العمل. بسبب هذا الشرط، يزداد الوقت الذي تنتظره حمولة العمل للتنفيذ. يمثل هذا الشرط أحد أكثر مشكلات أداء قاعدة البيانات خطورة. كُشفت هذه المشكلة من خلال مراقبة الزيادة في عدد سلاسل ترابط العاملين التي أُحبطت.
استكشاف الأخطاء وإصلاحها
يُخرج سجل التشخيص عدد الاستعلامات التي زاد تنفيذها، وزيادة تجزئة الاستعلام مع أكبر مساهمة في حمولة العمل. يمكنك استخدام هذه المعلومات كنقطة بداية لتحسين حمولة العمل. يعد الاستعلام المحدد على أنه أكبر مساهم في زيادة حمولة العمل؛ مفيداً بشكل خاص كنقطة البداية.
قد تفكر في توزيع أحمال العمل بشكل متساوٍ على قاعدة البيانات. ضع في اعتبارك تحسين الاستعلام المؤثر على الأداء عن طريق إضافة الفهارس. يمكنك أيضاً توزيع حمولة العمل الخاص بك بين قواعد بيانات متعددة. إن لم تكن هذه الحلول ممكنة، ففكر في زيادة مستوى التسعير لاشتراك قاعدة البيانات لديك حتى تزداد كمية الموارد المتاحة.
ضغط الذاكرة
ماذا يحدث
يشير نمط الأداء إلى تدهور أداء قاعدة البيانات الحالية بسبب ضغط الذاكرة، أو يشير إلى في حالة تراكم الذاكرة في شكله الأخطر، مقارنةً بخط الأساس للأيام السبعة الماضية.
يشير ضغط الذاكرة إلى حالة الأداء التي يوجد فيها عدد كبير من سلاسل العمليات التي تطلب منح الذاكرة. يتسبب الحجم الكبير في حالة استخدام ذاكرة عالية فلا تتمكن قاعدة البيانات من تخصيص الذاكرة بكفاءة لجميع العاملين الذين يطلبونها. يرتبط أحد الأسباب المتداولة لهذه المشكلة بحجم الذاكرة المتاحة لقاعدة البيانات من ناحية. ومن ناحية أخرى، تؤدي الزيادة في حمولة العمل إلى زيادة ترابط العامل وضغط الذاكرة.
الشكل الأشد لضغط الذاكرة هو حالة تراكم الذاكرة. يشير هذا الشرط إلى أن عدداً أكبر من سلاسل العمليات العاملة يطلب منح ذاكرة أكثر من وجود استعلامات تطلق الذاكرة. هذا العدد من سلاسل العمليات التي تطلب منح الذاكرة قد يتزايد باستمرار (يتراكم) لأن محرك قاعدة البيانات غير قادر على تخصيص الذاكرة بكفاءة كافية لتلبية الطلب. تمثل حالة تراكم الذاكرة أحد أكثر مشكلات أداء قاعدة البيانات خطورة.
استكشاف الأخطاء وإصلاحها
يقوم سجل التشخيص بإخراج تفاصيل مخزن كائن الذاكرة مع الموظف (أي: مؤشر ترابط العامل) الذي وضع علامة عليه كأعلى سبب لاستخدام الذاكرة العالية والطوابع الزمنية ذات الصلة. يمكنك استخدام هذه المعلومات كأساس لاستكشاف الأخطاء وإصلاحها.
يمكنك تحسين أو إزالة الاستعلامات المتعلقة بالموظفين أصحاب أعلى استخدام للذاكرة. يمكنك أيضاً التأكد من أنك لا تستعلم عن بيانات لا تخطط لاستخدامها. من الممارسات الجيدة دائماً استخدام عبارة WHERE في استفساراتك. بالإضافة إلى ذلك، نوصي بإنشاء فهارس غير مجمعة للبحث عن البيانات بدلاً من مسحها ضوئياً.
يمكنك أيضاً تقليل حمولة العمل عن طريق تحسينه أو توزيعه على قواعد بيانات متعددة. أو يمكنك توزيع حمولة العمل الخاص بك بين قواعد بيانات متعددة. إن لم تكن هذه الحلول ممكنة، ففكر في زيادة مستوى التسعير لقاعدة البيانات الخاصة بك حتى تزداد كمية موارد الذاكرة المتاحة لقاعدة البيانات.
للحصول على اقتراحات إضافية حول استكشاف الأخطاء وإصلاحها، راجع تمنح الذاكرة التأمل: المستهلك الغامض لذاكرة SQL Server مع العديد من الأسماء. لمزيد من المعلومات عن أخطاء نفاد الذاكرة في Azure SQL Database، راجع استكشاف أخطاء نفاد الذاكرة وإصلاحها باستخدام Azure SQL Database.
قفل
ماذا يحدث
يشير نمط الأداء إلى التدهور في أداء قاعدة البيانات الحالية عن طريق الكشف عن قفل قاعدة البيانات المفرط مقارنة بخط الأساس لأداء الأيام السبعة الماضية.
في RDBMS الحديثة، يعد القفل ضرورياً لتنفيذ الأنظمة متعددة مؤشرات الترابط التي يزاد فيها الأداء إلى أقصى، حد عن طريق تشغيل العديد من العاملين المتزامنين ومعاملات قاعدة البيانات المتوازية حيثما أمكن ذلك. يشير القفل في هذا السياق إلى آلية الوصول المضمنة، فيمكن لمعاملة واحدة فقط الوصول حصرياً إلى الصفوف والصفحات والجداول والملفات المطلوبة، ولا تتنافس مع معاملة أخرى للموارد. عند تمام المعاملة التي أغلقت الموارد للاستخدام معهم، يتم تحرير القفل على هذه الموارد، ما يسمح للمعاملات الأخرى بالوصول إلى الموارد المطلوبة. لمزيد من المعلومات حول التأمين، راجع تأمين محرك قاعدة البيانات.
إذا كانت المعاملات التي تُنفذ بواسطة مشغل SQL تنتظر فترات طويلة من الوقت للوصول إلى الموارد المؤمنة للاستخدام، فإن وقت الانتظار يتسبب في تباطؤ أداء تنفيذ حمل العمل.
استكشاف الأخطاء وإصلاحها
يقوم سجل التشخيص بإخراج التفاصيل التي يمكنك استخدامها كأساس لاستكشاف الأخطاء وإصلاحها. يمكنك تحليل استعلامات الحظر المبلغ عنها، أي: الاستعلامات التي تقدم تدهور أداء التأمين وإزالتها. في بعض الحالات، قد تنجح في تحسين استعلامات الحظر.
إن أيسر الطرق وأكثرها أماناً للتخفيف من المشكلة هو إبقاء المعاملات قصيرة وتقليل أثر القفل لأغلى الاستعلامات. يمكنك تقسيم مجموعة كبيرة من العمليات إلى عمليات أصغر. من الممارسات الجيدة تقليل أثر قفل الاستعلام بجعل الاستعلام فعالاً قدر الإمكان. تقليل عمليات الفحص الكبيرة؛ لأنها تزيد من فرص حدوث حالات توقف تام، وتؤثر سلباً على الأداء العام لقاعدة البيانات. بالنسبة للاستعلامات التي تحدد وتسبب الإقفال، يمكنك إنشاء فهارس جديدة أو إضافة أعمدة إلى الفهرس الحالي لتجنب عمليات فحص الجدول.
لمزيد من الاقتراحات، راجع:
زيادة MAXDOP
ماذا يحدث
يشير نمط الأداء القابل للاكتشاف إلى حالة توازت فيها خطة تنفيذ الاستعلام المختارة أكثر مما ينبغي. يمكن لمحسن الاستعلام تحسين أداء حمولة العمل من خلال تنفيذ الاستعلامات بالتوازي لتسريع الأمور حيثما أمكن ذلك. في بعض الحالات، يقضي العمال الموازون الذين يعالجون استعلاماً، وقتاً أطول في انتظار بعضهم البعض لمزامنة النتائج ودمجها، مقارنة بتنفيذ نفس الاستعلام مع عدد أقل من العمال المتوازيين، أو حتى في بعض الحالات مقارنة بترابط عامل واحد.
يحلل النظام الخبير أداء قاعدة البيانات الحالية مقارنة بفترة خط الأساس. يحدد ما إذا كان الاستعلام السابق تشغيله يعمل بشكل أبطأ من ذي قبل، لأن خطة تنفيذ الاستعلام أكثر توازناً مما ينبغي.
يستخدم خيار تكوين خادم MAXDOP للتحكم في عدد مراكز وحدة المعالجة المركزية التي يمكن استخدامها لتنفيذ نفس الاستعلام على التوازي.
استكشاف الأخطاء وإصلاحها
تجزئات استعلام مخرجات سجل التشخيص المتعلقة بطلبات البحث التي زادت مدة التنفيذ من أجلها لأنها كانت متوازية أكثر مما ينبغي. ينتج السجل أيضاً أوقات انتظار CXP. يمثل هذا الوقت الذي ينتظر فيه منظم / منسق واحد (مؤشر ترابط 0) انتهاء جميع سلاسل الرسائل الأخرى قبل دمج النتائج والمضي قدماً. بالإضافة إلى ذلك، يُخرج سجل التشخيص أوقات الانتظار التي كانت تنتظرها الاستعلامات ذات الأداء الضعيف في التنفيذ بشكل عام. يمكنك استخدام هذه المعلومات كأساس لاستكشاف الأخطاء وإصلاحها.
أولاً، حسِّن أو بسَّط الاستعلامات المعقدة. الممارسة الجيدة هي تقسيم وظائف الدُفعات الطويلة إلى وظائف أصغر. بالإضافة إلى ذلك، تأكد من إنشاء فهارس لدعم استعلاماتك. يمكنك أيضاً فرض أقصى درجة من التوازي (MAXDOP) يدوياً لاستعلام تم تمييزه على أنه أداء ضعيف. لتكوين هذه العملية باستخدام T-SQL، راجع تكوين خيار تكوين خادم MAXDOP.
يشير تعيين خيار تكوين خادم MAXDOP إلى صفر (0) بصفتها قيمة افتراضية إلى أن قاعدة البيانات يمكنها استخدام جميع مراكز وحدة المعالجة المركزية المتاحة لموازنة سلاسل العمليات لتنفيذ استعلام واحد. يشير تعيين MAXDOP إلى واحد (1) إلى أنه يمكن استخدام نواة واحدة فقط لتنفيذ استعلام واحد. من الناحية العملية، هذا يعني أن التوازي متوقف. اعتماداً على أساس كل حالة على حدة، والأنوية المتاحة لقاعدة البيانات، ومعلومات سجل التشخيص، يمكنك ضبط خيار MAXDOP على عدد النوى المستخدمة لتنفيذ الاستعلام المتوازي الذي قد يحل المشكلة في حالتك.
تنازع Pagelatch
ماذا يحدث
يشير نمط الأداء إلى انخفاض أداء حمل عمل قاعدة البيانات الحالي بسبب تغير ترتيب الصفحات مقارنة بخط الأساس لحمل العمل لمدة سبعة أيام مضت.
المزالج هي آليات مزامنة خفيفة الوزن تستخدم لتمكين تعدد مؤشرات الترابط. إنها تضمن اتساق الهياكل الموجودة في الذاكرة التي تتضمن الفهارس وصفحات البيانات والهياكل الداخلية الأخرى.
هناك العديد من أنواع المزالج المتاحة. لأغراض التسهيل، تُستخدم مزاليج المخزن المؤقت لحماية الصفحات الموجودة في الذاكرة في تجمع المخزن المؤقت. تُستخدم مزاليج الإدخال / الإخراج لحماية الصفحات التي لم تُحمَّل بعد في تجمع المخزن المؤقت. عندما تُكتب البيانات أو تُقرأ من صفحة في تجمع المخزن المؤقت، يحتاج مؤشر ترابط العامل إلى الحصول على مزلاج مخزن مؤقت للصفحة أولاً. عندما يحاول مؤشر ترابط عامل الوصول إلى صفحة غير متوفرة بالفعل في تجمع المخزن المؤقت في الذاكرة، يجرى طلب إدخال / إخراج لتحميل المعلومات المطلوبة من التخزين. يشير هذا التسلسل للأحداث إلى شكل أخطر من تدهور الأداء.
يحدث التنازع على مزلاج الصفحة عندما تحاول خيوط متعددة في نفس الوقت الحصول على مزلاج على نفس بنية الذاكرة، مما يؤدي إلى زيادة وقت الانتظار لتنفيذ الاستعلام. في حالة التنازع على IO pagelatch، عند الحاجة إلى الوصول إلى البيانات من وحدة التخزين، يكون وقت الانتظار أكبر. يمكن أن يؤثر على أداء حمولة العمل بشكل كبير. يعتبر تنازع Pagelatch هو السيناريو الأكثر تداولاً لسلاسل العمليات التي تنتظر بعضها البعض وتتنافس على الموارد على أنظمة وحدة المعالجة المركزية المتعددة.
استكشاف الأخطاء وإصلاحها
تفاصيل التنازع في مخرجات سجل التشخيصات. يمكنك استخدام هذه المعلومات كأساس لاستكشاف الأخطاء وإصلاحها.
نظراً لأن pagelatch هو آلية رقابة داخلية، فإنه يحدد تلقائياً متى تُستخدم. يمكن أن تؤثر قرارات التطبيق، بما في ذلك تصميم المخطط، على سلوك pagelatch بسبب السلوك الحتمي للمزالج.
تتمثل إحدى طرق معالجة تنازع المزلاج في استبدال مفتاح الفهرس المتسلسل بمفتاح غير متسلسل لتوزيع الإدخالات بالتساوي عبر نطاق فهرس. عادةً ما يوزع عمود البادئة في الفهرس حمولة العمل بشكل متناسب. هناك طريقة أخرى يجب مراعاتها وهي تقسيم الجدول. تعد طريقة إنشاء مخطط تقسيم تجزئة بعمود محسوب على جدول مقسم؛ طريقة شائعة للتخفيف من تنازع المزلاج المفرط. في حالة التنازع على IO pagelatch، يساعد تقديم الفهارس في التخفيف من هذه مشكلة في الأداء.
لمزيد من المعلومات، راجع تشخيص وحل مشكلة المزلاج على SQL Server (تنزيل ملف PDF).
الفهرس المفقود
ماذا يحدث
يشير هذا النمط من الأداء إلى انخفاض أداء عبء عمل قاعدة البيانات الحالي مقارنة بخط الأساس لمدة سبعة أيام ماضية بسبب عدم وجود فهرس.
يُستخدم فهرس لتسريع أداء الاستعلامات. يوفر وصولاً سريعاً إلى بيانات الجدول عن طريق تقليل عدد صفحات مجموعة البيانات التي يجب زيارتها أو مسحها ضوئياً.
تُحدد الاستعلامات المحددة التي تسببت في تدهور الأداء من خلال هذا الاكتشاف، ومن أجل ذلك يكون إنشاء الفهارس مفيداً للأداء.
استكشاف الأخطاء وإصلاحها
تجزئات استعلام مخرجات سجل التشخيص للاستعلامات التي حُددت للتأثير على أداء حمولة العمل. يمكنك إنشاء فهارس لهذه الاستعلامات. يمكنك أيضاً تحسين هذه الاستعلامات أو إزالتها إذا لم تكن مطلوبة. من الممارسات الجيدة للأداء تجنب الاستعلام عن البيانات غير المستخدمة.
تلميح
هل تعلم أن الذكاء المدمج يمكنه تلقائياً إدارة الفهارس الأفضل أداءً لقواعد البيانات الخاصة بك؟
لتحسين الأداء المستمر، نوصي بتمكين الضبط التلقائي. تراقب ميزة الذكاء المدمجة الفريدة قاعدة بياناتك باستمرار وتقوم تلقائياً بضبط وإنشاء فهارس لقواعد البيانات الخاصة بك.
استعلام جديد
ماذا يحدث
يشير هذه النمط من الأداء إلى اكتشاف استعلام جديد يؤدي أداءً ضعيفاً ويؤثر على أداء حمولة العمل مقارنة بخط الأساس للأداء لمدة سبعة أيام.
قد تكون كتابة استعلام جيد الأداء مهمة صعبة في بعض الأحيان. لمزيد من المعلومات حول كتابة الاستعلامات، راجع كتابة استعلامات SQL. لتحسين أداء الاستعلام الحالي، راجع ضبط الاستعلام.
استكشاف الأخطاء وإصلاحها
يقوم سجل التشخيص بإخراج معلومات تصل إلى استعلامين جديدين يستهلكان وحدة المعالجة المركزية (CPU)، بما في ذلك تجزئات الاستعلام الخاصة بهما. نظراً إلى تأثير الاستعلام المكتشف على أداء حمل العمل، يمكنك تحسين الاستعلام الخاص بك. الممارسة الجيدة هي استرداد البيانات التي تحتاج إلى استخدامها فقط. نوصي أيضاً باستخدام الاستعلامات مع عبارة WHERE. نوصي أيضاً بتسهيل الاستعلامات المعقدة وتقسيمها إلى استعلامات أصغر. من الممارسات الجيدة الأخرى تقسيم استعلامات الدُفعات الكبيرة إلى استعلامات مجمعة أصغر. يعد تقديم الفهارس للاستعلامات الجديدة ممارسة جيدة للتخفيف من هذه مشكلة في الأداء.
في Azure SQL Database، ضع في اعتبارك استخدام Query Performance Insight.
زيادة في إحصائية الانتظار
ماذا يحدث
يشير هذا النمط من الأداء القابل للاكتشاف إلى انخفاض أداء حمولة العمل حيث تُحدد الاستعلامات ذات الأداء الضعيف مقارنة بخط الأساس لحمل العمل لمدة سبعة أيام ماضية.
في هذه الحالة، لا يمكن للنظام تصنيف الاستعلامات ذات الأداء الضعيف ضمن أي فئات أداء قياسية أخرى يمكن اكتشافها، ولكنه يكتشف إحصائية الانتظار المسؤولة عن الانحدار. لذلك، تعتبرها استعلامات ذات إحصائيات انتظار متزايدة، حيث يتم أيضاً عرض إحصائية الانتظار المسؤولة عن الانحدار.
استكشاف الأخطاء وإصلاحها
يُخرج سجل التشخيص معلومات حول تفاصيل وقت الانتظار المتزايدة وتجزئة الاستعلام للاستعلامات المتأثرة.
نظراً إلى عدم تمكن النظام من تحديد السبب الجذري للاستعلامات ذات الأداء الضعيف بنجاح، فإن معلومات التشخيص هي نقطة انطلاق جيدة لاستكشاف الأخطاء وإصلاحها يدوياً. يمكنك تحسين أداء هذه الاستعلامات. من الممارسات الجيدة جلب البيانات التي تحتاج إلى استخدامها فقط وتسهيل الاستعلامات المعقدة وتقسيمها إلى استعلامات أصغر.
لمزيد من المعلومات حول تحسين أداء الاستعلام، راجع ضبط الاستعلام.
تنازع TempDB
ماذا يحدث
يشير هذا النمط من الأداء القابل للاكتشاف إلى حالة أداء قاعدة البيانات حيث يوجد عنق الزجاجة في مؤشرات الترابط التي تحاول الوصول إلى موارد tempDB. (هذا الشرط ليس مرتبطاً بإدخال البيانات.) السيناريو النموذجي لمشكلة الأداء هذه هو مئات الاستعلامات المتزامنة التي تقوم جميعها بإنشاء جداول tempDB الصغيرة واستخدامها ثم إسقاطها. اكتشف النظام أن عدد الاستعلامات المتزامنة التي تستخدم نفس جداول tempDB قد ازداد مع دلالة إحصائية كافية للتأثير على أداء قاعدة البيانات مقارنة بخط الأساس لأداء الأيام السبعة الماضية.
استكشاف الأخطاء وإصلاحها
يقوم سجل التشخيص بإخراج تفاصيل التنازع tempDB. يمكنك استخدام المعلومات كنقطة بداية لاستكشاف الأخطاء وإصلاحها. هناك شيئان يمكنك متابعتهما للتخفيف من هذا النوع من الخلاف وزيادة معدل نقل حمولة العمل الإجمالي: يمكنك التوقف عن استخدام الجداول المؤقتة. يمكنك أيضاً استخدام الجداول المحسّنة للذاكرة.
لمزيد من المعلومات، راجع مقدمة حول الجداول المخصصة للذاكرة.
نقص تجمع DTU مرن
ماذا يحدث
يشير هذا النمط من الأداء القابل للاكتشاف إلى تدهور أداء عبء عمل قاعدة البيانات الحالية مقارنة بخط الأساس في الأيام السبعة الماضية. يرجع ذلك إلى النقص في DTUs المتاحة في المجموعة المرنة لاشتراكك.
تُستخدمموارد التجمع المرن Azure بصفتها مجموعة من الموارد المتاحة المشتركة بين قواعد بيانات متعددة لأغراض القياس. عندما لا تكون موارد eDTU المتاحة في مجموعتك المرنة كبيرة بما يكفي لدعم جميع قواعد البيانات الموجودة في التجمع، تُكتشف مشكلة أداء نقص DTU للمجمع المرن بواسطة النظام.
استكشاف الأخطاء وإصلاحها
يقوم سجل التشخيص بإخراج معلومات حول التجمع المرن، ويسرد أفضل قواعد البيانات المستهلكة لـ DTU، ويوفر نسبة مئوية من DTU الخاص بالمجمع المستخدم بواسطة قاعدة البيانات الأكثر استهلاكاً.
نظراً إلى ارتباط هذه الحالة من الأداء بقواعد بيانات متعددة تستخدم نفس مجموعة وحدات eDTU في التجمع المرن، فإن خطوات استكشاف الأخطاء وإصلاحها تركز على أفضل قواعد البيانات التي تستهلك DTU. يمكنك تقليل حمولة العمل على قواعد البيانات الأكثر استهلاكاً، والتي تتضمن تحسين الاستعلامات الأكثر استهلاكاً في قواعد البيانات هذه. يمكنك أيضاً التأكد من أنك لا تستعلم عن بيانات لا تستخدمها. هناك طريقة أخرى تتمثل في تحسين التطبيقات باستخدام أفضل قواعد البيانات التي تستهلك DTU، وإعادة توزيع حمولة العمل بين قواعد بيانات متعددة.
إذا لم يكن من الممكن تقليل حمولة العمل الحالي وتحسينه على أفضل قواعد البيانات التي تستهلك DTU، ففكر في زيادة فئة تسعير المجمع المرن. تؤدي هذه الزيادة إلى زيادة DTUs المتاحة في المسبح المرن.
تراجع الخطة
ماذا يحدث
يشير هذا النمط من الأداء القابل للاكتشاف إلى حالة تستخدم فيها قاعدة البيانات خطة تنفيذ استعلام دون المستوى الأمثل. تؤدي الخطة الأقل مثالية عادةً إلى زيادة تنفيذ الاستعلام، ما يؤدي إلى فترات انتظار أطول للاستعلامات الحالية والاستعلامات الأخرى.
يحدد محرك قاعدة البيانات خطة تنفيذ الاستعلام بأقل تكلفة لتنفيذ الاستعلام. نظراً إلى تغير نوع الاستعلامات وحمولات العمل، لم تعد الخطط الموجودة في بعض الأحيان فعالة، أو ربما لم يقم محرك قاعدة البيانات بإجراء تقييم جيد. على سبيل التصحيح، يمكن فرض خطط تنفيذ الاستعلام يدوياً.
يجمع هذا النمط من الأداء القابل للاكتشاف بين ثلاث حالات مختلفة لانحدار الخطة: انحدار الخطة الجديدة، وانحدار الخطة القديمة، والخطط الحالية المغيرة لحمولة العمل. يتم توفير النوع المعين لانحدار الخطة الحادث في خاصية التفاصيل في سجل التشخيص.
يشير شرط انحدار الخطة الجديد إلى الحالة التي يبدأ فيها محرك قاعدة البيانات في تنفيذ خطة تنفيذ استعلام جديدة ليست فعالة مثل الخطة القديمة. تشير حالة انحدار الخطة القديمة إلى الحالة التي يتحول فيها محرك قاعدة البيانات من استخدام خطة جديدة أكثر كفاءة إلى الخطة القديمة الأقل كفاءة من الخطة الجديدة. تشير الخطط الحالية المتغيرة إلى انحدار حمولة العمل إلى الحالة التي تتناوب فيها الخطتان القديمة والجديدة باستمرار، حيث يتجه الميزان أكثر نحو الخطة ذات الأداء الضعيف.
لمزيد من المعلومات حول انحدار الخطة، راجع ما هو انحدار الخطة في SQL Server؟.
استكشاف الأخطاء وإصلاحها
يقوم سجل التشخيص بإخراج تجزئات الاستعلام، ومعرف الخطة الجيدة، ومعرف الخطة السيئة، ومعرفات الاستعلام. يمكنك استخدام هذه المعلومات كأساس لاستكشاف الأخطاء وإصلاحها.
يمكنك تحليل الخطة الأفضل أداءً لطلبات البحث المحددة التي يمكنك تحديدها باستخدام تجزئات الاستعلام المتوفرة. بعد تحديد الخطة الأفضل لاستعلاماتك، يمكنك فرضها يدوياً.
لمزيد من المعلومات، راجع تعرف على كيفية منع SQL Server لانحدار الخطة.
تلميح
هل تعلم أن ميزة الذكاء المضمنة يمكنها تلقائياً إدارة أفضل خطط تنفيذ الاستعلام أداءً لقواعد البيانات الخاصة بك؟
لتحسين الأداء المستمر، نوصي بتمكين الضبط التلقائي. تراقب هذه الميزة للذكاء المضمنة قاعدة بياناتك باستمرار، وتقوم تلقائياً بضبط وإنشاء خطط تنفيذ استعلام أفضل أداءً لقواعد البيانات الخاصة بك.
تغيير قيمة التكوين على نطاق قاعدة البيانات
ماذا يحدث
يشير هذا النمط من الأداء القابل للاكتشاف إلى حالة يتسبب فيها تغيير في تكوين نطاق قاعدة البيانات في حدوث تراجع في الأداء يُكتشف بمقارنة سلوك حمل عمل قاعدة البيانات في الأيام السبعة الماضية. يشير هذا النمط إلى أن التغيير الأخير الذي تم إجراؤه على تكوين نطاق قاعدة البيانات لا يبدو مفيداً لأداء قاعدة البيانات الخاصة بك.
يمكن تعيين تغييرات التكوين على نطاق قاعدة البيانات لكل قاعدة بيانات فردية. يُستخدم هذا التكوين على أساس كل حالة على حدة لتحسين الأداء الفردي لقاعدة البيانات الخاصة بك. يمكن تكوين الخيارات التالية لكل قاعدة بيانات فردية: MAXDOP وLEGACY_CARDINALITY_ESTIMATION وPARAMETER_SNIFFING وQUERY_OPTIMIZER_HOTFIXES وCLEAR PROCEDURE_CACHE.
استكشاف الأخطاء وإصلاحها
يقوم سجل التشخيص بإخراج تغييرات التكوين في نطاق قاعدة البيانات التي أجريت مؤخراً والمتسببة في تدهور الأداء مقارنة بسلوك حمل العمل السابق لمدة سبعة أيام. يمكنك إعادة تغييرات التكوين إلى القيم السابقة. يمكنك أيضاً ضبط القيمة حسب القيمة حتى الوصول إلى مستوى الأداء المطلوب. يمكنك نسخ قيم تكوين نطاق قاعدة البيانات من قاعدة بيانات مماثلة بأداء مُرضٍ. إذا لم تتمكن من استكشاف أخطاء الأداء وإصلاحها، فارجع إلى القيم الافتراضية وحاول إجراء ضبط دقيق بدءاً من هذا الخط الأساسي.
لمزيد من المعلومات حول تحسين تكوين نطاق قاعدة البيانات وبناء جملة T-SQL عند تغيير التكوين، راجع تعديل تكوين نطاق قاعدة البيانات (Transact-SQL).
عميل بطيء
ماذا يحدث
يشير هذا النمط من الأداء القابل للاكتشاف إلى حالة لا يستطيع فيها العميل المستخدم لقاعدة البيانات استهلاك الإخراج من قاعدة البيانات بالسرعة التي ترسل بها قاعدة البيانات النتائج. نظراً إلى عدم قدرة قاعدة البيانات على تخزين نتائج الاستعلامات المنفذة في مخزن مؤقت، فإنها تبطئ وتنتظر العميل لاستهلاك مخرجات الاستعلام المرسلة قبل المتابعة. قد يرتبط هذا الشرط أيضاً بشبكة ليست بالسرعة الكافية لنقل المخرجات من قاعدة البيانات إلى العميل المستهلك.
يُنشأ هذا الشرط فقط إذا تم اكتشاف انحدار في الأداء مقارنة بسلوك حمل عمل قاعدة البيانات في السبعة أيام الماضية. تُكتشف هذه المشكلة في الأداء فقط في حالة حدوث انخفاض مهم إحصائياً في الأداء مقارنة بسلوك الأداء السابق.
استكشاف الأخطاء وإصلاحها
يشير هذا النمط من الأداء القابل للاكتشاف إلى حالة من جانب العميل. استكشاف الأخطاء وإصلاحها مطلوب في التطبيق من جانب العميل، أو الشبكة من جانب العميل. يقوم سجل التشخيص بإخراج تجزئات الاستعلام وأوقات الانتظار الأكثر التي يبدو أنها تنتظر العميل حتى يستهلكها خلال الساعتين الماضيتين. يمكنك استخدام هذه المعلومات كأساس لاستكشاف الأخطاء وإصلاحها.
يمكنك تحسين أداء التطبيق الخاص بك لاستهلاك هذه الاستعلامات. يمكنك أيضاً التفكير في مشكلات زمن انتقال الشبكة المحتملة. نظراً إلى استناد مشكلة تدهور الأداء إلى التغيير في آخر سبعة أيام من الأداء الأساسي، يمكنك التحقق مما إذا كانت التغييرات الأخيرة في حالة التطبيق أو الشبكة تسببت في حدوث هذا التراجع للأداء.
تخفيض مستوى التسعير
ماذا يحدث
يشير هذا النمط من الأداء القابل للاكتشاف إلى حالة أُرجع فيها مستوى تسعير اشتراك قاعدة البيانات إلى إصدار سابق. بسبب تقليل الموارد (DTUs) المتاحة لقاعدة البيانات، اكتشف النظام انخفاضاً في أداء قاعدة البيانات الحالية مقارنة بخط الأساس في الأيام السبعة الماضية.
بالإضافة إلى ذلك، قد تكون هناك حالة خُفِّض فيها مستوى تسعير اشتراك قاعدة البيانات ثم ترقيتها إلى مستوى أعلى خلال فترة زمنية قصيرة. يُخرَّج الكشف عن هذا التدهور المؤقت في الأداء في قسم التفاصيل في سجل التشخيص، مثل: تخفيض مستوى التسعير وترقيته.
استكشاف الأخطاء وإصلاحها
إذا قمت بتخفيض مستوى التسعير الخاص بك، وبالتالي تتوفر DTUs، وكنت راضياً عن الأداء، فلا يوجد ما تحتاج إلى القيام به. إذا قمت بتخفيض مستوى التسعير الخاص بك ولم تكن راضياً عن أداء قاعدة البيانات، فقلل أعباء عمل قاعدة البيانات أو ضع في اعتبارك زيادة مستوى التسعير إلى مستوى أعلى.
يوصى بتدفق استكشاف الأخطاء وإصلاحها
اتبع المخطط الانسيابي للحصول على نهج موصًى به لاستكشاف مشكلات الأداء وإصلاحها باستخدام Intelligent Insights.
يمكنك الوصول إلى Intelligent insights من خلال مدخل Microsoft Azure بالانتقال إلى Azure SQL Analytics. حاول تحديد موقع تنبيه الأداء الوارد وتحديده. حدد ما يحدث في صفحة الاكتشافات. راقب تحليل السبب الجذري المقدم للمشكلة ونص الاستعلام واتجاهات وقت الاستعلام وتطور الحادث. حاول حل المشكلة باستخدام توصية Intelligent Insights للتخفيف من مشكلة الأداء.
تلميح
حدد المخطط الانسيابي لتنزيل نسخة PDF.
عادةً ما تحتاج Intelligent insights إلى ساعة واحدة لإجراء تحليل السبب الجذري لمشكلة الأداء. إذا لم تتمكن من تحديد موقع مشكلتك في Intelligent Insights وكان ذلك أمراً بالغ الأهمية بالنسبة لك، فاستخدم Query Store لتحديد السبب الجذري لمشكلة الأداء يدوياً. (عادةً ما تكون هذه المشكلات قبل أقل من ساعة واحدة.) لمزيد من المعلومات، راجع مراقبة الأداء باستخدام Query Store.
الخطوات التالية
- تعرف على مفاهيم Intelligent insights.
- استخدم سجل تشخيص أداء Intelligent Insights.
- راقب باستخدام Azure SQL Analytics.
- تعرف على كيفية جمع بيانات السجل واستهلاكها من موارد Azure.