SQL सर्वर में लेनदेन रोलबैक का उपयोग करना

परिचय

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

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

परिदृश्य समीक्षा

ऊपर वर्णित परिदृश्य असामान्य नहीं है। नियमित SQL सर्वर उपयोगकर्ताओं के साथ ऐसा होने के कारणों में से एक यह है कि SQL सर्वर का उपयोग करता है जिसे लागू लेनदेन कहा जाता है। अंतर्निहित लेनदेन डिफ़ॉल्ट रूप से बंद हो जाते हैं, जिसका अर्थ है कि SQL सर्वर आपसे प्रत्येक कथन के अंत में एक COMMIT TRANSACTION कथन जारी करने की अपेक्षा नहीं करता है। असल में, प्रत्येक कथन स्वचालित रूप से प्रतिबद्ध होता है। यह सुविधाजनक है और उन स्थितियों से बचने में मदद करता है जिनमें अभी तक किए जाने वाले सत्र संसाधनों को लॉक कर देते हैं और प्रदर्शन को प्रभावित करते हैं। ब्रेंट ओज़र IMPLICIT TRANSACTIONS =ON के प्रदर्शन निहितार्थ पर अधिक विवरण देता है।

हालांकि, इस कॉन्फ़िगरेशन (IMPLICIT TRANSACTIONS =OFF) का एक छोटा सा पहलू यह है कि उपयोगकर्ताओं के पास एक कथन पर पुनर्विचार करने और एक रोलबैक जारी करने का अवसर नहीं है जो Oracle में बहुत आम है। चित्र 1 SQL सर्वर प्रबंधन स्टूडियो में उपलब्ध ANSI क्वेरी विकल्पों को दिखाता है।

अंजीर। SQL सर्वर प्रबंधन स्टूडियो में 1 ANSI डिफ़ॉल्ट

अंतर्निहित लेनदेन का उपयोग करना

संक्षेप में, इस डिफ़ॉल्ट कॉन्फ़िगरेशन या हमारे सबसे वांछनीय क्लाइंट टूल में हमें जिस समस्या का सामना करना पड़ रहा है, वह यह है कि हम SQL स्टेटमेंट को निष्पादित करने के बाद रोलबैक नहीं कर सकते। हम अपने सत्र में IMPLICIT TRANSACTIONS को सक्षम करके इसे दरकिनार कर सकते हैं। यह हमें जरूरत पड़ने पर लेनदेन को रोलबैक करने का अवसर देगा। चित्र 2 और चित्र 4 हमें दिखाते हैं कि हम इस सेटिंग को केवल एक सत्र के लिए चालू कर सकते हैं, भले ही यह रोलबैक या COMMIT जारी नहीं होने पर उपयोगकर्ता सत्र को दूसरों को अवरुद्ध करने का जोखिम दूर नहीं करता है।

अंजीर। 2 निहित लेनदेन एक सत्र में चालू

-- Listing 1: UPDATE Table TAB2 with IMPLICIT_TRANSACTIONS ON
SET IMPLICIT_TRANSACTIONS ON

DECLARE @IMPLICIT_TRANSACTIONS VARCHAR(3) = 'OFF';  
IF ( (2 & @@OPTIONS) = 2 ) SET @IMPLICIT_TRANSACTIONS = 'ON';  
SELECT @IMPLICIT_TRANSACTIONS AS IMPLICIT_TRANSACTIONS;

USE KTrain
GO
SELECT * FROM Tab2;
GO

UPDATE TAB2
SET countryCode='SA'
-- WHERE fname='Joyce';
GO
SELECT * FROM Tab2;
GO

अंजीर। 3 सभी पंक्तियाँ अपडेट की गईं

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

याद रखें कि हमने पहले ही IMPLICIT TRANSACTION चालू कर दिया है, इसलिए जब हम इस कथन को निष्पादित करते हैं, तो SQL सर्वर हमसे लेनदेन को कमिट या रोलबैक करने की अपेक्षा करेगा। डेवलपर का इरादा जॉयस अफम के देश कोड . को अपडेट करना है 'एसए' के ​​लिए जब से वह दक्षिण अफ्रीका में आकर बस गई है। चित्र 3 हमें दिखाता है कि डेवलपर ने ऐसा करने का प्रयास करते समय गलती से सभी पंक्तियों को देश कोड मान SA के साथ अपडेट कर दिया है . वे इसे नोटिस करते हैं और रोलबैक जारी करते हैं।

अंजीर। 4 रोलबैक जारी करना

अंजीर। 5 निहित लेनदेन एक और सत्र में चालू

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

अंजीर। 6 लागू लेनदेन के बिना रोलबैक संभव नहीं है

स्पष्ट लेनदेन का उपयोग करना

उसी प्रभाव को प्राप्त करने का एक अन्य तरीका है DML को BEGIN TRAN स्पष्ट रूप से बताते हुए एक लेनदेन में संलग्न करना। फिर, लेन-देन को पूरा करना बहुत महत्वपूर्ण है - या तो COMMIT या रोलबैक का उपयोग करके। इस चर्चा के संदर्भ में, हम एक रोलबैक जारी करते हैं क्योंकि हमें पता चलता है कि कोड में कोई त्रुटि है।

-- Listing 2: UPDATE Table TAB2 with Explicit Transaction

BEGIN TRAN 
GO
USE KTrain
GO
SELECT * FROM Tab2;
GO

UPDATE TAB2
SET countryCode='GH'
-- WHERE fname='Joyce';
GO
SELECT * FROM Tab2;
GO

ROLLBACK;

SELECT * FROM Tab2;
GO

- Listing 3: Corrected UPDATE Statement

BEGIN TRAN 
GO
USE KTrain
GO
SELECT * FROM Tab2;
GO

UPDATE TAB2
SET countryCode='SA'
WHERE fname='Joyce';
GO
SELECT * FROM Tab2;
GO

निष्कर्ष

इस लेख में, हमने रोलबैक के लिए अवसर सृजित करने और इस प्रकार गलत डीएमएल से उत्पन्न उपयोगकर्ता त्रुटियों को कम करने के लिए एक अच्छे समाधान पर संक्षेप में बात की है। हमने इस दृष्टिकोण के एक प्रमुख जोखिम पर भी प्रकाश डाला है, जो अनजाने में अवरुद्ध है। एक डीबीए sys.dm_tran_session_transactions, sys.dm_tran_locks को क्वेरी करके इस जोखिम की संभावित उपस्थिति पर जांच शुरू कर सकता है। , और समान गतिशील प्रबंधन ऑब्जेक्ट।

संदर्भ

1. विलंबित पुनर्प्राप्ति के साथ लॉग शिपिंग का उपयोग करके डेटा हानि को ठीक करना

2. अंतर्निहित लेन-देन सेट करें

3. अंतर्निहित लेन-देन को गलत विचार के रूप में सेट करें

4. लेन-देन के लिए DMV