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

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

ما المتوقع

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

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

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

بمجرد تمكينها، يتم تنفيذ كافة المعاملات في قاعدة البيانات ضمن «عزل لقطة تنفيذ القراءة» ولن يُحترم إعداد لقطة عدم تنفيذ القراءة على مستوى الجلسة. تحقق من خيارات ALTER DATABASE SET (Transact-SQL) للتفاصيل.

حجم العملية

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

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

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

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

Gen2

Gen1

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

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

حالة العملية

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

وعلى سبيل المثال، في 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_ * القيم كما هو متوقع.

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

دالة Error_Line()

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

استخدام THROW وعبارة RAISERROR

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

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

التقييدات

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

• لا توجد معاملة موزعة
• لا يسمح بأي معاملات متداخلة
• لا يسمح بنقاط حفظ
• لا توجد معاملات باسم
• لا توجد معاملات محددة
• لا يوجد دعم لـ DDL مثل CREATE TABLE داخل معاملة معرفة من المستخدم

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

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