प्रतिबद्ध स्नैपशॉट अलगाव पढ़ें के तहत डेटा संशोधन

इस श्रृंखला की पिछली पोस्ट में दिखाया गया है कि कैसे एक T-SQL स्टेटमेंट रीड कमिटेड स्नैपशॉट आइसोलेशन के तहत चल रहा है (RCSI) ) आमतौर पर डेटाबेस की प्रतिबद्ध स्थिति का एक स्नैपशॉट दृश्य देखता है जैसा कि उस समय था जब स्टेटमेंट का निष्पादन शुरू हुआ था। यह इस बात का अच्छा विवरण है कि डेटा पढ़ने वाले कथनों के लिए चीजें कैसे काम करती हैं, लेकिन महत्वपूर्ण अंतर हैं RCSI के अंतर्गत चल रहे कथनों के लिए जो मौजूदा पंक्तियों को संशोधित करें ।

मैं मौजूदा पंक्तियों में संशोधन पर ज़ोर देता हूं ऊपर, क्योंकि निम्नलिखित विचार केवल UPDATE पर लागू होते हैं और DELETE संचालन (और MERGE . की संगत कार्रवाइयां) बयान)। स्पष्ट होने के लिए, INSERT कथन विशेष रूप से बहिष्कृत . हैं मैं जिस व्यवहार का वर्णन करने जा रहा हूं, उसके अनुसार क्योंकि इंसर्ट मौजूदा को संशोधित नहीं करते हैं डेटा।

ताला और पंक्ति संस्करण अपडेट करें

पहला अंतर यह है कि स्टेटमेंट अपडेट और डिलीट करें पंक्ति संस्करण न पढ़ें संशोधित करने के लिए स्रोत पंक्तियों की खोज करते समय RCSI के अंतर्गत। RCSI के तहत विवरण अपडेट करें और हटाएं इसके बजाय अपडेट लॉक करें . प्राप्त करें योग्यता पंक्तियों की खोज करते समय। अपडेट लॉक का उपयोग करना सुनिश्चित करता है कि खोज ऑपरेशन सबसे हाल ही में प्रतिबद्ध डेटा . का उपयोग करके संशोधित करने के लिए पंक्तियों को ढूंढता है ।

अपडेट लॉक के बिना, खोज डेटा सेट के संभावित रूप से पुराने संस्करण पर आधारित होगी (प्रतिबद्ध डेटा जैसा कि डेटा संशोधन विवरण शुरू होने पर था)। यह आपको पिछली बार देखे गए ट्रिगर उदाहरण की याद दिला सकता है, जहां एक READCOMMITTEDLOCK आरसीएसआई से रीड कमिटेड आइसोलेशन के लॉकिंग कार्यान्वयन के लिए संकेत का उपयोग किया गया था। उस उदाहरण में उस संकेत की आवश्यकता थी ताकि पुरानी जानकारी पर एक महत्वपूर्ण कार्रवाई को आधार न बनाया जा सके। यहां भी इसी तरह के तर्क का इस्तेमाल किया जा रहा है। एक अंतर यह है कि READCOMMITTEDLOCK संकेत अद्यतन ताले के बजाय साझा ताले प्राप्त करता है। इसके अलावा, SQL सर्वर हमें स्पष्ट संकेत जोड़ने की आवश्यकता के बिना RCSI के तहत डेटा संशोधनों की सुरक्षा के लिए स्वचालित रूप से अपडेट लॉक प्राप्त करता है।

अपडेट लॉक लेने से यह भी सुनिश्चित होता है कि अपडेट या डिलीट स्टेटमेंट ब्लॉक . होगा अगर यह एक असंगत लॉक का सामना करता है, उदाहरण के लिए एक अन्य समवर्ती लेनदेन द्वारा किए गए इन-फ्लाइट डेटा संशोधन की रक्षा करने वाला एक विशेष लॉक।

एक अतिरिक्त जटिलता यह है कि संशोधित व्यवहार केवल लागू होता है तालिका में लक्ष्य . है अपडेट या डिलीट ऑपरेशन का। अन्य टेबल उसी . में अतिरिक्त संदर्भों . सहित, हटाएं या विवरण अपडेट करें लक्ष्य तालिका में, पंक्ति संस्करणों का उपयोग जारी रखें ।

इन भ्रामक व्यवहारों को थोड़ा स्पष्ट करने के लिए शायद कुछ उदाहरणों की आवश्यकता है…

परीक्षण सेटअप

निम्न स्क्रिप्ट सुनिश्चित करती है कि हम RCSI का उपयोग करने के लिए पूरी तरह से तैयार हैं, एक साधारण तालिका बनाता है, और इसमें दो उदाहरण पंक्तियाँ जोड़ता है:

ALTER DATABASE Sandpit
SET READ_COMMITTED_SNAPSHOT ON
WITH ROLLBACK IMMEDIATE;
GO
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
GO
CREATE TABLE dbo.Test
(
    RowID integer PRIMARY KEY,
    Data integer NOT NULL
);
GO
INSERT dbo.Test
    (RowID, Data)
VALUES 
    (1, 1234),
    (2, 2345);

अगले चरण को अलग सत्र . में चलाने की आवश्यकता है . यह एक लेन-देन शुरू करता है और परीक्षण तालिका से दोनों पंक्तियों को हटा देता है (अजीब लगता है, लेकिन यह सब जल्द ही समझ में आएगा):

BEGIN TRANSACTION;
DELETE dbo.Test 
WHERE RowID IN (1, 2);

ध्यान दें कि लेन-देन जानबूझकर खुला छोड़ दिया गया है . यह दोनों पंक्तियों को हटाए जाने पर विशेष लॉक बनाए रखता है (साथ ही साथ पेज और टेबल पर सामान्य इंटेंट-एक्सक्लूसिव लॉक के साथ) क्योंकि नीचे दी गई क्वेरी को दिखाने के लिए इस्तेमाल किया जा सकता है:

SELECT
    resource_type,
    resource_description,
    resource_associated_entity_id,
    request_mode,
    request_status
FROM sys.dm_tran_locks
WHERE 
    request_session_id = @@SPID;

चुनें टेस्ट

मूल सत्र पर वापस जाना , पहली चीज जो मैं दिखाना चाहता हूं वह यह है कि आरसीएसआई का उपयोग करने वाले नियमित चयन कथन अभी भी दो पंक्तियों को हटाते हुए देखते हैं। नीचे दी गई चुनिंदा क्वेरी, स्टेटमेंट के शुरू होने के समय नवीनतम प्रतिबद्ध डेटा वापस करने के लिए पंक्ति संस्करणों का उपयोग करती है:

SELECT *
FROM dbo.Test;

यदि यह आश्चर्यजनक लगता है, तो याद रखें कि पंक्तियों को हटाए गए के रूप में दिखाने का अर्थ डेटा का एक अप्रतिबद्ध दृश्य प्रदर्शित करना होगा, जिसे पढ़ने के लिए प्रतिबद्ध अलगाव में अनुमति नहीं है।

डिलीट टेस्ट

चयनित परीक्षण की सफलता के बावजूद, हटाने . का प्रयास वर्तमान सत्र से इन्हीं पंक्तियों को अवरुद्ध कर दिया जाएगा। आप सोच सकते हैं कि यह अवरोध तब होता है जब ऑपरेशन अनन्य . प्राप्त करने का प्रयास करता है ताले, लेकिन ऐसा नहीं है।

हटाएं पंक्ति संस्करण का उपयोग नहीं करता हटाने के लिए पंक्तियों का पता लगाने के लिए; यह इसके बजाय अद्यतन ताले हासिल करने का प्रयास करता है। अपडेट लॉक खुले लेनदेन के साथ सत्र द्वारा आयोजित अनन्य पंक्ति लॉक के साथ असंगत हैं, इसलिए क्वेरी ब्लॉक:

DELETE dbo.Test 
WHERE RowID IN (1, 2);

इस कथन के लिए अनुमानित क्वेरी योजना दर्शाती है कि हटाए जाने वाली पंक्तियों को एक अलग ऑपरेटर द्वारा वास्तविक विलोपन करने से पहले एक नियमित खोज ऑपरेशन द्वारा पहचाना जाता है:

हम पहले की तरह (दूसरे सत्र से) उसी लॉकिंग क्वेरी को चलाकर इस स्तर पर रखे गए ताले को देख सकते हैं कि अवरुद्ध क्वेरी द्वारा उपयोग किए गए SPID संदर्भ को बदलना याद है। परिणाम इस तरह दिखते हैं:

हमारी डिलीट क्वेरी को क्लस्टर्ड इंडेक्स सीक ऑपरेटर पर ब्लॉक कर दिया गया है, जो पढ़ने के लिए अपडेट लॉक प्राप्त करने की प्रतीक्षा कर रहा है। जानकारी। इससे पता चलता है कि आरसीएसआई के तहत हटाने के लिए पंक्तियों का पता लगाने से संभावित-बासी संस्करण वाले डेटा को पढ़ने के बजाय अपडेट लॉक प्राप्त होते हैं। इससे यह भी पता चलता है कि अवरोधन ऑपरेशन के हटाए गए हिस्से के कारण नहीं है जो एक विशेष लॉक प्राप्त करने की प्रतीक्षा कर रहा है।

अपडेट टेस्ट

अवरोधित क्वेरी को रद्द करें और इसके बजाय निम्न अद्यतन का प्रयास करें:

UPDATE dbo.Test
SET Data = Data + 1000
WHERE RowID IN (1, 2);

अनुमानित निष्पादन योजना डिलीट टेस्ट में देखी गई योजना के समान है:

कंप्यूट स्केलर प्रत्येक पंक्ति में डेटा कॉलम के वर्तमान मूल्य में 1000 जोड़ने के परिणाम को निर्धारित करने के लिए है, जिसे क्लस्टर इंडेक्स सीक द्वारा पढ़ा जाता है। यह कथन अवरुद्ध . भी करेगा रीड ऑपरेशन द्वारा अनुरोधित अपडेट लॉक के कारण निष्पादित होने पर। नीचे दिया गया स्क्रीनशॉट क्वेरी ब्लॉक होने पर रुके हुए लॉक को दिखाता है:

पहले की तरह, क्वेरी को खोज पर अवरुद्ध कर दिया गया है, असंगत अनन्य लॉक जारी होने की प्रतीक्षा कर रहा है ताकि अपडेट लॉक प्राप्त किया जा सके।

द इंसर्ट टेस्ट

अगले परीक्षण में एक कथन होता है जो डेटा कॉलम मान मौजूदा पंक्ति से का उपयोग करके हमारी परीक्षण तालिका में एक नई पंक्ति सम्मिलित करता है। तालिका में आईडी 1 के साथ। याद रखें कि यह पंक्ति अभी भी खुले लेनदेन के साथ सत्र द्वारा विशेष रूप से बंद है:

INSERT dbo.Test
    (RowID, Data)
SELECT 3, Data
FROM dbo.Test
WHERE RowID = 1;

निष्पादन योजना फिर से पिछले परीक्षणों के समान है:

इस बार, क्वेरी अवरुद्ध नहीं है . इससे पता चलता है कि पढ़ने . के दौरान अपडेट लॉक प्राप्त नहीं किए गए थे डालने के लिए डेटा। इसके बजाय इस क्वेरी ने नई-सम्मिलित पंक्ति के लिए डेटा कॉलम मान प्राप्त करने के लिए पंक्ति-संस्करण का उपयोग किया। अपडेट लॉक हासिल नहीं किए गए थे क्योंकि इस कथन में संशोधित . के लिए कोई पंक्ति नहीं मिली थी , यह केवल डालने में उपयोग करने के लिए डेटा पढ़ता है।

हम इस नई पंक्ति को पहले से चयनित परीक्षण क्वेरी का उपयोग करके तालिका में देख सकते हैं:

ध्यान दें कि हम हैं नई पंक्ति को अपडेट करने और हटाने में सक्षम (जिसमें अपडेट लॉक की आवश्यकता होगी) क्योंकि कोई परस्पर विरोधी अनन्य लॉक नहीं है। खुले लेन-देन वाले सत्र में केवल 1 और 2 पंक्तियों पर अनन्य ताले होते हैं:

-- Update the new row
UPDATE dbo.Test
SET Data = 9999
WHERE RowID = 3;
-- Show the data
SELECT * FROM dbo.Test;
-- Delete the new row
DELETE dbo.Test
WHERE RowID = 3;

यह परीक्षण पुष्टि करता है कि सम्मिलित विवरण पढ़ते समय अपडेट लॉक प्राप्त नहीं करते हैं , क्योंकि अपडेट और डिलीट के विपरीत वे संशोधित . नहीं करते हैं एक मौजूदा पंक्ति। एक सम्मिलित करें . का पठन भाग कथन सामान्य RCSI पंक्ति संस्करण व्यवहार का उपयोग करता है।

एकाधिक संदर्भ परीक्षण

मैंने पहले उल्लेख किया था कि अद्यतन ताले को संशोधित करने के लिए पंक्तियों का पता लगाने के लिए केवल एकल तालिका संदर्भ का उपयोग किया जाता है; एक ही अपडेट या डिलीट स्टेटमेंट में अन्य टेबल अभी भी पंक्ति संस्करण पढ़ते हैं। उस सामान्य सिद्धांत के विशेष मामले के रूप में, एक ही तालिका . के एकाधिक संदर्भों वाला डेटा संशोधन कथन केवल एक उदाहरण . पर अपडेट लॉक लागू करता है संशोधित करने के लिए पंक्तियों का पता लगाने के लिए उपयोग किया जाता है। यह अंतिम परीक्षण चरण दर चरण इस अधिक जटिल व्यवहार को दिखाता है।

पहली चीज़ जो हमें चाहिए होगी वह है हमारी टेस्ट टेबल के लिए एक नई तीसरी पंक्ति, इस बार डेटा कॉलम में शून्य के साथ:

INSERT dbo.Test
    (RowID, Data)
VALUES
    (3, 0);

जैसा कि अपेक्षित था, यह सम्मिलन अवरुद्ध किए बिना आगे बढ़ता है, जिसके परिणामस्वरूप एक तालिका इस तरह दिखती है:

याद रखें, दूसरे सत्र में अभी भी अनन्य है इस बिंदु पर पंक्तियों 1 और 2 पर ताले। यदि आवश्यक हो तो हम पंक्ति 3 पर ताले प्राप्त करने के लिए स्वतंत्र हैं। निम्न क्वेरी वह है जिसका उपयोग हम लक्ष्य तालिका के कई संदर्भों के साथ व्यवहार दिखाने के लिए करेंगे:

-- Multi-reference update test
UPDATE WriteRef
SET Data = ReadRef.Data * 2
OUTPUT 
    ReadRef.RowID, 
    ReadRef.Data,
    INSERTED.RowID AS UpdatedRowID,
    INSERTED.Data AS NewDataValue
FROM dbo.Test AS ReadRef
JOIN dbo.Test AS WriteRef
    ON WriteRef.RowID = ReadRef.RowID + 2
WHERE 
    ReadRef.RowID = 1;

यह एक अधिक जटिल प्रश्न है, लेकिन इसका संचालन अपेक्षाकृत सरल है। परीक्षण तालिका के दो संदर्भ हैं, एक जिसे मैंने ReadRef के रूप में अलियास किया है, और दूसरा WriteRef के रूप में। विचार यह है कि पढ़ें पंक्ति 1 से (पंक्ति संस्करण का उपयोग करके) ReadRef के माध्यम से, और अपडेट . के लिए WriteRef का उपयोग करके तीसरी पंक्ति (जिसे अपडेट लॉक की आवश्यकता होगी)।

क्वेरी पठन तालिका संदर्भ के लिए जहां क्लॉज में स्पष्ट रूप से पंक्ति 1 निर्दिष्ट करती है। यह उसी तालिका . के लेखन संदर्भ से जुड़ता है उस पंक्ति में 2 जोड़कर (इसलिए पंक्ति 3 की पहचान करना)। अद्यतन विवरण स्रोत तालिका से पढ़े गए मानों और पंक्ति 3 में किए गए परिणामी परिवर्तनों को दिखाते हुए परिणाम सेट को वापस करने के लिए आउटपुट क्लॉज का भी उपयोग करता है।

इस कथन के लिए अनुमानित क्वेरी योजना इस प्रकार है:

(1) . लेबल किए गए खोज के गुण दिखाएँ कि यह खोज ReadRef . पर है उपनाम, RowID 1 के साथ पंक्ति से डेटा पढ़ना:

यह सीक ऑपरेशन एक पंक्ति का पता नहीं लगाता है जिसे अपडेट किया जाएगा, इसलिए अपडेट लॉक नहीं . हैं लिया; पठन संस्करणित डेटा का उपयोग करके किया जाता है। अन्य सत्र द्वारा आयोजित अनन्य तालों द्वारा पठन अवरुद्ध नहीं है।

(2) labeled लेबल वाला कंप्यूट स्केलर 1004 लेबल वाले व्यंजक को परिभाषित करता है जो अद्यतन डेटा स्तंभ मान की गणना करता है। एक्सप्रेशन 1009 अपडेट की जाने वाली पंक्ति आईडी की गणना करता है (1 + 2 =पंक्ति आईडी 3):

दूसरी खोज उसी तालिका का संदर्भ है (3)। यह खोज उस पंक्ति का पता लगाता है जिसे अद्यतन किया जाएगा (पंक्ति 3) अभिव्यक्ति 1009 का उपयोग करके:

क्योंकि यह खोज बदलने के लिए एक पंक्ति का पता लगाता है, एक अपडेट लॉक पंक्ति संस्करणों का उपयोग करने के बजाय लिया जाता है। पंक्ति आईडी 3 पर कोई परस्पर विरोधी अनन्य लॉक नहीं है, इसलिए लॉक अनुरोध तुरंत प्रदान किया जाता है।

अंतिम हाइलाइट किया गया ऑपरेटर (4) अपडेट ऑपरेशन ही है। पंक्ति 3 पर अपडेट लॉक को अनन्य . में अपग्रेड कर दिया गया है इस बिंदु पर, वास्तव में संशोधन किए जाने से ठीक पहले लॉक करें। यह ऑपरेटर आउटपुट क्लॉज . में निर्दिष्ट डेटा भी लौटाता है अद्यतन विवरण का:

अद्यतन विवरण का परिणाम (आउटपुट क्लॉज द्वारा उत्पन्न) नीचे दिखाया गया है:

तालिका की अंतिम स्थिति नीचे दर्शाई गई है:

हम एक प्रोफाइलर ट्रेस का उपयोग करके निष्पादन के दौरान लिए गए तालों की पुष्टि कर सकते हैं:

यह दर्शाता है कि केवल एक अपडेट पंक्ति कुंजी लॉक का अधिग्रहण किया जाता है। जब यह पंक्ति अपडेट ऑपरेटर तक पहुंच जाती है, तो लॉक को अनन्य . में बदल दिया जाता है ताला। बयान के अंत में, ताला जारी किया जाता है।

आप ट्रेस आउटपुट से देख सकते हैं कि अपडेट-लॉक की गई पंक्ति के लिए लॉक हैश मान (98ec012aa510) है मेरे परीक्षण डेटाबेस में। निम्न क्वेरी से पता चलता है कि यह लॉक हैश वास्तव में क्लस्टर इंडेक्स में RowID 3 से जुड़ा है:

SELECT RowID, %%LockRes%%
FROM dbo.Test;

ध्यान दें कि यदि हम एक UPDLOCK निर्दिष्ट करते हैं, तो इन उदाहरणों में लिए गए अपडेट लॉक, लिए गए अपडेट लॉक की तुलना में कम अवधि के होते हैं संकेत देना। ये आंतरिक अपडेट लॉक स्टेटमेंट के अंत में जारी किए जाते हैं, जबकि UPDLOCK लेन-देन के अंत तक ताले लगाए जाते हैं।

यह उन मामलों के प्रदर्शन को समाप्त करता है जहां आरसीएसआई पंक्ति संस्करण का उपयोग करने के बजाय वर्तमान प्रतिबद्ध डेटा को पढ़ने के लिए अद्यतन लॉक प्राप्त करता है।

RCSI के अंतर्गत साझा और की-रेंज लॉक

ऐसे कई अन्य परिदृश्य हैं जहां डेटाबेस इंजन अभी भी आरसीएसआई के तहत लॉक प्राप्त कर सकता है। ये सभी स्थितियां उस शुद्धता को बनाए रखने की आवश्यकता से संबंधित हैं जो संभावित रूप से पुराने संस्करण वाले डेटा पर भरोसा करने से खतरे में पड़ सकती हैं।

विदेशी कुंजी सत्यापन के लिए लिए गए साझा ताले

एक सीधे विदेशी कुंजी संबंध में दो तालिकाओं के लिए, डेटाबेस इंजन को यह सुनिश्चित करने के लिए कदम उठाने की जरूरत है कि संभावित-बासी संस्करण वाले पठन पर भरोसा करके बाधाओं का उल्लंघन नहीं किया जाता है। वर्तमान कार्यान्वयन लॉकिंग रीड कमिटेड . पर स्विच करके ऐसा करता है स्वचालित विदेशी कुंजी जांच के भाग के रूप में डेटा एक्सेस करते समय।

साझा ताले लेना सुनिश्चित करता है कि अखंडता जांच नवीनतम प्रतिबद्ध डेटा (पुराना संस्करण नहीं) पढ़ता है, या समवर्ती इन-फ्लाइट संशोधन के कारण ब्लॉक करता है। रीड कमिटेड लॉक करने के लिए स्विच केवल विदेशी कुंजी डेटा की जांच के लिए उपयोग की जाने वाली विशेष एक्सेस विधि पर लागू होता है; उसी कथन में अन्य डेटा एक्सेस पंक्ति संस्करणों का उपयोग करना जारी रखता है।

यह व्यवहार केवल उन बयानों पर लागू होता है जो डेटा बदलते हैं, जहां परिवर्तन सीधे विदेशी कुंजी संबंध को प्रभावित करता है। संदर्भित (पैरेंट) तालिका में संशोधन के लिए, इसका अर्थ है ऐसे अपडेट जो संदर्भित मान को प्रभावित करते हैं (जब तक कि इसे NULL पर सेट नहीं किया जाता है) ) और सभी विलोपन। रेफरेंसिंग (चाइल्ड) टेबल के लिए, इसका मतलब है कि सभी इंसर्ट और अपडेट (फिर से, जब तक कि मुख्य संदर्भ NULL न हो। ) MERGE . के घटक प्रभावों पर भी यही विचार लागू होते हैं ।

एक विदेशी कुंजी लुकअप दिखाते हुए एक उदाहरण निष्पादन योजना जो साझा ताले लेता है, नीचे दिखाया गया है:

विदेशी कुंजियों को कैस्केडिंग करने के लिए सीरियल करने योग्य

जहां विदेशी कुंजी संबंध में एक व्यापक कार्रवाई होती है, शुद्धता के लिए क्रमबद्ध अलगाव शब्दार्थ के लिए एक स्थानीय वृद्धि की आवश्यकता होती है। इसका मतलब है कि आप एक कैस्केडिंग रेफ़रेंशियल कार्रवाई के लिए की-रेंज के ताले देखेंगे। जैसा कि पहले देखे गए अपडेट लॉक के मामले में था, ये की-रेंज लॉक स्टेटमेंट के दायरे में हैं, लेन-देन के लिए नहीं। एक उदाहरण निष्पादन योजना दिखा रही है कि आरसीएसआई के तहत आंतरिक क्रमिक ताले कहाँ लिए गए हैं, नीचे दिखाया गया है:

अन्य परिदृश्य

ऐसे कई अन्य विशिष्ट मामले हैं जहां इंजन स्वचालित रूप से ताले के जीवनकाल का विस्तार करता है, या स्थानीय रूप से शुद्धता सुनिश्चित करने के लिए अलगाव स्तर को बढ़ाता है। इनमें संबंधित अनुक्रमित दृश्य को बनाए रखते समय या IGNORE_DUP_KEY वाले इंडेक्स को बनाए रखने के दौरान उपयोग किए जाने वाले क्रमिक शब्दार्थ शामिल हैं विकल्प सेट।

मुख्य संदेश यह है कि आरसीएसआई लॉकिंग की मात्रा को कम करता है, लेकिन इसे हमेशा पूरी तरह से समाप्त नहीं कर सकता।

अगली बार

इस श्रृंखला की अगली पोस्ट स्नैपशॉट अलगाव स्तर को देखती है।