مشاركة عبر

إدارة الموارد في تجمعات مرنة كثيفة

  • مقالة

ينطبق على: قاعدة بيانات Azure SQL

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

إدارة الموارد

تتطلب مشاركة الموارد من النظام التحكم بعناية في استخدام الموارد لتقليل تأثير "الجوار الصاخب"، حيث تؤثر قاعدة البيانات ذات الاستهلاك العالي للموارد على قواعد البيانات الأخرى في نفس المجموعة المرنة. تحقق Azure SQL Database هذه الأهداف من خلال تنفيذ إدارة الموارد. في الوقت نفسه، يجب أن يوفر النظام موارد كافية لميزات مثل التوافر العالي والتعافي من الكوارث (HADR) والنسخ الاحتياطي والاستعادة والمراقبة وتخزين الاستعلام والضبط التلقائي وما إلى ذلك لتعمل بشكل موثوق.

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

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

هام

في المجموعات الكثيفة مع العديد من قواعد البيانات النشطة، قد لا يكون من الممكن زيادة عدد قواعد البيانات في المجموعة حتى الحدود القصوى الموثقة لمجموعات DTU وvCore المرنة.

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

بالإضافة إلى ذلك، إذا تم تعيين min vCores لكل قاعدة بيانات أو min DTUs لكل إعداد قاعدة بيانات إلى قيمة أكبر من 0، فالحد الأقصى لعدد قواعد البيانات في المجموعة ستكون محدودة ضمنياً. لمزيد من المعلومات، راجع خصائص قاعدة البيانات لقواعد بيانات vCore المجمعة وخصائص قاعدة البيانات لقواعد بيانات DTU المجمعة.

عندما يحدث التنازع على الموارد في مجموعة معبأة بكثافة، يمكن للعملاء اختيار واحد أو أكثر من الإجراءات التالية للتخفيف من حدته:

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

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

مراقبة استهلاك الموارد

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

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

لإرسال تنبيه عندما يتجاوز استخدام موارد التجمع (CPU، وبيانات IO، وسجل IO، والعاملين، إلخ.) الحد، خذ بعين الاعتبار أيضاً إنشاء تنبيهات عبر مدخل Microsoft Azure أو أمر PowerShell Add-AzMetricAlertRulev2. عند مراقبة المجموعات المرنة، خذ بعين الاعتبار أيضاً إنشاء تنبيهات لقواعد البيانات الفردية في التجمع إذا لزم الأمر في السيناريو الخاص بك. للحصول على عينة من السيناريو لمراقبة المجموعات المرنة، راجع مراقبة وإدارة أداء Azure SQL Database في تطبيق SaaS متعدد المستأجرين.

اسم قياسي الوصف متوسط القيمة الموصى بها
avg_instance_cpu_percent استخدام وحدة المعالجة المركزية لعملية SQL المرتبطة بمجموعة مرنة، كما يقاس من قبل نظام التشغيل الأساسي. متوفر في طريقة العرض sys.dm_db_resource_stats في كل قاعدة بيانات، وفي طريقة العرض sys.elastic_pool_resource_stats في master قاعدة البيانات. يُصدر هذا القياس إلى Azure Monitor، حيث يُطلق عليه اسمsqlserver_process_core_percent، ويُعرض في مدخل Microsoft Azure. هذه القيمة هي نفسها لكل قاعدة بيانات في نفس المجموعة المرنة. أقل من 70٪. قد يتم قبول ارتفاعات قصيرة تصل إلى 90٪ من حين لآخر.
max_worker_percent استخدام مؤشر ترابط العامل. المقدمة لكل قاعدة بيانات في المجموعة، وكذلك للمجموعة نفسها. هناك حدود مختلفة على عدد مؤشرات الترابط العاملة على مستوى قاعدة البيانات، وعلى مستوى المجموعة، لذلك ينصح بمراقبة هذا المقياس على كلا المستويين. متوفر في طريقة العرض sys.dm_db_resource_stats في كل قاعدة بيانات، وفي طريقة العرض sys.elastic_pool_resource_stats في master قاعدة البيانات. يُصدر هذا القياس إلى Azure Monitor، حيث يُطلق عليه اسمworkers_percent، ويُعرض في مدخل Microsoft Azure. أقل من 80%. سوف تتسبب ارتفاعات تصل إلى 100٪ في فشل محاولات الاتصال والاستعلامات.
avg_data_io_percent استخدام IOPS للقراءة والكتابة المادية IO. المقدمة لكل قاعدة بيانات في المجموعة، وكذلك للمجموعة نفسها. هناك حدود مختلفة على عدد IOPS على مستوى قاعدة البيانات، وعلى مستوى المجموعة، لذلك ينصح بمراقبة هذا المقياس على كلا المستويين. متوفر في طريقة العرض sys.dm_db_resource_stats في كل قاعدة بيانات، وفي طريقة العرض sys.elastic_pool_resource_stats في master قاعدة البيانات. يُصدر هذا القياس إلى Azure Monitor، حيث يُطلق عليه اسمphysical_data_read_percent، ويُعرض في مدخل Microsoft Azure. أقل من 80%. قد يتم قبول ارتفاعات قصيرة تصل إلى 100% من حين لآخر.
avg_log_write_percent استخدامات معدل النقل لتسجيل المعاملة كتابة IO. المقدمة لكل قاعدة بيانات في المجموعة، وكذلك للمجموعة نفسها. هناك حدود مختلفة على معدل نقل السجل على مستوى قاعدة البيانات، وعلى مستوى المجموعة، لذلك ينصح بمراقبة هذا المقياس على كلا المستويين. متوفر في طريقة العرض sys.dm_db_resource_stats في كل قاعدة بيانات، وفي طريقة العرض sys.elastic_pool_resource_stats في master قاعدة البيانات. يُصدر هذا القياس إلى Azure Monitor، حيث يُطلق عليه اسمlog_write_percent، ويُعرض في مدخل Microsoft Azure. عندما يقترب هذا القياس من 100٪، ستكون جميع تعديلات قواعد البيانات (INSERT, UPDATE, DELETE, MERGE statements, SELECT … INTO, BULK INSERT, إلخ.) أبطأ. أقل من 90%. قد يتم قبول ارتفاعات قصيرة تصل إلى 100% من حين لآخر.
oom_per_second معدل أخطاء الذاكرة (OOM) في مجموعة مرنة، وهو مؤشر لضغط الذاكرة. متوفر في طريقة العرض sys.dm_resource_governor_resource_pools_history_ex. راجع أمثلة لاستعلام نموذج لحساب هذا المقياس. لمزيد من المعلومات، راجع حدود الموارد المجموعات المرنة باستخدام DTUs أو المجموعات المرنة باستخدام vCores، واستكشاف أخطاء الذاكرة وإصلاحها باستخدام Azure SQL Database. إذا واجهت أخطاء في الذاكرة، فقيم sys.dm_os_out_of_memory_events. 0
avg_storage_percent إجمالي مساحة التخزين المستخدمة من قبل البيانات في جميع قواعد البيانات داخل مجموعة مرنة. لا يتضمن مساحة فارغة في ملفات قاعدة البيانات. متاح في طريقة عرض sys.elastic_pool_resource_stats في قاعدة البيانات.master يُصدر هذا القياس إلى Azure Monitor، حيث يُطلق عليه اسمstorage_percent، ويُعرض في مدخل Microsoft Azure. أقل من 80%. يمكن الاقتراب 100٪ لمجموعات مع عدم وجود نمو البيانات.
avg_allocated_storage_percent إجمالي مساحة التخزين المستخدمة من قبل البيانات في جميع قواعد البيانات داخل مجموعة مرنة. يتضمن مساحة فارغة في ملفات قاعدة البيانات. متاح في طريقة عرض sys.elastic_pool_resource_stats في قاعدة البيانات.master يُصدر هذا القياس إلى Azure Monitor، حيث يُطلق عليه اسمallocated_data_storage_percent، ويُعرض في مدخل Microsoft Azure. أقل من 90%. يمكن الاقتراب 100٪ لمجموعات مع عدم وجود نمو البيانات.
tempdb_log_used_percent استخدام مساحة سجل المعاملات في قاعدة البيانات.tempdb على الرغم من أن الكائنات المؤقتة التي تم إنشاؤها في قاعدة بيانات واحدة غير مرئية في قواعد البيانات الأخرى في نفس المجموعة المرن، مورد مشترك لجميع قواعد البيانات في نفس المجموعة.tempdb يمكن أن تستهلك المعاملة طويلة الأمد أو المعزولة في tempdb والتي بدأت من قاعدة بيانات واحدة في المجموعة جزءاً كبيراً من سجل المعاملات، وتتسبب في فشل الاستعلامات في قواعد البيانات الأخرى في نفس التجمع. مشتق من طرق العرض sys.dm_db_log_space_usage وsys.database_files. يتم أيضاً انبعاث هذا المقياس إلى Azure Monitor، حيث يمكن عرضه في مدخل Microsoft Azure. راجع أمثلة استعلام نموذج لإرجاع القيمة الحالية لهذا المقياس. أقل من 50%. يُقبل حدوث ارتفاعات عرضية تصل إلى 80٪.

بالإضافة إلى هذه المقاييس، توفر قاعدة بيانات Azure SQL طريقة عرض تُرجع حدود حوكمة الموارد الفعلية، بالإضافة إلى طرق عرض إضافية تُرجع إحصاءات استخدام الموارد على مستوى تجمع الموارد وعلى مستوى مجموعة حمل العمل.

عرض الاسم الوصف
sys.dm_user_db_resource_governance إرجاع إعدادات التكوين والقدرة الفعلية المستخدمة من قبل آليات إدارة الموارد في قاعدة البيانات الحالية أو المجموعة المرنة.
sys.dm_resource_governor_resource_pools إرجاع معلومات حول حالة تجمع الموارد الحالية والتكوين الحالي لمجموعات الموارد وإحصائيات مجموعة الموارد التراكمية.
sys.dm_resource_governor_workload_groups إرجاع إحصائيات مجموعة حمل العمل التراكمي والتكوين الحالي لمجموعة حمل العمل. يمكن ربط طريقة العرض هذه sys.dm_resource_governor_resource_pools في عمود الحصول على معلومات مجموعة الموارد.pool_id
⁦⁩sys.dm_resource_governor_resource_pools_history_ex⁦⁩ إرجاع إحصائيات استخدام تجمع الموارد للمحفوظات الحديثة، بناءً على عدد النسخ المطابقة المتوفرة. يمثل كل سجل فاصلاً زمنياً. تُوفر مدة الفاصل الزمني في العمود duration_ms. ترجع الأعمدة التغيير في كل إحصائية أثناء الفاصل الزمني.delta_
⁦⁩sys.dm_resource_governor_workload_groups_history_ex⁦⁩ إرجاع إحصائيات استخدام مجموعة حمل العمل للمحفوظات الحديثة، بناءً على عدد النسخ المطابقة المتوفرة. يمثل كل سجل فاصلاً زمنياً. تُوفر مدة الفاصل الزمني في العمود duration_ms. ترجع الأعمدة التغيير في كل إحصائية أثناء الفاصل الزمني.delta_

تلميح

للاستعلام عن طرق عرض هذه الإدارة الديناميكية وغيرها باستخدام أساسي بخلاف مسؤول الخادم، أضف هذا الأساسي إلى ##MS_ServerStateReader##دور الخادم.

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

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

توصيات تنفيذية

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

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

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

ملاحظة

بالنسبة لتجمعات DTU المرنة، فإن قياس eDTU على مستوى التجمع ليس MAX أو SUM لاستخدام قاعدة البيانات الفردية. مشتق من استخدام مختلف قياسات مستوى التجمع. قد تكون حدود موارد مستوى التجمع أعلى من حدود مستوى قاعدة البيانات الفردية، لذلك من الممكن أن تصل قاعدة البيانات الفردية إلى حد موارد معين (CPU، data IO، log IO، إلخ.)، حتى عندما يشير تقرير eDTU للمجموعة إلى عدم وجود وصول إلى الحد الأقصى.

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

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

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

  • نقل بعض قواعد البيانات خارج المجموعة لتقليل إجمالي المساحة المخصصة
  • تقليص ملفات قاعدة البيانات لتقليل المساحة الفارغة المخصصة في الملفات
  • تغيير حجم نطاق المجموعة إلى هدف خدمة مع أكبر حجم للحجم الأقصى للمجموعة

إذا استخدمت مساحة مجموعة (إجمالي حجم البيانات في جميع قواعد البيانات في مجموعة، لا تشمل المساحة الفارغة في الملفات) اتجاهات عالية وعلى الطريق الصحيح للوصول إلى الحد الأقصى لحجم مجموعة، وتشمل خيارات التخفيف:

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

تجنب خوادم كثيفة للغاية. قاعدة بيانات Azure SQL تدعم ما يصل إلى 5،000 قاعدة بيانات لكل خادم. قد يفكر العملاء الذين يستخدمون مجموعات مرنة مع الآلاف من قواعد البيانات في وضع مجموعات مرنة متعددة على خادم واحد، مع العدد الإجمالي لقواعد البيانات حتى الحد المدعوم. ومع ذلك، تنشئ الخوادم مع عدة آلاف من قواعد البيانات تحديات التشغيل. العمليات التي تتطلب تعداد جميع قواعد البيانات على خادم، على سبيل المثال عرض قواعد البيانات في المدخل، ستكون أبطأ. ستؤثر الأخطاء التشغيلية، مثل التعديل غير الصحيح لتسجيلات الدخول على مستوى الخادم أو قواعد جدار الحماية، على عدد أكبر من قواعد البيانات. الحذف العرضي للخادم سيتطلب مساعدة من دعم Microsoft لاسترداد قواعد البيانات على الخادم المحذوف، وسيتسبب انقطاع مطولة لجميع قواعد البيانات المتأثرة.

حدد عدد قواعد البيانات لكل خادم بعدد أقل من الحد الأقصى المدعوم. في العديد من وحدات السيناريو، استخدام قواعد بيانات تصل إلى 1000-2000 لكل خادم هو الأمثل. لتقليل احتمال حذف الخادم غير مقصود، ضع تأمين حذف على الخادم أو مجموعة الموارد الخاصة به.

أمثلة

عرض إعدادات سعة قاعدة البيانات الفردية

استخدم sys.dm_user_db_resource_governance طريقة عرض الإدارة الديناميكية لعرض إعدادات السعة والتكوين الفعلي المستخدمَين بواسطة إدارة الموارد في قاعدة البيانات الحالية أو التجمع المرن. لمزيد من المعلومات، راجع sys.dm_user_db_resource_governance.

قم بتشغيل هذا الاستعلام في أي قاعدة بيانات في تجمع مرن. جميع قواعد البيانات في التجمع لها نفس إعدادات إدارة الموارد.

SELECT * FROM sys.dm_user_db_resource_governance AS rg
WHERE database_id = DB_ID();

مراقبة الاستهلاك العام لموارد التجمع المرنة

استخدم sys.elastic_pool_resource_stats عرض كتالوج النظام لمراقبة استهلاك الموارد للتجمع بأكمله. لمزيد من المعلومات، راجع sys.elastic_pool_resource_stats.

يجب تشغيل عينة الاستعلام هذه لعرض آخر 10 دقائق في قاعدة بيانات master لخادم Azure SQL المنطقي الذي يحتوي على التجمع المرن المطلوب.

SELECT * FROM sys.elastic_pool_resource_stats AS rs
WHERE rs.start_time > DATEADD(mi, -10, SYSUTCDATETIME()) 
AND rs.elastic_pool_name = '<elastic pool name>';

مراقبة استهلاك موارد قاعدة البيانات الفردية

استخدم sys.dm_db_resource_stats عرض الإدارة الديناميكي لمراقبة استهلاك الموارد لقواعد البيانات الفردية. لمزيد من المعلومات، راجع sys.dm_db_resource_stats. يوجد سجل واحد لكل 15 ثانية، حتى لو لم يكن هناك أي نشاط. تُحفظ البيانات التاريخية لمدة ساعة واحدة تقريباً.

يجب تشغيل عينة هذا الاستعلام لعرض آخر 10 دقائق من البيانات في قاعدة البيانات المطلوبة.

SELECT * FROM sys.dm_db_resource_stats AS rs
WHERE rs.end_time > DATEADD(mi, -10, SYSUTCDATETIME());

كي يصبح وقت استبقاء البيانات أطول والتردد أقل، خذ بعين الاعتبار الاستعلام التالي على sys.resource_stats، قم بالتشغيل في قاعدة بيانات master للخادم المنطقي Azure SQL. لمزيد من المعلومات، راجع sys.resource_stats (Azure SQL Database). يوجد سجل واحد كل خمس دقائق، ويتم الاحتفاظ بالبيانات التاريخية لمدة أسبوعين.

SELECT * FROM sys.resource_stats
WHERE [database_name] = 'sample'
ORDER BY [start_time] desc;

مراقبة استخدام الذاكرة

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

SELECT pool_id,
       name AS resource_pool_name,
       IIF(name LIKE 'SloSharedPool%' OR name LIKE 'UserPool%', 'user', 'system') AS resource_pool_type,
       SUM(CAST(delta_out_of_memory_count AS decimal))/(SUM(duration_ms)/1000.) AS oom_per_second
FROM sys.dm_resource_governor_resource_pools_history_ex
GROUP BY pool_id, name
ORDER BY pool_id;

مراقبة استخدام مساحة السجلtempdb

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

SELECT (lsu.used_log_space_in_bytes / df.log_max_size_bytes) * 100 AS tempdb_log_space_used_percent
FROM tempdb.sys.dm_db_log_space_usage AS lsu
CROSS JOIN (
           SELECT SUM(CAST(max_size AS bigint)) * 8 * 1024. AS log_max_size_bytes
           FROM tempdb.sys.database_files
           WHERE type_desc = N'LOG'
           ) AS df
;

الخطوات التالية