إدارة الموارد في قاعدة بيانات Azure SQL

  • مقالة

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

توفر هذه المقالة نظرة عامة حول إدارة الموارد في قاعدة بيانات Azure SQL. يوفر معلومات حول ما يحدث عند الوصول إلى حدود الموارد، ويصف آليات إدارة الموارد المستخدمة لفرض هذه الحدود.

بالنسبة لحدود الموارد المحددة لكل مستوى تسعير (المعروف أيضاً باسم هدف الخدمة) لقواعد البيانات الفردية، راجع إما حدود موارد قاعدة البيانات الفردية المستندة إلى DTU أو مورد قاعدة البيانات الفردية المستند إلى vCore حدود . بالنسبة لحدود موارد التجمع المرن، راجع إما حدود موارد التجمع المرن المستندة إلى DTU أو حدود موارد التجمع المرن المستندة إلى vCore .

تلميح

بالنسبة إلى حدود مجموعة SQL المخصصة في Azure Synapse Analytics، راجع حدود السعة و حدود الذاكرة والتزامن .

حدود الخادم المنطقي

المورد الحد
قواعد البيانات لكل خادم منطقي 5000
العدد الافتراضي للخوادم المنطقية لكل اشتراك في المنطقة 20
أقصى عدد من الخوادم المنطقية لكل اشتراك في المنطقة 250
حصة DTU / eDTU لكل خادم منطقي 54,000
حصة vCore لكل خادم منطقي 540
أقصى تجمعات مرنة لكل خادم منطقي مقيد بعدد DTUs أو vCores. على سبيل المثال، إذا كان كل تجمع 1000 وحدة DTU، فيمكن للخادم أن يدعم 54 مجموعة.

هام

نظراً لأن عدد قواعد البيانات يقترب من الحد لكل خادم منطقي، يمكن أن يحدث ما يلي:

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

ملاحظة

للحصول على المزيد من حصة DTU / eDTU أو حصة vCore أو خوادم منطقية أكثر من الرقم الافتراضي، قم بإرسال طلب دعم جديد في بوابة Azure. لمزيد من المعلومات، راجع طلب زيادات الحصة النسبية لقاعدة بيانات ِAzure SQL.

ماذا يحدث عندما يتم الوصول إلى حدود الموارد

حساب وحدة المعالجة المركزية

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

التخزين

عندما تصل مساحة البيانات المستخدمة إلى الحد الأقصى لحجم البيانات؛ إما على مستوى قاعدة البيانات أو على مستوى التجمع المرن، تفشل عمليات الإدراج والتحديثات التي تُزيد حجم البيانات ويتلقى العملاء رسالة خطأ. تظل عبارات SELECT وDELETE غير متأثرة.

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

عند مواجهة استخدام كبير للمساحة، تشمل خيارات التخفيف ما يلي:

  • زيادة الحد الأقصى لحجم البيانات لقاعدة البيانات أو التجمع المرن، أو الارتقاء إلى هدف خدمة بحد أقصى أعلى لحجم البيانات. راجع توسيع نطاق موارد قاعدة البيانات الفردية و قياس موارد التجمع المرن .
  • إذا كانت قاعدة البيانات في تجمع مرن، فبدلاً من ذلك يمكن نقل قاعدة البيانات خارج التجمع، بحيث لا تتم مشاركة مساحة التخزين الخاصة بها مع قواعد البيانات الأخرى.
  • تقليص قاعدة البيانات لاستعادة المساحة غير المستخدمة. في التجمعات المرنة، يوفر تقليص قاعدة البيانات مزيداً من التخزين لقواعد البيانات الأخرى في التجمع. لمزيد من المعلومات، راجع إدارة مساحة الملف في قاعدة بيانات Azure SQL .
  • تحقق مما إذا كان الاستخدام الكبير للمساحة ناتجاً عن ارتفاع كبير في حجم مخزن الإصدار الثابت (PVS). PVS هو جزء من كل قاعدة بيانات، ويتم استخدامه لتنفيذ الاسترداد السريع لقاعدة البيانات. لتحديد حجم PVS الحالي، راجع استكشاف أخطاء PVS وإصلاحها . السبب الشائع لحجم PVS الكبير هو المعاملة المفتوحة لوقت طويل (ساعات)، مما يمنع تنظيف الإصدارات الأقدم للسجل في PVS.
  • بالنسبة لقواعد البيانات والتجمعات المرنة في طبقات الخدمات المميزة وBusiness Critical التي تستهلك كميات كبيرة من التخزين، فقد تتلقى خطأ نفاد المساحة على الرغم من أن المساحة المستخدمة في قاعدة البيانات أو التجمع المرن أقل من الحد الأقصى لحجم البيانات. قد يحدث هذا إذا tempdbأو ملفات سجل العمليات تستهلك قدراً كبيراً من التخزين نحو الحد الأقصى للتخزين المحلي. أخفق قاعدة البيانات أو التجمع المرن في إعادة ضبط tempdbإلى حجمها الأولي الأصغر، أو تقليص سجل العمليات لتقليل استهلاك التخزين المحلي.

الجلسات والعمال والطلبات

يتم تعريف الجلسات والعمال والطلبات على النحو التالي:

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

لمزيد من المعلومات حول هذه المفاهيم، راجع دليل هندسة المهام ومؤشر الترابط.

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

ملاحظة

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

يمكنك التخفيف من الاقتراب من حدود العامل أو الجلسات أو الوصول إليها من خلال:

البحث عن حدود العامل والجلسة لقاعدة بيانات Azure SQL حسب مستوى الخدمة وحجم الحساب:

تعرف على المزيد حول استكشاف أخطاء معينة لحدود جلسة العمل أو العامل في أخطاء إدارة الموارد.

ذاكرة

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

بعد بدء تشغيل محرك قاعدة البيانات، عندما يبدأ حمل العمل في قراءة البيانات من التخزين، يقوم محرك قاعدة البيانات بتخزين البيانات مؤقتاً في الذاكرة. بعد فترة التكثيف الأولية هذه، من الشائع ومن المتوقع أن ترى الأعمدة avg_memory_usage_percentو avg_instance_memory_percentفي sys.dm_db_resource_stats قريبة أو تساوي 100٪، خاصة بالنسبة لقواعد البيانات غير الخاملة والتي لا تتناسب تماماً مع الذاكرة.

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

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

عند مواجهة أخطاء نفاد الذاكرة، تتضمن خيارات التخفيف ما يلي:

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

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

استهلاك الموارد من خلال أعباء عمل المستخدم والعمليات الداخلية

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

يتم تسجيل إجمالي استهلاك وحدة المعالجة المركزية والذاكرة حسب أحمال عمل المستخدم والعمليات الداخلية في طرق عرض sys.dm_db_resource_stats و sys.resource_stats ، في avg_instance_cpu_percentو avg_instance_memory_percentعمود. يتم الإبلاغ عن هذه البيانات أيضاً عبر مقاييس sqlserver_process_core_percentو sqlserver_process_memory_percentAzure Monitor، لـ قواعد البيانات الفردية و التجمعات المرنة في مستوى البلياردو.

يتم تسجيل استهلاك وحدة المعالجة المركزية والذاكرة بواسطة أحمال عمل المستخدم في كل قاعدة بيانات في طرق عرض sys.dm_db_resource_stats و sys.resource_stats ، في avg_cpu_percentو avg_memory_usage_percentعمود. بالنسبة للتجمعات المرنة، يتم الإبلاغ عن استهلاك الموارد على مستوى التجمع في طريقة العرض sys.elastic_pool_resource_stats . يتم أيضاً الإبلاغ عن استهلاك وحدة المعالجة المركزية لحمل عمل المستخدم عبر cpu_percentمقياس مراقب Azure، لقواعد البيانات الفردية و التجمعات المرنة على مستوى التجمع.

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

في سياق مراقبة الأداء واستكشاف الأخطاء وإصلاحها، من المهم مراعاة استهلاك وحدة المعالجة المركزية للمستخدم (avg_cpu_percent، cpu_percent) و إجمالي استهلاك وحدة المعالجة المركزية حسب أعباء عمل المستخدم والعمليات الداخلية (avg_instance_cpu_percent، sqlserver_process_core_percent).

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

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

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

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

بالإضافة إلى استخدام Resource Governor للتحكم في الموارد داخل محرك قاعدة البيانات، تستخدم قاعدة بيانات Azure SQL أيضاً عنصر وظيفةWindows لإدارة الموارد على مستوى العملية، ومدير موارد خادم الملفات Windows لإدارة حصة التخزين.

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

إدارة إدخال/إخراج البيانات

إدارة إدخال / إخراج البيانات هي عملية في قاعدة بيانات Azure SQL تُستخدم لتقييد قراءة وكتابة الإدخال / الإخراج الفعلي مقابل ملفات بيانات قاعدة البيانات. يتم تعيين حدود IOPS لكل مستوى خدمة لتقليل تأثير "الجوار المزعج"، لتوفير عدالة تخصيص الموارد في خدمة متعددة المستأجرين، والبقاء ضمن إمكانات الأجهزة والتخزين الأساسيين.

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

على سبيل المثال، إذا قام استعلام بإنشاء 1000 IOPS دون أي إدارة لموارد الإدخال والإخراج، ولكن تم تعيين الحد الأقصى لـ IOPS لمجموعة حمل العمل على 900 IOPS، فلن يتمكن الاستعلام من إنشاء أكثر من 900 IOPS. ومع ذلك، إذا تم تعيين الحد الأقصى لـ IOPS لمجموعة الموارد على 1500 IOPS، وكان إجمالي الإدخال/الإخراج من جميع مجموعات أحمال العمل المرتبطة بتجمع الموارد يتجاوز 1500 IOPS، فقد يتم تقليل الإدخال/الإخراج لنفس الاستعلام إلى ما دون حد مجموعة العمل البالغ 900 IOPS.

IOPS والقيم القصوى للإنتاجية التي يتم إرجاعها بواسطة طريقة العرض sys.dm_user_db_resource_governance بمثابة حدود / حدود قصوى، وليس كضمانات. علاوة على ذلك، لا تضمن إدارة الموارد أي زمن انتقال محدد للتخزين. إن أفضل زمن انتقال يمكن تحقيقه، وعمليات الإدخال / الإخراج (IOPS)، ومعدل النقل لحمل عمل مستخدم معين لا يعتمد فقط على حدود إدارة موارد الإدخال / الإخراج، ولكن أيضاً على مزيج أحجام الإدخال / الإخراج المستخدمة، وعلى إمكانيات التخزين الأساسي. تستخدم قاعدة بيانات SQL المدخلات والمخرجات التي تتفاوت في الحجم بين 512 كيلوبايت و4 ميغابايت. لأغراض فرض حدود IOPS، يتم حساب كل المدخلات والمخرجات بغض النظر عن حجمها، باستثناء قواعد البيانات التي تحتوي على ملفات بيانات في Azure Storage. في هذه الحالة، يتم حساب عمليات الإدخال / الإخراج الأكبر من 256 كيلوبايت على أنها عمليات إدخال متعددة بسعة 256 كيلوبايت للتوافق مع محاسبة الإدخال والإخراج لـ Azure Storage.

بالنسبة لقواعد البيانات الأساسية والقياسية والعامة، التي تستخدم ملفات البيانات في Azure Storage، قد لا تكون قيمة primary_group_max_ioقابلة للتحقيق إذا لم تكن قاعدة البيانات تحتوي على ملفات بيانات كافية لتوفير هذا العدد التراكمي من IOPS، أو إذا كانت البيانات لا يتم توزيعها بالتساوي عبر الملفات، أو إذا كان مستوى الأداء للنقاط الأساسية يحد من IOPS / الإنتاجية أقل من حدود إدارة الموارد. وبالمثل، مع عمليات الإدخال / الإخراج الصغيرة التي تم إنشاؤها بواسطة عمليات تنفيذ المعاملات المتكررة، قد لا يمكن تحقيق قيمة primary_max_log_rateمن خلال عبء العمل بسبب حد عمليات الإدخال / الإخراج في الثانية على كائن تخزين Azure الأساسي. بالنسبة لقواعد البيانات التي تستخدم Azure Premium Storage، تستخدم قاعدة بيانات Azure SQL مساحات تخزين كبيرة بما يكفي للحصول على IOPS / الإنتاجية المطلوبة، بغض النظر عن حجم قاعدة البيانات. بالنسبة لقواعد البيانات الأكبر حجماً، يتم إنشاء ملفات بيانات متعددة لزيادة إجمالي سعة IOPS / الإنتاجية.

يتم حساب قيم استخدام الموارد مثل avg_data_io_percent وavg_log_write_percent، المقررة في طرق العرض sys.dm_db_resource_stats، وsys.resource_stats وsys.elastic_pool_resource_stats كنسب مئوية للحد الأقصى لحدود إدارة الموارد. لذلك، عندما تحد عوامل أخرى غير إدارة الموارد IOPS / الإنتاجية، فمن الممكن أن نرى تسطيح IOPS / الإنتاجية وزيادة زمن الانتقال مع زيادة عبء العمل، على الرغم من أن استخدام الموارد المبلغ عنه لا يزال أقل من 100٪.

لتحديد قراءة وكتابة IOPS والإنتاجية ووقت الاستجابة لكل ملف قاعدة بيانات، استخدم الوظيفة sys.dm_io_virtual_file_stats () . تعمل هذه الوظيفة على إظهار كل عمليات الإدخال والإخراج مقابل قاعدة البيانات، بما في ذلك عمليات الإدخال والإخراج الخلفية التي لم يتم احتسابها تجاه avg_data_io_percent، ولكنها تستخدم عمليات الإدخال والإخراج في الثانية (IOPS) ومعدل نقل التخزين الأساسي، ويمكن أن تؤثر على زمن انتقال التخزين المرصود. تقوم الوظيفة بالإبلاغ عن زمن انتقال إضافي قد يتم تقديمه بواسطة إدارة موارد الإدخال / الإخراج للقراءة والكتابة، في العمودين io_stall_queued_read_ms وio_stall_queued_write_msعلى التوالي.

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

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

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

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

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

يتم عرض تشكيل حركة مرور منظم معدل السجل عبر أنواع الانتظار التالية (يتم عرضها في طريقتي العرض sys.dm_exec_requests و sys.dm_os_wait_stats ):

نوع الانتظار ملاحظات
LOG_RATE_GOVERNOR تقييد قاعدة البيانات
POOL_LOG_RATE_GOVERNOR تحديد حمام السباحة
INSTANCE_LOG_RATE_GOVERNOR تحديد مستوى المثيل
HADR_THROTTLE_LOG_RATE_SEND_RECV_QUEUE_SIZE التحكم في الملاحظات، التكرار المادي لمجموعة التوافر في Premium / Business Critical لا يواكب ذلك
HADR_THROTTLE_LOG_RATE_LOG_SIZE التحكم في التغذية الراجعة، والحد من المعدلات لتجنب حالة مساحة السجل
HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO التحكم في ردود فعل النسخ المتماثل الجغرافي، والحد من معدل السجل لتجنب زمن انتقال البيانات العالي وعدم توفر الثواني الجغرافية

عند مواجهة حد معدل السجل الذي يعيق قابلية التوسع المطلوبة، ضع في اعتبارك الخيارات التالية:

  • قم بالارتقاء إلى مستوى خدمة أعلى من أجل الحصول على الحد الأقصى لمعدل السجل لطبقة الخدمة، أو التبديل إلى مستوى خدمة مختلف. توفر طبقة الخدمة Hyperscale معدل سجل يبلغ 100 ميجابايت / ثانية بغض النظر عن مستوى الخدمة المختار.
  • إذا كانت البيانات التي يتم تحميلها عابرة، مثل عملية التقسيم المرحلي للبيانات في عملية ETL، فيمكن تحميلها في tempdb(والذي يتم تسجيله بأدنى حد).
  • بالنسبة للسيناريوهات التحليلية، قم بالتحميل إلى جدول مجمع أعمدة أو جدول به فهارس تستخدم ضغط البيانات . هذا يقلل من معدل التسجيل المطلوب. تعمل هذه التقنية على زيادة استخدام وحدة المعالجة المركزية وهي قابلة للتطبيق فقط على مجموعات البيانات التي تستفيد من فهارس مخزن الأعمدة المتفاوت أو ضغط البيانات.

إدارة مساحة التخزين

في مستويي الخدمات Premium وBusiness Critical، بيانات العملاء بما في ذلك ملفات البيانات و ملفات سجل المعاملات و ملفات tempdb يتم تخزينه على تخزين SSD المحلي للجهاز الذي يستضيف قاعدة البيانات أو التجمع المرن. يوفر تخزين SSD المحلي عمليات إدخال / إخراج عالية ومعدل نقل عاليًا، وزمن انتقال منخفضًا للإدخال والإخراج. بالإضافة إلى بيانات العميل، يتم استخدام التخزين المحلي لنظام التشغيل وبرامج الإدارة وبيانات المراقبة والسجلات وغيرها من الملفات الضرورية لتشغيل النظام.

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

يمكنك أيضاً العثور على هذه القيمة ومقدار التخزين المحلي المستخدم حالياً بواسطة قاعدة بيانات معينة أو تجمع مرن باستخدام الاستعلام التالي:

SELECT server_name, database_name, slo_name, user_data_directory_space_quota_mb, user_data_directory_space_usage_mb
FROM sys.dm_user_db_resource_governance
WHERE database_id = DB_ID();
العمود الوصف
server_name اسم الخادم المنطقي
database_name اسم قاعدة البيانات
slo_name اسم هدف الخدمة، بما في ذلك إنشاء الأجهزة
user_data_directory_space_quota_mb الحد الأقصى للتخزين المحلي ، بالميغا بايت
user_data_directory_space_usage_mb استهلاك التخزين المحلي الحالي من خلال ملفات البيانات وملفات سجل العمليات وملفات tempdbبالميغابايت. يتم التحديث كل خمس دقائق.

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

هام

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

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

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

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

أحجام Tempdb

تعتمد حدود الحجم لـ tempdb في Azure SQL Database على نموذج الشراء والتوزيع.

لمعرفة المزيد، راجع tempdbحدود الحجم لـ:

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