مشاركة عبر

استخدم المعاملات مع مجموعة SQL مخصصة في Azure Synapse Analytics

نصائح لتنفيذ المعاملات مع مجموعة SQL مخصصة في Azure Synapse Analytics لتطوير الحلول.

ما الذي يمكن توقعه

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

مستويات عزل المعاملات

تجمع SQL المخصص ينفذ معاملات ACID. مستوى العزل في دعم المعاملات يكون افتراضيا على READ غير ملتزم. يمكنك تغييره إلى عزل لقطة القراءة الملتزم عن طريق تفعيل خيار قاعدة البيانات READ_COMMITTED_SNAPSHOT لقاعدة بيانات المستخدم عند الاتصال بقاعدة البيانات الرئيسية.

بمجرد تفعيلها، يتم تنفيذ جميع المعاملات في هذه قاعدة البيانات تحت عزل لقطة القراءة المرتزم ولن يتم قبول تعيين READ غير ملتزم على مستوى الجلسة. تحقق من خيارات مجموعة قواعد بيانات alter (Transact-SQL) لمزيد من التفاصيل.

حجم المعاملة

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

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

في الجدول أدناه تم وضع الافتراضات التالية:

  • حدث توزيع متساو للبيانات
  • متوسط طول الصف هو 250 بايت

Gen2

DWU الحد الأقصى لكل توزيع (GB) عدد التوزيعات الحد الأقصى لحجم المعاملات (GB) # الصفوف لكل توزيع الحد الأقصى للصفوف لكل معاملة
DW100c 1 60 60 4,000,000 240,000,000
DW200c 1.5 60 90 6,000,000 360,000,000
DW300c 2.25 60 135 9,000,000 540,000,000
DW400c 3 60 180 12,000,000 720,000,000
DW500c 3.75 60 225 15,000,000 900,000,000
DW1000c 7.5 60 450 30,000,000 1,800,000,000
DW1500c 11.25 60 675 45,000,000 2,700,000,000
DW2000c 15 60 900 60,000,000 3,600,000,000
DW2500c 18.75 60 1125 75,000,000 4,500,000,000
DW3000c 22.5 60 1,350 90,000,000 5,400,000,000
DW5000c 37.5 60 2,250 150,000,000 9,000,000,000
DW6000c 45 60 2,700 180,000,000 10,800,000,000
DW7500c 56.25 60 3,375 225,000,000 13,500,000,000
DW10000c 75 60 4,500 300,000,000 18,000,000,000
DW15000c 112.5 60 6,750 450,000,000 27,000,000,000
DW30000c 225 60 13,500 900,000,000 54,000,000,000

Gen1

DWU الحد الأقصى لكل توزيع (GB) عدد التوزيعات الحد الأقصى لحجم المعاملات (GB) # الصفوف لكل توزيع الحد الأقصى للصفوف لكل معاملة
DW100 1 60 60 4,000,000 240,000,000
DW200 1.5 60 90 6,000,000 360,000,000
DW300 2.25 60 135 9,000,000 540,000,000
DW400 3 60 180 12,000,000 720,000,000
DW500 3.75 60 225 15,000,000 900,000,000
DW600 4.5 60 270 18,000,000 1,080,000,000
DW1000 7.5 60 450 30,000,000 1,800,000,000
DW1200 9 60 540 36,000,000 2,160,000,000
DW1500 11.25 60 675 45,000,000 2,700,000,000
DW2000 15 60 900 60,000,000 3,600,000,000
DW3000 22.5 60 1,350 90,000,000 5,400,000,000
DW6000 45 60 2,700 180,000,000 10,800,000,000

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

لتحسين وتقليل كمية البيانات المكتوبة على السجل، راجع مقالة أفضل ممارسات المعاملات .

التحذير

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

حالة المعاملة

تستخدم مجموعة SQL المخصصة دالة XACT_STATE() للإبلاغ عن معاملة فاشلة باستخدام القيمة -2. تعني هذه القيمة أن المعاملة فشلت وتم تمييزها للتراجع فقط.

ملحوظة

استخدام -2 من قبل دالة XACT_STATE للدلالة على معاملة فاشلة يمثل سلوكا مختلفا عن SQL Server. يستخدم SQL Server القيمة -1 لتمثيل معاملة غير قابلة للالتزام. يمكن ل SQL Server تحمل بعض الأخطاء داخل المعاملة دون الحاجة إلى تصنيفها على أنها غير قابلة للالتزام. على سبيل المثال SELECT 1/0 ، قد يسبب خطأ لكنه لا يجبر المعاملة على الدخول في حالة غير قابلة للالتزام. كما يسمح SQL Server بالقراءة في المعاملة غير القابلة للالتزام. ومع ذلك، فإن تجمع SQL المخصص لا يسمح لك بذلك. إذا حدث خطأ داخل معاملة SQL مخصصة لمجموعة SQL، فسيدخل تلقائيا الحالة -2 ولن تتمكن من إصدار أي بيانات محددة أخرى حتى يتم التراجع عن البيان. لذلك من المهم التحقق من كود تطبيقك لمعرفة ما إذا كان يستخدم XACT_STATE() لأنك قد تحتاج إلى إجراء تعديلات على الكود.

على سبيل المثال، في SQL Server قد ترى معاملة تبدو كما يلي:

SET NOCOUNT ON;
DECLARE @xact_state smallint = 0;

BEGIN TRAN
    BEGIN TRY
        DECLARE @i INT;
        SET     @i = CONVERT(INT,'ABC');
    END TRY
    BEGIN CATCH
        SET @xact_state = XACT_STATE();

        SELECT  ERROR_NUMBER()    AS ErrNumber
        ,       ERROR_SEVERITY()  AS ErrSeverity
        ,       ERROR_STATE()     AS ErrState
        ,       ERROR_PROCEDURE() AS ErrProcedure
        ,       ERROR_MESSAGE()   AS ErrMessage
        ;

        IF @@TRANCOUNT > 0
        BEGIN
            ROLLBACK TRAN;
            PRINT 'ROLLBACK';
        END

    END CATCH;

IF @@TRANCOUNT >0
BEGIN
    PRINT 'COMMIT';
    COMMIT TRAN;
END

SELECT @xact_state AS TransactionState;

الكود السابق يعطي رسالة الخطأ التالية:

الجنرال 111233، المستوى 16، الولاية 1، الخط 1 111233؛ تم إلغاء المعاملة الحالية، وتم التراجع عن أي تغييرات معلقة. السبب: لم يتم التراجع صراحة عن معاملة في حالة استرجاع فقط قبل صدور عبارة DDL أو DML أو SELECT.

لن تحصل على مخرج دوال ERROR_*.

في مجموعة SQL المخصصة، يحتاج الكود إلى تعديل طفيف:

SET NOCOUNT ON;
DECLARE @xact_state smallint = 0;

BEGIN TRAN
    BEGIN TRY
        DECLARE @i INT;
        SET     @i = CONVERT(INT,'ABC');
    END TRY
    BEGIN CATCH
        SET @xact_state = XACT_STATE();

        IF @@TRANCOUNT > 0
        BEGIN
            ROLLBACK TRAN;
            PRINT 'ROLLBACK';
        END

        SELECT  ERROR_NUMBER()    AS ErrNumber
        ,       ERROR_SEVERITY()  AS ErrSeverity
        ,       ERROR_STATE()     AS ErrState
        ,       ERROR_PROCEDURE() AS ErrProcedure
        ,       ERROR_MESSAGE()   AS ErrMessage
        ;
    END CATCH;

IF @@TRANCOUNT >0
BEGIN
    PRINT 'COMMIT';
    COMMIT TRAN;
END

SELECT @xact_state AS TransactionState;

السلوك المتوقع الآن يلاحظ. يتم إدارة الخطأ في المعاملة وتوفر دوال ERROR_* القيم كما هو متوقع.

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

دالة Error_Line()

ومن الجدير بالذكر أيضا أن مجموعة SQL المخصصة لا تنفذ أو تدعم دالة ERROR_LINE(). إذا كان لديك هذه الوظيفة في كودك، عليك إزالتها لتكون متوافقة مع مجموعة SQL المخصصة. استخدم تسميات الاستعلام في كودك بدلا من ذلك لتنفيذ الوظائف المكافئة. لمزيد من المعلومات، راجع مقال LABEL .

استخدام THROW و RAISERROR

THROW هو التطبيق الأحدث لرفع الاستثناءات في تجمع SQL المخصص، لكن RAISERROR مدعوم أيضا. هناك بعض الاختلافات التي تستحق الانتباه مع ذلك.

  • أرقام رسائل الخطأ التي يحددها المستخدم لا يمكن أن تكون في نطاق 100,000 - 150,000 ل THROW
  • رسائل خطأ RAISERROR ثابتة عند 50,000
  • استخدام sys.messages غير مدعوم

القيود

تجمع SQL المخصص لديه بعض القيود الأخرى المتعلقة بالمعاملات. وهي كما يلي:

  • لا توجد معاملات موزعة
  • لا يسمح بالمعاملات المتداخلة
  • لا يسمح بنقاط الحفظ
  • لا توجد معاملات مسماة
  • لا توجد معاملات معلمة
  • لا يوجد دعم ل DDL مثل إنشاء جدول داخل معاملة يحددها المستخدم

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

لمعرفة المزيد حول تحسين المعاملات، راجع أفضل ممارسات المعاملات. كما تتوفر أدلة إضافية لأفضل الممارسات لمجموعة SQL المخصصةومجموعة SQL بدون خادم.

  • Last updated on