الأسئلة المتداولة حول Azure SQL Database Hyperscale

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

يتوفر مستوى خدمة Hyperscale فقط لقواعد البيانات المفردة باستخدام نموذج الشراء المستند إلى vCore في Azure SQL Database.

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

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

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

يتوفر حاليا مستوى خدمة Hyperscale في المناطق المدرجة ضمن نظرة عامة على Azure SQL Database Hyperscale.

نعم. لمزيد من المعلومات والحدود حول عدد قواعد بيانات لكل خادم، راجع حدود موارد SQL Database لقواعد البيانات المفردة والمجمعة على خادم.

يوفر تصميم Hyperscale أداءً ومعدل نقل عاليين مع دعم أحجام قواعد بيانات كبيرة.

توفر Hyperscale قابلية توسع سريعة استنادًا إلى الطلب على حمل العمل لديك.

• توسيع النطاق/تقليصه

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

• تقليص النطاق/توسيعه

  باستخدام Hyperscale، يمكنك استخدام ثلاثة أنواع من النُسخ المتماثلة الثانوية لتلبية متطلبات توسيع نطاق القراءة وقابلية الوصول العالية والنسخ المتماثل الجغرافي. هذا يتضمن:

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

نعم يمكنك.

لا، يظل نموذج برمجة التطبيق خاصتك كما هو الحال مع أي قاعدة بيانات MSSQL أخرى. يمكنك استخدام سلسلة الاتصال كالمعتاد والطرق المعتادة الأخرى للتفاعل مع قاعدة بيانات Hyperscale. بمجرد استخدام Hyperscale، يمكن لتطبيقك الاستفادة من ميزات مثل النُسخ المتماثلة الثانوية.

على النسخة المتماثلة الأساسية، مستوى العزل الافتراضي هو RCSI (عزل اللقطة الملتزم بالقراءة). على النسخ المتماثلة الثانوية للتوسعة للقراءة، يكون مستوى العزل الافتراضي هو اللقطة. هذا هو نفسه كما هو الحال في أي قاعدة بيانات Azure SQL DB أخرى.

نعم، تتوفر Azure Hybrid Benefit لـ Hyperscale. يمكن لكل ذاكرة SQL Server Standard أساسية التعيين إلى Hyperscale vCores واحدة. يمكن لكل ذاكرة SQL Server Enterprise أساسية التعيين إلى أربعة Hyperscale vCores. لا تحتاج إلى ترخيص SQL للنسخ المتماثلة الثانوية. سيتم تطبيق سعر Azure Hybrid Benefit تلقائيًا على النسخ المتماثلة (الثانوية) للتوسعة للقراءة.

يعمل Hyperscale جيداً لجميع أنواع أحمال العمل، بما في ذلك أحمال عمل OLTP وHybrid (HTAP) والتحليلية (متجر البيانات).

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

إذا كنت تشغل تحليلات البيانات على نطاق واسع باستخدام استعلامات معقدة ومعدلات استيعاب مستمرة أعلى من 100 ميغابايت ثانية، أو باستخدام Parallel Data Warehouse (PDW) أو Teradata أو غيرها من مستودعات البيانات ذات المعالجة المتوازية المكثفة (MPP)، فقد يكون Azure Synapse Analytics هو الخيار الأفضل.

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

بالنسبة لأحمال عمل القراءة، يمكنك إنشاء نُسخ متماثلة مُسماة بحجم حساب أعلى (عدد أنوية وذواكر أكثر) من النُسخ الأساسية. لمزيد من المعلومات عن أحجام الحساب المتاحة، راجع أحجام تخزين وحساب Hyperscale.

بالنسبة لأحمال عمل القراءة، يمكن تحقيق ذلك باستخدام النُسخ المتماثلة المُسماة.

يمكنك تغيير عدد النُسخ المتماثلة الثانوية ذات قابلية الوصول العالية بين 0 و4 باستخدام مدخل Azure أو واجهة برمجة تطبيقات REST. بالإضافة إلى ذلك، يمكنك إنشاء ما يصل إلى 30 نُسخة متماثلة مُسماة للعديد من سيناريوهات توسيع نطاق القراءة.

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

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

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

100 تيرابايت.

إن سجل العمليات في Hyperscale لا نهائي عملياً، مع تقييد أن معاملة واحدة لا يمكن أن تولد أكثر من 1 تيرابايت من السجل. بالإضافة إلى ذلك، في حالة استخدام Change Data Capture، يمكن إنشاء 1 تيرابايت على الأكثر من السجل منذ بداية أقدم معاملة نشطة. يوصى بتجنب العمليات الكبيرة غير الضرورية للبقاء أقل من هذا الحد. بخلاف القيود المذكورة، لا داعي للقلق بشأن نفاد مساحة السجل على نظام يحتوي على معدل نقل عالٍ للسجل. ومع ذلك، قد يتم تقييد معدل إنشاء السجلات لكتابة أحمال العمل بقوة باستمرار. المعدل الأقصى لإنشاء السجلات هو 100 ميغابايت/ثانية.

تقع قاعدة بياناتك tempdb على موقع تخزين SSD المحلي ويتم تحديد حجمها بالتناسب مع حجم الحساب (عدد الأنوية) الذي توفره. حجم tempdb غير قابل للتكوين ويتم إدارته من أجلك. لتحديد حجم tempdb الأقصى لقاعدة بياناتك، راجع موقع تخزين Hyperscale واحجام الحساب.

يزداد حجم قاعدة بياناتك تلقائيًا مع إدراج/استيعاب المزيد من البيانات.

⁧40 غيغابايت. يتم إنشاء قاعدة بيانات Hyperscale بحجم بداية يبلغ 10 غيغابايت. ثم يبدأ النمو بمقدار 10 غيغابايت كل 10 دقائق، حتى يصل حجمه إلى 40 غيجابايت. يتم تخصيص كل مجموعة بحجم 10 غيغابايت من هذه المجموعات في خادم صفحات مختلف لتوفير IOPS أكثر وتوازي إدخال/إخراج أعلى. وبسبب هذا التحسين، حتى إذا اخترت حجم قاعدة بيانات أولي أصغر من 40 غيغابايت، سوف تزداد قاعدة البيانات إلى 40 غيغابايت على الأقل تلقائيًا.

يزداد كل ملف بيانات بمقدار 10 غيغابايت. قد تزداد ملفات البيانات المتعددة في نفس الوقت.

في Hyperscale، يتم تخزين ملفات البيانات في تخزين Azure القياسي. يتم تخزين البيانات مؤقتاً بشكل كامل على موقع تخزين SSD المحلي، على خوادم الصفحات البعيدة من النُسخ المتماثلة للحساب. بالإضافة إلى ذلك، تحتوي النسخ المتماثلة للحساب على ذاكرات تخزين مؤقت للبيانات على SSD المحلي، لتقليل تكرار إحضار البيانات من خوادم الصفحات البعيدة.

كلا. تتم إضافة ملفات البيانات تلقائياً إلى مجموعة الملفات PRIMARY. لا تنطبق الأسباب الشائعة لإنشاء مجموعات ملفات إضافية في تصميم تخزين Hyperscale أو في قاعدة بيانات Azure SQL على نطاقٍ أوسع.

كلا.

ليس في الوقت الحالي.

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

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

نعم. يمكنك نقل قواعد البيانات الموجودة في Azure SQL Database إلى Hyperscale. لإثباتات المبدأ (POCs)، نوصي بعمل نسخة من قواعد بياناتك وترحيل النسخة إلى Hyperscale.

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

احصل على نموذج تعليمة برمجية لترحيل قواعد بيانات Azure SQL الحالية إلى Hyperscale في مدخل Microsoft Azure وAzure CLI وPowerShell وTransact-SQL في ترحيل قاعدة بيانات موجودة إلى Hyperscale.

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

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

لا يمكن نقل قواعد البيانات التي تم إنشاؤها في طبقة خدمة Hyperscale إلى طبقات خدمة أخرى.

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

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

نعم. يمكنك استخدام العديد من تقنيات الترحيل الموجودة للترحيل إلى Hyperscale، بما في ذلك النسخ المتماثل للمعاملات، وأي تقنيات أخرى لنقل البيانات (النسخ المجمع، Azure Data Factory، Azure Databricks، SSIS). راجع أيضًا Azure Database Migration Service، التي تدعم العديد من سيناريوهات الترحيل.

وقت التعطل للترحيل إلى Hyperscale هو نفس وقت التعطل عند ترحيل قواعد البيانات إلى مستويات خدمة Azure SQL Database الأخرى. يمكنك استخدام النسخ المماثل للمعاملات لتقليل ترحيل وقت التعطل لقواعد البيانات التي يصل حجمها إلى بضعة تيرابايت. بالنسبة لقواعد البيانات الكبيرة جداً (أكثر من 10 تيرابايت)، يمكنك التفكير في تنفيذ عملية الترحيل باستخدام تقنيات ADF أو Spark أو غيرها من تقنيات نقل البيانات المجمعة.

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

يمكنك الحصول على بيانات قراءة تطبيق العميل من Azure Storage وتحميل حمل البيانات في قاعدة بيانات Hyperscale (تماما كما يمكنك باستخدام أي قاعدة بيانات أخرى في Azure SQL Database). Polybase غير مدعوم حالياً في Azure SQL Database. كبديل لتوفير تحميل سريع، يمكنك استخدام Azure Data Factory، أو استخدام وظيفة Spark في Azure Databricks مع موصل Spark لـ SQL. يدعم موصل Spark لـ SQL الإدراج المجمع.

من الممكن أيضًا قراءة البيانات المجمعة من متجر Azure Blob باستخدام BULK INSERT أو OPENROWSET: أمثلة على الوصول المجمع إلى البيانات في Azure Blob Storage.

الاسترداد البسيط أو نموذج التسجيل المجمع غير مدعوم في Hyperscale. نموذج الاسترداد الكامل مطلوب لتوفير قابلية وصول عالية واسترداد في نقطة زمنية. مع ذلك، يوفر تصميم سجل Hyperscale معدل استيعاب أفضل للبيانات مقارنة بمستويات خدمة Azure SQL Database الأخرى.

كلا. Hyperscale هو تصميم معالجة متعددة متماثلة (SMP) وليس معالجة متوازية على نطاق واسع (MPP) أو تصميم رئيسي متعدد. يمكنك فقط إنشاء نسخ متماثلة متعددة لتوسيع نطاق أحمال العمل للقراءة فقط.

نعم. تدعم Azure Database Migration Service العديد من سيناريوهات الترحيل.

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

نعم.

نعم، يدعم Hyperscale تكوين المنطقة المكررة في المعاينة العامة. يلزم ما لا يقل عن نسخة متماثلة ثانوية واحدة ذات قابلية وصول عالية واستخدام التخزين المتكرر في المنطقة لتمكين تكوين المتكرر في المنطقة لـ Hyperscale.

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

نعم.

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

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

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

نعم. النسخ المتماثل الجغرافي لقواعد بيانات Hyperscale في المعاينة العامة.

كلا. يختلف تنسيق التخزين لقواعد بيانات Hyperscale عن أي نسخة تم إصدارها من SQL Server، ولا يمكنك التحكم في النسخ الاحتياطية أو الوصول إليها. لإخراج بياناتك من قاعدة بيانات Hyperscale، يمكنك استخراج البيانات باستخدام أي تقنيات نقل بيانات، مثل Azure Data Factory، Azure Databricks، SSIS، وغيرها.

نعم. اعتباراً من 4 مايو 2022، يتم فرض رسوم على النسخ الاحتياطية لجميع قواعد البيانات الجديدة استناداً إلى تخزين النسخ الاحتياطي المستهلك وتكرار التخزين المُحدد بأسعار تم تسجيلها في صفحة تسعير Azure SQL Database. بالنسبة لقواعد بيانات Hyperscale التي تم إنشاؤها قبل 4 مايو 2022، سيتم فرض رسوم على النسخ الاحتياطية فقط إذا تم تعيين فترة استبقاء النُسخة الاحتياطية لتكون أكبر من 7 أيام. لمعرفة المزيد، راجع النسخ الاحتياطية وتكرار تخزين Hyperscale.

تُسجيل تفاصيل بشأن كيفية قياس حجم تخزين النسخ الاحتياطي في النُسخ الاحتياطية التلقائية.

لتحديد فاتورة تخزين النسخ الاحتياطي خاصتك، يتم حساب حجم تخزين النسخ الاحتياطي بصفةٍ دوريةٍ وضربه بمعدل تخزين النسخ الاحتياطي وعدد الساعات منذ الحساب الأخير. لتقدير فاتورة النسخ الاحتياطي لفترة زمنية، اضرب حجم تخزين النسخ الاحتياطي القابل للفوترة لكل ساعة من الفترة بمعدل تخزين النسخ الاحتياطي، وأضِف جميع المبالغ بالساعة. للاستعلام عن مقاييس Azure Monitor ذات الصلة لفواصل زمنية متعددة كل ساعة برمجياً، استخدم واجهة برمجة تطبيقات REST الخاصة بـ Azure Monitor.

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

تُسجل تفاصيل بشأن كيفية تقليل تكاليف تخزين النسخ الاحتياطي في النُسخ الاحتياطية التلقائية.

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

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

كلا. يتم فصل الحساب من طبقة التخزين. يلغي هذا تأثير أداء النسخ الاحتياطي.

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

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

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

عادة ما يستغرق توسيع نطاق الحساب وتقليصه ما يصل إلى دقيقتين بغض النظر عن حجم البيانات.

كلا. سيكون توسيع النطاق وتقليصه أثناء الاتصال.

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

المستخدم النهائي. غير تلقائية.

نعم. سيتسع حجم قاعدة بيانات tempdb وذاكرة التخزين المؤقت RBPEX على عقد الحساب تلقائيًا مع زيادة عدد الذاكرات الأساسية. للحصول على التفاصيل، راجع تخزين Hyperscale وأحجام الحساب.

كلا. النسخة المتماثلة الأساسية للحساب فقط تقبل طلبات القراءة/الكتابة. النسخ المتماثلة الثانوية للحساب تقبل فقط طلبات القراءة فقط.

يدعم Hyperscale النسخ المتماثلة عالية التوفر (HA) والنسخ المتماثلة المسماة والنسخ المتماثلة الجغرافية. راجع النسخ المتماثلة الثانوية في Hyperscale للحصول على التفاصيل.

بين 0 و4. إذا كنت تريد ضبط عدد النسخ المتماثلة، يمكنك القيام بذلك باستخدام مدخل Azure أو واجهة برمجة تطبيقات REST.

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

يمكنك تنفيذ استعلام T-SQL التالي: SELECT DATABASEPROPERTYEX ('<database_name>', 'Updateability'). والنتيجة هي READ_ONLY إذا كنت متصلاً بنسخة متماثلة ثانوية للقراءة فقط، وREAD_WRITE إذا كنت متصلاً بالنسخة المتماثلة الأساسية. لاحظ أنه يجب تعيين سياق قاعدة البيانات إلى اسم قاعدة بياناتك، وليس إلى قاعدة البيانات master.

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

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

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

كلا. يتم تكوين قاعدة بيانات tempdb خاصتك استناداً إلى حجم الحساب المُقدَّم، تكون النسخ المتماثلة الثانوية ذات قابلية الوصول العالية بنفس الحجم، بما في ذلك tempdb، كالحساب الأساسي. على النسخ المتماثلة المسماة، يتم تحجيم tempdb وفقًا لحجم حساب النسخة المتماثلة، وبالتالي يمكن أن يكون أصغر أو أكبر من tempdb على الأساسي.

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

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

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

لمزيد من المعلومات حول مستوى خدمة Hyperscale، راجع مستوى خدمة Hyperscale.