SQL सर्वर में लेनदेन लॉग का महत्व

लेन-देन लॉग डेटाबेस आर्किटेक्चर का एक महत्वपूर्ण और महत्वपूर्ण घटक है। इस लेख में, हम SQL सर्वर लेनदेन लॉग, महत्व और डेटाबेस माइग्रेशन में उनकी भूमिका पर चर्चा करेंगे।

परिचय

आइए SQL सर्वर बैकअप लेने के विभिन्न विकल्पों के बारे में बात करते हैं। SQL सर्वर तीन अलग-अलग प्रकार के बैकअप का समर्थन करता है।
1. पूर्ण
2. डिफरेंशियल
3. लेन-देन-लॉग

लेन-देन-लॉग अवधारणाओं में कूदने से पहले, आइए SQL सर्वर में अन्य बुनियादी बैकअप प्रकारों पर चर्चा करें।

एक पूर्ण बैकअप हर चीज की एक प्रति है। जैसा कि नाम का तात्पर्य है, यह सब कुछ वापस कर देगा। यह सभी डेटा, डेटाबेस के प्रत्येक ऑब्जेक्ट जैसे फ़ाइल, फ़ाइल-समूह, टेबल इत्यादि का बैक अप लेगा:- एक पूर्ण बैकअप किसी अन्य प्रकार के बैकअप के लिए आधार है।

एक अंतर बैकअप डेटा का बैकअप लेगा जो पिछले पूर्ण बैकअप के बाद से बदल गया है।

तीसरा विकल्प एक ट्रांजेक्शन-लॉग बैकअप है, जो उन सभी स्टेटमेंट्स को लॉग करेगा जो हम ट्रांजेक्शन लॉग में डेटाबेस को जारी करते हैं। लेन-देन लॉग एक तंत्र है जिसे "वाल" (राइट-आगे-लॉगिंग) के रूप में जाना जाता है। यह जानकारी के हर टुकड़े को पहले ट्रांजेक्शन लॉग में और फिर डेटाबेस को लिखता है। दूसरे शब्दों में, प्रक्रिया आमतौर पर डेटाबेस को सीधे अपडेट नहीं करती है। डेटाबेस के पूर्ण पुनर्प्राप्ति मॉडल के साथ यह एकमात्र पूर्ण उपलब्ध विकल्प है। अन्य पुनर्प्राप्ति मॉडल में, डेटा या तो आंशिक होता है या लॉग में पर्याप्त डेटा नहीं होता है। उदाहरण के लिए, एक नए लेन-देन की शुरुआत (LOP_BEGIN_XACT लॉग रिकॉर्ड) को रिकॉर्ड करते समय लॉग रिकॉर्ड में लेन-देन शुरू होने का समय होगा, और LOP_COMMIT_XACT (या LOP_ABORT_XACT) लॉग रिकॉर्ड उस समय को रिकॉर्ड करेंगे जब लेन-देन किया गया था (या निरस्त)।

ऑनलाइन लेन-देन लॉग के आंतरिक भाग को खोजने के लिए, आप sys.fn_dblog फ़ंक्शन को क्वेरी कर सकते हैं।

सिस्टम फ़ंक्शन sys.fn_dblog दो पैरामीटर स्वीकार करता है, पहला, LSN प्रारंभ करें और लेन-देन का LSN समाप्त करें। डिफ़ॉल्ट रूप से, यह NULL पर सेट है। यदि यह NULL पर सेट है, तो यह लेन-देन लॉग फ़ाइल से सभी लॉग रिकॉर्ड लौटा देगा।

USE WideWorldImporters
GO
SELECT [Current LSN],
[Operation],
[Transaction Name],
[Transaction ID],
[Log Record Fixed Length],
[Log Record Length]
[Transaction SID],
[SPID],
[Begin Time],
*
FROM fn_dblog(null,null)

. से

जैसा कि हम सभी जानते हैं, लेन-देन बाइनरी प्रारूप में संग्रहीत होते हैं और यह पढ़ने योग्य प्रारूप में नहीं होते हैं। ऑफ़लाइन लेनदेन लॉग फ़ाइल को पढ़ने के लिए, आप fn_dump_dblog का उपयोग कर सकते हैं।

आइए लेन-देन लॉग फ़ाइल को देखें कि किसने fn_dump_dblog का उपयोग करके ऑब्जेक्ट को छोड़ा है।

SELECT [Current LSN], [Operation], [Transaction Name], [Transaction ID], SUSER_SNAME ([Transaction SID]) AS DBUser
FROM fn_dump_dblog (
NULL, NULL, N'DISK', 1, N'G:\BKP\AdventureWorks_2016_log.trn',
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT)
WHERE
Context IN ('LCX_NULL') AND Operation IN ('LOP_BEGIN_XACT')
AND [Transaction Name] LIKE '%DROP%'

हम डेटा पर की गई गतिविधि को खोजने के लिए लेन-देन लॉग के सक्रिय भाग को पढ़ने के लिए fn_dblog () फ़ंक्शन का उपयोग करेंगे। एक बार लेन-देन लॉग साफ़ हो जाने के बाद, आपको fn_dump_dblog() का उपयोग करके लॉग फ़ाइल से डेटा को क्वेरी करना होगा।

यह फ़ंक्शन fn_dblog () के समान ही रोसेट प्रदान करता है, लेकिन इसमें कुछ दिलचस्प कार्यक्षमता है जो इसे उपयोगी बनाती है, कुछ समस्या निवारण और पुनर्प्राप्ति परिदृश्य हैं। विशेष रूप से, यह न केवल वर्तमान डेटाबेस के लेनदेन लॉग को पढ़ सकता है, बल्कि डिस्क या टेप पर लेनदेन लॉग बैकअप भी पढ़ सकता है।

लेन-देन फ़ाइल का उपयोग करके छोड़ी गई वस्तुओं की सूची प्राप्त करने के लिए, निम्न क्वेरी चलाएँ। प्रारंभ में, डेटा को अस्थायी तालिका में डंप किया जाता है। कुछ मामलों में fun_dump_dblog() के निष्पादन में थोड़ा अधिक समय लगता है। इसलिए, डेटा को अस्थायी तालिका में कैप्चर करना बेहतर है।

लॉक इंफॉर्मेशन कॉलम से ऑब्जेक्ट आईडी प्राप्त करने के लिए, निम्न क्वेरी चलाएँ।

SELECT * INTO TEMP
FROM fn_dump_dblog (
NULL, NULL, N'DISK', 1, N'G:\BKP\AdventureWorks_2016_log.trn',
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT)
WHERE
[Transaction ID] in(
SELECT DISTINCT [Transaction ID]
FROM fn_dump_dblog (
NULL, NULL, N'DISK', 1, N'G:\BKP\AdventureWorks_2016_log.trn',
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT)
WHERE
[Transaction Name] LIKE '%DROP%')
and [Lock Information] like '%ACQUIRE_LOCK_SCH_M OBJECT%'

SELECT DISTINCT [Lock Information],PATINDEX('%: 0%', [Lock Information])+4,(PATINDEX('%:0%', [Lock Information])-PATINDEX('%: 0%', [Lock Information]))-4,
Substring([Lock Information],PATINDEX('%: 0%', [Lock Information])+4,(PATINDEX('%:0%', [Lock Information])-PATINDEX('%: 0%', [Lock Information]))-4) objectid
from temp

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

USE AdventureWorks2016;
GO
SELECT name, object_id from sys.objects
WHERE object_id = '1815677516';

अब, sys.dn_dblog, sys.fn_full_dblog का उपयोग करके एक ही लेनदेन विवरण के विभिन्न रूपों को देखते हैं। सिस्टम फ़ंक्शन fn_full_dblog केवल SQL सर्वर 2017 के साथ काम करता है।

fn_dblog का उपयोग करके शीर्ष 10 लेनदेन प्राप्त करने की क्वेरी।

SELECT TOP 10 * FROM sys.fn_dblog(null,null)

SQL सर्वर 2017 के बाद से, आप fn_full dblog का उपयोग कर सकते हैं।

SELECT TOP 10 * FROM sys.fn_full_dblog(null,null,DB_ID(),null,null,null,null,NULL)

आप sp_helptext fn_full_dblog का उपयोग करके सिस्टम फ़ंक्शन में और गहराई से जा सकते हैं।

इसके बाद, fn_full_dblog का उपयोग करके सिस्टम फ़ंक्शन का उपयोग करके बैकअप फ़ाइल को क्वेरी करें। फिर से, यह केवल SQL सर्वर 2017 के बाद से लागू होता है।

प्वाइंट-इन-टाइम पुनर्स्थापना

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

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

समय-समय पर परीक्षण को बहाल करने की प्रक्रिया को कम करना हमेशा अच्छा होता है, इसलिए सुनिश्चित करें कि प्रक्रिया सामान्य रूप से बैकअप के माध्यम से चलती है।

परिदृश्य

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

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

डेटाबेस माइग्रेशन के सर्वोत्तम अभ्यास

आइए डेटाबेस माइग्रेशन प्रबंधन के मानक अभ्यासों पर चर्चा करें।

डेटा में विसंगतियों से बचने के लिए ट्रांजेक्शनल तरीके से माइग्रेशन किया जाना चाहिए। प्रवासन प्रक्रिया के सामान्य चरण पारंपरिक रूप से निम्नलिखित हैं:

एप्लिकेशन सेवा बंद करें—यह वह जगह है जहां से डाउनटाइम शुरू होता है
लॉग बैकअप आरंभ करें, यह आपकी आवश्यकताओं पर निर्भर करता है
डेटाबेस को पुनर्प्राप्ति मोड में रखें ताकि डेटाबेस में और कोई परिवर्तन न किया जाए
लॉग फ़ाइल को स्थानांतरित करें
डेटाबेस को पुनर्स्थापित करें लेन-देन लॉग फ़ाइल(फ़ाइलें)-बशर्ते, आपने लक्ष्य पर डेटाबेस का पूर्ण बैकअप पहले ही बहाल कर दिया है और डेटाबेस को पुनर्स्थापित करने की स्थिति में छोड़ दें।
लॉगिन को क्लोन करें और अनाथ उपयोगकर्ताओं को ठीक करें
नौकरियां बनाएं
एप्लिकेशन इंस्टॉल करें
नेटवर्क कॉन्फ़िगर करें - DNS प्रविष्टियां बदलें
एप्लिकेशन सेटिंग फिर से कॉन्फ़िगर करें
आवेदन सेवा प्रारंभ करें
आवेदन का परीक्षण करें

आरंभ करना

इस लेख में, हम चर्चा करेंगे कि बहुत बड़े OLTP डेटाबेस माइग्रेशन को कैसे हैंडल किया जाए। हम उत्पादन प्रणाली की उपलब्धता में शून्य या न्यूनतम व्यवधान के साथ डेटा सुरक्षा के लिए SQL सर्वर तकनीकों और तृतीय पक्ष टूल का उपयोग करने के लिए रणनीतियों पर चर्चा करेंगे। प्रक्रिया के दौरान, डेटा खोने का हमेशा एक मौका होता है। क्या आपको लगता है कि लेनदेन का निर्बाध संचालन एक अच्छी रणनीति है? यदि "हाँ", तो आपके पसंदीदा विकल्प क्या हैं?

आइए उपलब्ध विकल्पों के बारे में गहराई से जानें:

बैकअप और पुनर्स्थापित करें
लॉगिन शिपिंग
डेटाबेस मिररिंग
तृतीय पक्ष टूल

बैकअप लें और पुनर्स्थापित करें

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

लॉगिन शिपिंग

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

प्रतिबिंबित करना

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

सारांश

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

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

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

व्यक्तिगत रूप से, मैं विभिन्न कारणों से लॉग शिपिंग को प्राथमिकता दूंगा:आप पुराने सर्वर से डेटा का पूर्ण बैकअप पहले से ही ले सकते हैं, इसे नए सर्वर पर ले जा सकते हैं, इसे पुनर्स्थापित कर सकते हैं, और फिर अवशिष्ट लेनदेन (टी-लॉग बैकअप) लागू कर सकते हैं। ) बिंदु से कटओवर के क्षण तक। प्रक्रिया वास्तव में काफी सरल है।

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