السابق

التالي

القيام بمراقبة الأداء واستكشاف الأخطاء وإصلاحها

مكتمل

وتكون المراقبة واستكشاف الأخطاء وإصلاحها عنصرين أساسيين للعمل على تقديم أداء ثابت. ويكون لدى Azure SQL نفس الأدوات والميزات كما في SQL Server وذلك لمراقبة الأداء واستكشاف الأخطاء وإصلاحه، بالإضافة إلى إمكانيات إضافية. وهذا يشتمل على ميزات مثل طرق عرض الإدارة الديناميكية (DMVs) والأحداث الممتدة وAzure Monitor. ومن المهم أيضًا معرفة كيف يتم استخدام هذه الأدوات والإمكانيات من خلال سيناريوهات أداء متعددة لـ Azure SQL. تتضمن هذه السيناريوهات استخداما عاليا لوحدة المعالجة المركزية أو انتظار مورد.

الأدوات والإمكانيات لمراقبة الأداء

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

Azure Monitor

تعتبر Azure Monitor جزءًا من النظام الحيوي لـ Azure، ويتم دمج Azure SQL لدعم مقاييس وتنبيهات وسجلاتها Azure. يمكنك تصور بيانات Azure Monitor في مدخل Microsoft Azure، ويمكن للتطبيقات الوصول إلى هذه البيانات من خلال مراكز الأحداث أو واجهات برمجة التطبيقات. مثل مراقبة أداء Windows، يساعدك Azure Monitor على الوصول إلى مقاييس استخدام الموارد ل Azure SQL دون استخدام أدوات SQL Server.

طرق عرض الإدارة الديناميكية

يوفر Azure SQL نفس البنية الأساسية ل DMV تقريبا مثل SQL Server، مع بعض الاختلافات. وتعتبر طرق DMV هامة لمراقبة الأداء، لأنه يمكنك عرض بيانات أداء SQL Server الأساسية عن طريق استخدام استعلامات T-SQL القياسية. فعلى سبيل المثال، يمكنك أن تعرض معلومات مثل الاستعلامات النشطة واستخدام الموارد وخطط الاستعلام وأنواع انتظار الموارد. ستتعرف على مزيد من التفاصيل حول DMVs باستخدام Azure SQL لاحقا في هذه الوحدة.

الأحداث الممتدة

يوفر Azure SQL نفس البنية الأساسية للأحداث الممتدة تقريبا مثل SQL Server، مع بعض الاختلافات. تقوم الأحداث الممتدة بمنحك إمكانية تعقب الأحداث الرئيسية للتنفيذ داخل SQL Server الذي يدعم Azure SQL. وبالنسبة إلى الأداء، تسمح لك الأحداث الممتدة بتتبع تنفيذ الاستعلامات الفردية. ستتعرف على مزيد من التفاصيل حول الأحداث الموسعة باستخدام Azure SQL لاحقا في هذه الوحدة.

جمع معلومات استعلامات خفيفة

يعد جمع المعلومات الخفيف طريقة متقدمة لاستكشاف السيناريوهات التي تتطلب استرداد خطة التنفيذ الفعلية لطلبات الطيران والاستعلامات عالية القيمة وإصلاحها. نظرا لانخفاض الحمل، يمكن لأي خادم ليس مرتبطا بالفعل بوحدة المعالجة المركزية تشغيل جمع معلومات خفيف الوزن بشكل مستمر، والسماح لمتخصصي قاعدة البيانات بالاستفادة من أي تنفيذ قيد التشغيل في أي وقت؛ على سبيل المثال، استخدام مراقب النشاط في SQL Server Management Studio (SSMS) أو الاستعلام sys.dm_exec_query_profiles مباشرة أو sys.dm_exec_query_statistics_xml.

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

إمكانيات تصحيح أخطاء خطط الاستعلام

وفي بعض المواقف، قد تكون بحاجة إلى تفاصيل إضافية عن أداء الاستعلام لكشوف T-SQL الفردية. ويمكن لكشوف T-SQL SET مثل SHOWPLAN وSTATISTICS أن تقوم بتوفير هذه التفاصيل وتكون مدعومة بالكامل لـ Azure SQL كما هو الحال بالنسبة إلى SQL Server.

Query Store

ويعد مخزن الاستعلام سجلاً تاريخيًا لتنفيذ الأداء للاستعلامات المُخزنة في قاعدة بيانات المستخدم. ويكون مخزن الاستعلام قيد التشغيل افتراضيًا لـ Azure SQL، ويتم استخدامه لتوفير إمكانيات مثل التصحيح التلقائي للخطة والضبط التلقائي. وتكون تقارير SQL Server Management Studio بالنسبة إلى المخزن متاحة لـ Azure SQL. قم باستخدام هذه التقارير للبحث عن الاستعلامات الخاصة باستهلاك الموارد العالية الأهمية، بما في ذلك اختلافات خطة الاستعلامات وأنواع الانتظار العليا للنظر في سيناريوهات انتظار الموارد.

التصورات الخاصة بالأداء

وبالنسبة إلى قاعدة بيانات Azure SQL، فإنه يمكنك مشاهدة معلومات أداء مخزن الاستعلام المتكامل في مدخل Microsoft Azure عن طريق التصورات. بهذه الطريقة، يمكنك مشاهدة بعض المعلومات نفسها لمتجر الاستعلام كما تفعل مع أداة عميل مثل SSMS. استخدم خيارات نظرة عامة على الأداء وApplication Performance Insight في مدخل Microsoft Azure.

التفاصيل الخاصة بـ DMV

كانت طرق DMV قوة دافعة للقيام بمراقبة الأداء واستكشاف أخطاء وتصحيحها لسنوات عديدة مع SQL Server. وتعد طرق DMV المشتركة متوفرة مع Azure SQL لـ SQL Server، وتعد إضافات خاصة بـ Azure.

مثيل Azure SQL المُدار

وتكون جميع طرق DMV لـ SQL Server متوفرة لمثيل SQL المدارُ. تستخدم طرق عرض الإدارة الديناميكية الرئيسية مثل sys.dm_exec_requests و sys.dm_os_wait_stats بشكل شائع لفحص أداء الاستعلام.

sys.server_resource_stats طريقة عرض النظام خاصة بمثيل Azure SQL المدار، وتظهر استخدام الموارد التاريخية. هذه أداة قيمة لمشاهدة استخدام الموارد، لأنه ليس لديك وصول مباشر إلى أدوات نظام التشغيل مثل مراقبة الأداء.

قاعدة بيانات Azure SQL

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

sys.dm_db_resource_stats DMV خاص بقاعدة بيانات Azure SQL، ويمكنك استخدامه لعرض محفوظات استخدام الموارد لقاعدة البيانات. استخدم DMV هذا مشابها لكيفية استخدامك sys.server_resource_stats لمثيل مدار.

sys.elastic_pool_resource_stats يشبه DMV sys.dm_db_resource_stats، ولكن يمكنك استخدامه لعرض استخدام الموارد لقواعد بيانات التجمع المرن.

طرق DMV التي تحتاجها

سوف تحتاج إلى طرق DMV التالية للقيام بحل بعض سيناريوهات الأداء لـ Azure SQL:

• sys.dm_io_virtual_file_stats مهم لأنه ليس لديك وصول مباشر إلى مقاييس نظام التشغيل لأداء الإدخال/الإخراج لكل ملف.
• يتوفر sys.dm_os_performance_counters لكل من قاعدة بيانات Azure SQL ومثيل SQL المدار للاطلاع على مقاييس الأداء الشائعة ل SQL Server. استخدم DMV هذا لعرض معلومات عداد أداء SQL Server المتوفرة عادة في مراقبة الأداء.
• sys.dm_instance_resource_governance تمكنك من عرض حدود الموارد لمثيل مدار. يمكنك القيام بعرض هذه المعلومات لمعرفة ما ينبغي أن تكون حدود الموارد المتوقعة الخاصة بك بدون استخدام مدخل Microsoft Azure.
• يمكنك sys.dm_user_db_resource_governance من رؤية حدود الموارد الشائعة لكل خيار نشر ومستوى الخدمة وحجم نشر قاعدة بيانات Azure SQL. يمكنك القيام بعرض هذه المعلومات لمعرفة ما ينبغي أن تكون حدود الموارد المتوقعة الخاصة بك بدون استخدام مدخل Microsoft Azure.

DMV من أجل رؤى أعمق

تقوم طرق DMV هذه بتوفير رؤية أعمق في حدود المورد وإدارتها لـ Azure SQL. لا يُقصد بها أن يتم استخدامها للسيناريوهات المشتركة، ولكن قد تكون مفيدة عند النظر عميقًا في مشاكل الأداء المعقدة. قم بمراجعة الوثائق لجميع التفاصيل الخاصة بطرق DMV:

• sys.dm_user_db_resource_governance_internal (مثيل SQL المدار فقط)
• sys.dm_resource_governor_resource_pools_history_ex
• sys.dm_resource_governor_workload_groups_history_ex

التفاصيل الخاصة بالأحداث الممتدة

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

الأحداث الممتدة لقاعدة بيانات Azure SQL

يمكنك استخدام الأحداث الموسعة لقاعدة بيانات Azure SQL، تماما مثل SQL Server، عن طريق إنشاء جلسات العمل واستخدام الأحداث والإجراءات والأهداف. قم بوضع هذه النقاط الهامة في الاعتبار عند إنشاء جلسات الأحداث الممتدة:

• ويتم دعم معظم الأحداث والإجراءات الأكثر استخدامًا.
• يتم دعم أهداف الملفات والعدادات ring_buffer.
• يتم دعم أهداف الملف مع وحدة تخزين Azure Blob، نظرًا إلى أنه ليس لديك إمكانية الوصول إلى الأقراص الأساسية لنظام التشغيل.

يمكنك القيام باستخدام Management Studio أو T-SQL لكي تقوم بإنشاء وبدء جلسات العمل. يمكنك استخدام SSMS لعرض البيانات المستهدفة لجلسة الحدث الموسعة أو وظيفة sys.fn_xe_file_target_read_fileالنظام .

إشعار

لا يمكن استخدام SSMS لعرض البيانات النشطة لقاعدة بيانات Azure SQL.

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

الأحداث الممتدة لمثيل Azure SQL المُدار

يمكنك القيام باستخدام الأحداث الممتدة لمثيل SQL المُدار، تمامًا مثل SQL Server، وذلك من خلال إنشاء الجلسات واستخدام الأحداث والإجراءات والأهداف. قم بوضع هذه النقاط الهامة في الاعتبار عند إنشاء جلسات الأحداث الممتدة:

• ويتم دعم جميع الأحداث والأهداف والإجراءات.
• يتم دعم أهداف الملف مع وحدة تخزين Azure Blob، نظرًا إلى أنه ليس لديك إمكانية الوصول إلى الأقراص الأساسية لنظام التشغيل.
• تتم إضافة بعض الأحداث المخصصة لمثيل SQL المُدار لتتبع الأحداث الخاصة بإدارة المثيل وتنفيذها.

يمكنك القيام باستخدام Management Studio أو T-SQL لكي تقوم بإنشاء وبدء جلسات العمل. يمكنك استخدام SSMS لعرض البيانات المستهدفة لجلسة الحدث الموسعة أو وظيفة sys.fn_xe_file_target_read_fileالنظام . يتم دعم قدرة SSMS على عرض البيانات المباشرة ل SQL Server وAzure SQL Managed Instance.

سيناريوهات الأداء لـ Azure SQL

ولتقوم بتقرير كيف يتم تطبيق أدوات المراقبة واستكشاف الأخطاء الخاصة بالأداء وإصلاحها وتطبيق القدرات، فمن المهم النظر إلى أداء Azure SQL من خلال السيناريوهات.

سيناريوهات الأداء المشترك

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

فدعونا نتعمق أكثر في تفاصيل كل جانب من جوانب المخطط.

قيد التشغيل مقابل في الانتظار

أولاً، قم بالنظر إلى الاستخدام العام للمورد. لنشر SQL Server قياسي، يمكنك استخدام أدوات مثل مراقبة الأداء في Windows أو أعلى في Linux. وبالنسبة إلى Azure SQL فإنه يمكنك استخدام الطرق التالية:

• مدخل Microsoft Azure/ وPowerShell/والتنبيهات

  ويحتوي Azure Monitor على مقاييس متكاملة لعرض استخدام الموارد لـ Azure SQL. ويمكنك أيضًا القيام بإعداد التنبيهات للبحث عن شروط استخدام الموارد.

• sys.dm_db_resource_stats

  وبالنسبة إلى قاعدة بيانات Azure SQL، يمكنك النظر إلى DMV هذه لرؤية استخدام مورد CPU والذاكرة وI/O لنشر قاعدة البيانات. وتقوم DMV هذه بأخذ لقطة من هذه البيانات كل 15 ثانية.

• sys.server_resource_stats

  يعمل DMV هذا تماما مثل sys.dm_db_resource_stats، ولكنه يستخدم لمشاهدة استخدام الموارد لمثيل SQL المدار لوحدة المعالجة المركزية والذاكرة والإداء/الإخراج. وتقوم DMV هذه أيضًا بأخذ لقطة كل 15 ثانية.

• sys.dm_user_db_resource_governance

  وبالنسبة إلى قاعدة بيانات Azure SQL، تقوم DMV بإرجاع إعدادات التكوين الفعلي وإعدادات القدرة المستخدمة من قبل آليات إدارة الموارد في قاعدة البيانات الحالية أو في التجمّع المرن.

• sys.dm_instance_resource_governance

  بالنسبة إلى مثيل Azure SQL المدار، يقوم DMV هذا بإرجاع معلومات مشابهة مثل sys.dm_user_db_resource_governance، ولكن لمثيل SQL المدار الحالي.

قيد التشغيل

إذا كنت قد حددت أن المشكلة هي ارتفاع استخدام معالج CPU، فهذا يسمى سيناريو التشغيل. ويمكن أن يتضمن سيناريو التشغيل الاستعلامات التي تستهلك الموارد من خلال التجميع أو التنفيذ. قم باستخدام الأدوات التالية للقيام بالمزيد من التحليل:

• Query Store

  قم باستخدام تقارير المورد الأعلى استهلاكًا في Management Studio أو طرق عرض كتالوج مخزن الاستعلام أو رؤية أداء الاستعلام في مدخل Microsoft Azure (قاعدة بيانات Azure SQL فقط) لإيجاد الاستعلامات التي تقوم باستهلاك معظم موارد وحدة معالج CPU.

• sys.dm_exec_requests

  قم باستخدام DMV في Azure SQL لكي تحصل على لقطة من حالة الاستعلامات النشطة. ابحث عن الاستعلامات ذات الحالة RUNNABLE ونوع SOS_SCHEDULER_YIELD انتظار لمعرفة ما إذا كانت لديك سعة CPU كافية.

• sys.dm_exec_query_stats

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

• sys.dm_exec_procedure_stats

  يوفر DMV هذا معلومات تشبه sys.dm_exec_query_statsإلى حد كبير ، باستثناء معلومات الأداء التي يمكن عرضها على مستوى الإجراء المخزن.

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

قيد الانتظار‬

إذا لم تظهر المشكلة الخاصة بك كاستخدام عالٍ لمورد CPU، فقد تكون مشكلة الأداء تتضمن الانتظار للمورد. وتشمل السيناريوهات التي تتضمن الانتظار للمورد ما يلي:

• انتظار I/O
• انتظار التأمين
• مهلة الحماية المؤقتة
• حدود ذاكرة التخزين المؤقت
• تخصيصات الذاكرة
• خطة إخلاء الذاكرة المؤقتة

لإجراء تحليل لسيناريوهات الانتظار، عادة ما تنظر إلى الأدوات التالية:

• sys.dm_os_wait_stats

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

• sys.dm_exec_requests

  استخدم DMV هذا للعثور على أنواع انتظار محددة للاستعلامات النشطة لمعرفة المورد الذي تنتظره. وهذا يمكن أن يكون سيناريو حظر قياسي، ويكون في انتظار عمليات تأمين من المستخدمين الآخرين.

• sys.dm_os_waiting_tasks

  يمكنك استخدام DMV هذا للبحث عن أنواع انتظار لمهمة معينة لاستعلام معين يتم تنفيذه حاليا، ربما لمعرفة سبب استعلام يستغرق وقتا أطول من المعتاد. sys.dm_os_waiting_tasks يحتوي على إحصائيات الانتظار المباشر التي sys.dm_os_wait_stats التجميعات بمرور الوقت.

• Query Store

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

تلميح

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

السيناريوهات الخاصة بـ Azure SQL

فهناك بعض من سيناريوهات الأداء، سواء قيد التشغيل أو في الانتظار، تكون خاصة بـ Azure SQL. وهي تشمل إدارة التسجيل وحدود العامل وانتظار موجهة مستويات الخدمات الهامة للأعمال التجارية والانتظار الخاص بالنشر الفائق السرعة.

إدارة السجلات

يمكن أن تقوم Azure SQL باستخدام إدارة معدل التسجيل لفرض حدود الموارد على استخدام سجلات المعاملات. وقد تكون بحاجة إلى هذا الفرض لضمان حدود الموارد وتنفيذ اتفاقية SLA الموعودة. ويمكن النظر إلى إدارة السجلات من خلال أنواع الانتظار التالية:

• LOG_RATE_GOVERNOR: ينتظر قاعدة بيانات Azure SQL
• POOL_LOG_RATE_GOVERNOR: ينتظر التجمعات المرنة
• INSTANCE_LOG_GOVERNOR: ينتظر مثيل Azure SQL المدار
• HADR_THROTTLE_LOG_RATE*: ينتظر زمن انتقال الأعمال الحرجة والنسخ المتماثل الجغرافي

الحدود الخاصة بالعامل

يستخدم SQL Server مجموعة من العمال ولكن لديها حدود لأقصى عدد من العمال. قد تقترب التطبيقات التي تضم عددا كبيرا من المستخدمين المتزامنين من حدود العامل المفروضة لقاعدة بيانات Azure SQL ومثيل SQL المدار:

• ولدى قاعدة بيانات Azure SQL حدود استنادًا إلى مستوى الخدمة وحجمها. فإذا تجاوزت هذا الحد، يتلقى الاستعلام الجديد خطأ.
• في الوقت الحالي، يستخدم max worker threadsSQL Managed Instance ، لذلك قد يرى THREADPOOL العمال الذين تجاوزوا هذا الحد حالات انتظار.

انتظار HADR للأعمال التجارية الحرجة

فإذا كنت تقوم باستخدام مستوى خدمة الأعمال الحرجة، فقد ترى بشكل غير متوقع أنواع الانتظار التالية:

• HADR_SYNC_COMMIT
• HADR_DATABASE_FLOW_CONTROL
• HADR_THROTTLE_LOG_RATE_SEND_RECV

فعلى الرغم من أن هذه الانتظارات من المحتمل ألا تبطئ التطبيق الخاص بك، فقد لا تتوقع أن ترى هذه. فعادةً ما تكون مخصصة لاستخدام مجموعة قابلية وصول عالية التوفر. تستخدم المستويات الهامة للأعمال تقنية المجموعة المتاحة لتنفيذ اتفاقية SLA وميزات التوافر الخاصة بمستوى خدمة الأعمال الهامة، لذا فتكون هذه الانتظارات متوقعة. ولاحظ أن أوقات الانتظار الطويلة قد تشير إلى نقطة ازدحام مثل زمن انتقال عملية I/O أو النسخة المماثلة الخلفية.

مقياس فائق

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

في التمرين التالي، ستتعلم كيفية مراقبة مشكلة أداء Azure SQL وحلها باستخدام الأدوات والمعرفة التي اكتسبتها في هذه الوحدة.

متابعة