رفع خطای 3930 SQL Server: مدیریت و حل مشکلات تراکنش‌های Snapshot Isolation

خطای 3930 در SQL Server یکی از چالش‌های رایج در محیط‌های پایگاه داده با همزمانی بالا است که به طور خاص با تراکنش‌های تحت سطح ایزولیشن Snapshot (Snapshot Isolation) سروکار دارد. این خطا با پیغام “Snapshot isolation transaction failed – Conflicting update / transaction error” ظاهر می‌شود و نشان‌دهنده یک تضاد در به‌روزرسانی (Conflicting update) یا یک خطای تراکنش (transaction error) در حین عملیات پایگاه داده است. درک این خطا برای توسعه‌دهندگان و مدیران پایگاه داده (DBA) که از مزایای ایزولیشن Snapshot برای بهبود عملکرد خواندن و کاهش قفل‌گذاری استفاده می‌کنند، حیاتی است. این خطا به طور معمول زمانی رخ می‌دهد که یک تراکنش با ایزولیشن Snapshot تلاش می‌کند تا داده‌ای را تغییر دهد (به‌روزرسانی یا حذف کند)، اما متوجه می‌شود که همان داده از زمان شروع تراکنش Snapshot توسط یک تراکنش دیگر تغییر یافته و Commit شده است. این سازوکار به SQL Server اجازه می‌دهد تا یکپارچگی داده‌ها را حتی در محیط‌های با همزمانی بالا حفظ کند، اما در عین حال نیاز به رویکردهای خاصی برای حل تضادها دارد.

ایزولیشن Snapshot یک راهکار همزمانی (Concurrency Control) در SQL Server است که به تراکنش‌ها اجازه می‌دهد یک نمای سازگار (Consistent View) از پایگاه داده را ببینند، حتی اگر داده‌ها توسط تراکنش‌های دیگر در حال تغییر باشند. این رویکرد به جای قفل‌گذاری (Locking) برای خواندن داده‌ها، از نسخه‌سازی سطر (Row Versioning) استفاده می‌کند. یعنی وقتی یک تراکنش، داده‌ای را تغییر می‌دهد، SQL Server یک کپی از نسخه قبلی آن سطر را در پایگاه داده موقت (tempdb) ذخیره می‌کند. تراکنش‌های خواندنی که در حالت Snapshot اجرا می‌شوند، به این نسخه‌های قدیمی‌تر دسترسی پیدا می‌کنند و نیازی به انتظار برای آزاد شدن قفل‌ها ندارند. این امر به شدت به کاهش قفل‌گذاری و بهبود عملکرد خواندن کمک می‌کند. با این حال، وقتی یک تراکنش Snapshot اقدام به نوشتن (UPDATE یا DELETE) می‌کند، باید از یکپارچگی داده‌ها اطمینان حاصل کند. اینجاست که خطای 3930 مطرح می‌شود، زیرا سیستم متوجه تضادی بین نسخه داده‌ای که تراکنش Snapshot می‌بیند و نسخه فعلی Commit شده در پایگاه داده می‌شود.

شرح علت ارور 3930 در SQL Server

علت اصلی خطای 3930 به نحوه کارکرد ایزولیشن Snapshot برای عملیات نوشتن بازمی‌گردد. در حالی که برای عملیات خواندن، ایزولیشن Snapshot به یک تراکنش اجازه می‌دهد تا نمای ثابتی از داده‌ها را در زمان شروع تراکنش مشاهده کند، این قضیه برای عملیات نوشتن (UPDATE, DELETE) متفاوت است. وقتی یک تراکنش که با سطح ایزولیشن SNAPSHOT اجرا می‌شود، سعی می‌کند یک سطر را به‌روزرسانی یا حذف کند، SQL Server دو مرحله اصلی را برای بررسی تضاد انجام می‌دهد:

بررسی تغییرات سطر (Row Modification Check): سیستم بررسی می‌کند که آیا سطر مورد نظر برای به‌روزرسانی/حذف، از زمان شروع تراکنش Snapshot، توسط یک تراکنش دیگر Commit شده و تغییر یافته است یا خیر.
مقایسه شناسه نسخه سطر (Row Version ID Comparison): هر سطر در SQL Server دارای یک شناسه نسخه داخلی است که هنگام تغییر سطر، به‌روزرسانی می‌شود. تراکنش Snapshot شناسه نسخه سطر را در زمان شروع خود ثبت می‌کند. وقتی یک عملیات نوشتن انجام می‌شود، SQL Server شناسه نسخه فعلی سطر را با شناسه نسخه‌ای که تراکنش Snapshot در ابتدا مشاهده کرده بود، مقایسه می‌کند. اگر این شناسه‌ها متفاوت باشند، به این معنی است که سطر توسط یک تراکنش دیگر Commit شده است.

اگر SQL Server تشخیص دهد که سطر مورد نظر توسط تراکنش دیگری از زمان شروع تراکنش Snapshot شما تغییر یافته است، خطای 3930 را صادر می‌کند. این مکانیسم برای اطمینان از یکپارچگی داده‌ها و جلوگیری از از دست رفتن به‌روزرسانی‌ها (Lost Updates) حیاتی است. به عبارت دیگر، SQL Server نمی‌خواهد اجازه دهد تراکنش Snapshot شما داده‌ای را بر اساس یک نمای قدیمی تغییر دهد، در حالی که داده واقعی در پایگاه داده توسط تراکنش دیگری تغییر یافته است.

سناریوهای رایج که منجر به خطای 3930 می‌شوند:

تراکنش‌های Snapshot طولانی‌مدت: هرچه یک تراکنش Snapshot بیشتر طول بکشد، احتمال اینکه داده‌هایی که قصد به‌روزرسانی آن‌ها را دارد، توسط تراکنش‌های دیگر تغییر یابند، بیشتر می‌شود.
همزمانی بالا و به‌روزرسانی‌های مکرر: در محیط‌هایی که تعداد زیادی کاربر یا برنامه به طور همزمان سعی در به‌روزرسانی یا حذف رکوردهای مشترک دارند، احتمال وقوع این تضاد بسیار افزایش می‌یابد.
عدم وجود مکانیزم کنترل همزمانی خوش‌بینانه در برنامه: اگر برنامه‌های کاربردی به درستی مکانیزم‌های کنترل همزمانی خوش‌بینانه (Optimistic Concurrency Control) را پیاده‌سازی نکرده باشند، ممکن است بدون بررسی اینکه آیا داده‌ها از زمان بازیابی اولیه تغییر کرده‌اند یا خیر، اقدام به به‌روزرسانی کنند، که منجر به خطای 3930 می‌شود.
استفاده از SET TRANSACTION ISOLATION LEVEL SNAPSHOT برای عملیات نوشتن: این خطا به طور خاص زمانی رخ می‌دهد که شما صراحتاً سطح ایزولیشن یک تراکنش را به SNAPSHOT تنظیم کرده و سپس اقدام به عملیات UPDATE یا DELETE در آن تراکنش می‌کنید. تنظیم READ_COMMITTED_SNAPSHOT ON در سطح پایگاه داده (که بر رفتار پیش‌فرض READ COMMITTED تأثیر می‌گذارد) معمولاً منجر به این خطا نمی‌شود، زیرا تراکنش‌های READ COMMITTED برای نوشتن قفل می‌گیرند و به نسخه‌سازی سطر برای خواندن اتکا می‌کنند.

راهکار رفع خطای 3930 SQL Server: عملی و مرحله‌ای

رفع خطای 3930 اغلب نیازمند تغییراتی در منطق برنامه یا مدیریت تراکنش‌ها است. در اینجا راهکارهای عملی و مرحله‌ای برای حل این مشکل ارائه شده است:

1. درک منطق برنامه‌نویسی و رفتار تراکنش‌ها

اولین گام حیاتی، شناسایی دقیق تراکنش‌هایی است که این خطا را ایجاد می‌کنند و درک منطق کسب‌وکار پشت آن‌ها. باید بررسی کنید کدام بخش از برنامه شما اقدام به به‌روزرسانی داده‌ها تحت ایزولیشن SNAPSHOT می‌کند. این شامل تحلیل کد برنامه و بررسی لاگ‌های خطا برای یافتن الگوهای تکرارشونده است. درک اینکه چرا آن تراکنش‌ها طولانی می‌شوند یا چرا سعی در به‌روزرسانی رکوردهای مشابه دارند، می‌تواند به طراحی راهکار مناسب کمک کند.

2. پیاده‌سازی مکانیزم تلاش مجدد (Retry Logic)

یکی از رایج‌ترین و موثرترین راهکارها، پیاده‌سازی مکانیزم تلاش مجدد در سمت برنامه کاربردی است. از آنجایی که خطای 3930 اغلب یک خطای گذرا (transient error) ناشی از زمان‌بندی (timing) است، تلاش مجدد برای اجرای تراکنش پس از یک وقفه کوتاه می‌تواند مشکل را حل کند. این راهکار به خصوص زمانی مفید است که تضادها ناشی از همزمانی‌های لحظه‌ای هستند.

مثال مفهوم پیاده‌سازی در زبان‌های برنامه‌نویسی (مانند C# یا Java):


try
{
    // Begin Transaction (with SNAPSHOT isolation)
    // Perform UPDATE/DELETE operations
    // Commit Transaction
}
catch (SqlException ex) when (ex.Number == 3930)
{
    // Log the error
    // Wait for a short period (e.g., 50-200 ms)
    // Retry the entire transaction (up to a predefined number of times)
}
catch (Exception ex)
{
    // Handle other errors
}

در این مثال، برنامه سعی می‌کند تراکنش را در بلوک try اجرا کند. اگر خطای 3930 رخ دهد، آن را دریافت کرده، کمی صبر می‌کند و دوباره تلاش می‌کند. این فرآیند معمولاً برای تعداد محدودی تکرار (مثلاً 3 تا 5 بار) انجام می‌شود تا از حلقه‌های بی‌نهایت جلوگیری شود.

3. استفاده از همزمانی خوش‌بینانه (Optimistic Concurrency)

همزمانی خوش‌بینانه یک روش مدیریت تضاد است که در آن فرض می‌شود تضادها نادر هستند. در این روش، شما وضعیت اولیه داده‌ها را در زمان بازیابی، در جایی ذخیره می‌کنید و قبل از انجام به‌روزرسانی، بررسی می‌کنید که آیا داده‌ها از زمان بازیابی اولیه تغییر کرده‌اند یا خیر. این کار را می‌توان با استفاده از یک ستون ROWVERSION (که قبلاً TIMESTAMP نامیده می‌شد) یا با مقایسه مقادیر ستون‌های مهم انجام داد.

الف) استفاده از ستون ROWVERSION: یک ستون ROWVERSION به جدول خود اضافه کنید. این ستون به طور خودکار هر بار که سطر تغییر می‌کند، به‌روزرسانی می‌شود. در زمان به‌روزرسانی، ROWVERSION اصلی را به عنوان بخشی از شرط WHERE ارسال می‌کنید.

ابتدا، اطمینان حاصل کنید که جدول شما دارای یک ستون ROWVERSION است. اگر نه، می‌توانید آن را اضافه کنید:


ALTER TABLE YourTableName
ADD RowVersionColumn ROWVERSION;

سپس، در کوئری UPDATE خود، ROWVERSION اصلی را که هنگام بازیابی اطلاعات به دست آورده‌اید، لحاظ کنید:


UPDATE YourTableName
SET Column1 = @NewValue1, Column2 = @NewValue2
WHERE PrimaryKeyColumn = @Key
AND RowVersionColumn = @OriginalRowVersion;

IF @@ROWCOUNT = 0
BEGIN
    -- Conflict detected: the row was updated by another transaction
    -- OR the primary key did not exist.
    -- You can SELECT the row again to get the latest data and inform the user,
    -- or retry the operation with the latest data.
    PRINT 'Error 3930: Conflicting update detected or row not found.';
    THROW 50000, 'Conflicting update detected. Please refresh and try again.', 1;
END;

در این روش، اگر @@ROWCOUNT پس از اجرای UPDATE برابر با صفر باشد، به این معنی است که سطر با PrimaryKeyColumn و RowVersionColumn مشخص شده پیدا نشده است. این معمولاً نشان می‌دهد که سطر توسط تراکنش دیگری از زمان بازیابی شما تغییر یافته و RowVersionColumn آن تغییر کرده است. برنامه می‌تواند این وضعیت را تشخیص داده و به کاربر اطلاع دهد یا عملیات را با داده‌های جدید دوباره امتحان کند.

ب) مقایسه ستون‌های مهم: اگر نمی‌توانید از ROWVERSION استفاده کنید، می‌توانید مقادیر مهم ستون‌ها را که هنگام بازیابی اولیه داشته‌اید، در شرط WHERE قرار دهید. این روش کمتر کارآمد است اما در برخی موارد قابل استفاده است.


UPDATE YourTableName
SET Column1 = @NewValue1
WHERE PrimaryKeyColumn = @Key
AND OriginalColumn1 = @InitialColumn1Value
AND OriginalColumn2 = @InitialColumn2Value;

IF @@ROWCOUNT = 0
BEGIN
    -- Conflict detected.
    PRINT 'Error 3930: Conflicting update detected based on column values.';
    THROW 50000, 'Conflicting update detected. Please refresh and try again.', 1;
END;

این روش به خصوص در مواردی که تعداد ستون‌های مورد نیاز برای مقایسه زیاد نیست، کارآمد است. با این حال، باید تمامی ستون‌هایی را که ممکن است تغییر کرده باشند و برای یکپارچگی داده حیاتی هستند، در نظر بگیرید.

4. کوتاه‌تر کردن زمان اجرای تراکنش‌ها

تراکنش‌های طولانی‌مدت زمان بیشتری برای وقوع تضادها را فراهم می‌کنند. سعی کنید منطق برنامه خود را بازبینی کنید تا تراکنش‌ها را به بخش‌های کوچک‌تر و متمرکزتر تقسیم کنید. هرچه تراکنش‌ها کوتاه‌تر باشند، پنجره زمانی برای تضادهای به‌روزرسانی کمتر می‌شود. این رویکرد به ویژه در سیستم‌هایی با حجم بالای عملیات و همزمانی گسترده، بسیار مؤثر است.

5. بررسی و تنظیم سطح ایزولیشن

در حالی که خطای 3930 مستقیماً به تراکنش‌هایی با سطح ایزولیشن SNAPSHOT مربوط می‌شود که سعی در نوشتن دارند، درک صحیح سطوح ایزولیشن و پیامدهای آن‌ها مهم است. اگرچه SNAPSHOT برای خواندن داده‌ها مزایای زیادی دارد، اما برای نوشتن نیاز به مدیریت تضادها دارد.

تنظیم سطح ایزولیشن SNAPSHOT: برای استفاده از ایزولیشن SNAPSHOT، ابتدا باید آن را در سطح پایگاه داده فعال کنید:


ALTER DATABASE YourDatabaseName
SET ALLOW_SNAPSHOT_ISOLATION ON;

این دستور امکان استفاده از سطح ایزولیشن SNAPSHOT را در تراکنش‌ها فراهم می‌کند. سپس، در هر تراکنش که می‌خواهید از این ایزولیشن استفاده کنید، باید آن را به صورت صریح تنظیم کنید:


SET TRANSACTION ISOLATION LEVEL SNAPSHOT;
BEGIN TRANSACTION;
    -- Your SELECT, UPDATE, DELETE statements here
COMMIT TRANSACTION;

اگر خطای 3930 در تراکنشی رخ می‌دهد که با این دستور SET TRANSACTION ISOLATION LEVEL SNAPSHOT شروع شده و حاوی عملیات UPDATE یا DELETE است، راهکارهای قبلی (تلاش مجدد، همزمانی خوش‌بینانه) مناسب‌تر هستند.

استفاده از READ_COMMITTED_SNAPSHOT: گاهی اوقات، سردرگمی بین SNAPSHOT و READ_COMMITTED_SNAPSHOT به وجود می‌آید. فعال کردن READ_COMMITTED_SNAPSHOT در سطح پایگاه داده، رفتار پیش‌فرض سطح ایزولیشن READ COMMITTED را تغییر می‌دهد تا برای عملیات خواندن به جای قفل‌گذاری، از نسخه‌سازی سطر استفاده کند.


ALTER DATABASE YourDatabaseName
SET READ_COMMITTED_SNAPSHOT ON;

هنگامی که READ_COMMITTED_SNAPSHOT ON باشد، تراکنش‌هایی که با READ COMMITTED اجرا می‌شوند، برای خواندن داده‌ها از نسخه‌های سطر در tempdb استفاده می‌کنند و بنابراین، قفل‌های اشتراکی (Shared Locks) را برای خواندن اعمال نمی‌کنند. اما برای عملیات نوشتن، همچنان قفل‌های انحصاری (Exclusive Locks) اعمال می‌کنند و به همین دلیل، خطای 3930 در این حالت (برای تراکنش‌های READ COMMITTED) رخ نمی‌دهد، زیرا تضادها با قفل‌گذاری مدیریت می‌شوند. اگر برنامه شما به اشتباه از SNAPSHOT برای نوشتن استفاده می‌کند در حالی که هدف اصلی فقط خواندن بدون قفل بوده، بررسی تنظیمات ایزولیشن می‌تواند کمک‌کننده باشد. اما به خاطر داشته باشید که خطای 3930 خاص تراکنش‌های SNAPSHOT است که سعی در نوشتن دارند.

6. بهینه‌سازی کوئری‌ها و ایندکس‌ها

کوئری‌های ناکارآمد که درون یک تراکنش Snapshot اجرا می‌شوند، می‌توانند زمان اجرای تراکنش را افزایش داده و احتمال وقوع تضادها را بالا ببرند. اطمینان حاصل کنید که کوئری‌های SELECT، UPDATE و DELETE شما بهینه‌سازی شده‌اند و از ایندکس‌های مناسب استفاده می‌کنند. این به SQL Server کمک می‌کند تا داده‌ها را سریع‌تر پیدا کرده و تغییر دهد، که زمان نگهداری قفل‌ها و همچنین زمان کلی تراکنش را کاهش می‌دهد.

بررسی طرح اجرایی (Execution Plan): از SHOWPLAN_ALL یا ابزارهای گرافیکی SQL Server Management Studio (SSMS) برای بررسی طرح اجرایی کوئری‌های خود استفاده کنید.
```
SET SHOWPLAN_ALL ON;
-- Your SQL Query
GO
SET SHOWPLAN_ALL OFF;
GO
        
```
اطمینان از وجود ایندکس‌های مناسب: ایندکس‌های کلیدی اصلی (Primary Key) و ایندکس‌های غیرخوشه‌ای (Non-Clustered Index) باید بر روی ستون‌هایی که در شروط WHERE و JOIN استفاده می‌شوند، وجود داشته باشند.

7. مانیتورینگ و لاگ‌برداری

مانیتورینگ فعال پایگاه داده و لاگ‌برداری دقیق می‌تواند به شناسایی الگوها و منشأ خطای 3930 کمک کند. شما باید موارد زیر را رصد کنید:

استفاده از tempdb: افزایش ناگهانی در استفاده از tempdb می‌تواند نشان‌دهنده فعالیت بالای نسخه‌سازی سطر باشد که با ایزولیشن Snapshot مرتبط است.
طول مدت تراکنش‌ها: شناسایی تراکنش‌های طولانی‌مدت به وسیله sys.dm_tran_active_snapshot_database_transactions و sys.dm_tran_version_store می‌تواند نقاط مشکل‌ساز را مشخص کند.
```
SELECT
    transaction_id,
    oldest_active_transaction_id,
    transaction_sequence_num,
    first_snapshot_sequence_num,
    is_snapshot,
    elapsed_time_seconds
FROM sys.dm_tran_active_snapshot_database_transactions;

SELECT
    version_sequence_num,
    database_id,
    transaction_id,
    record_length_bytes
FROM sys.dm_tran_version_store;
        
```
این کوئری‌ها اطلاعاتی در مورد تراکنش‌های فعال Snapshot و حجم حافظه استفاده شده در Version Store را ارائه می‌دهند که می‌تواند برای تشخیص مشکلات مفید باشد.
لاگ‌های خطا و Extended Events: SQL Server Error Log و SQL Server Extended Events می‌توانند جزئیات دقیقی در مورد زمان، تعداد و منشأ خطای 3930 ارائه دهند. با ایجاد یک سشن Extended Events برای ردیابی رویداد error_reported (با فیلتر برای error_number = 3930) می‌توانید به طور فعال این خطاها را مانیتور کنید و اطلاعات زمینه‌ای (مانند متن کوئری و شناسه فرآیند) را به دست آورید.

مدیریت خطای 3930 یک فرآیند تکراری است که نیازمند درک عمیق از منطق برنامه، الگوهای دسترسی به داده و رفتار همزمانی در SQL Server است. با اعمال راهکارهای ذکر شده و پایش مداوم، می‌توانید پایداری و عملکرد پایگاه داده خود را در محیط‌های با همزمانی بالا بهبود بخشید.

رفع خطای 3930 SQL Server: مدیریت و حل مشکلات تراکنش‌های Snapshot Isolation