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

लेन-देन लॉग क्या है?

रिलेशनल डेटाबेस सिस्टम में एक आवश्यकता है कि लेनदेन टिकाऊ होना चाहिए। लेन-देन के ACID गुणों में यह "D" है। सिस्टम को यह सुनिश्चित करना चाहिए कि अगर अचानक दुर्घटना होती है, तो लेनदेन को फिर से चलाया जा सकता है। SQL सर्वर लेनदेन लॉग फ़ाइल . नामक एक भौतिक फ़ाइल में सभी लेन-देन को कैप्चर करके इस आवश्यकता को पूरा करता है ।

संक्षेप में, जब भी कोई लेन-देन किया जाता है, SQL सर्वर लेनदेन लॉग में उस लेन-देन द्वारा उत्पादित परिवर्तनों को रिकॉर्ड करता है। भले ही डेटा फ़ाइल में लेन-देन जारी नहीं रखा गया हो, यह लेन-देन लॉग में उपलब्ध है और अचानक दुर्घटना की स्थिति में इसे फिर से चलाया जा सकता है।

वसूली मॉडल और लेन-देन लॉग

SQL सर्वर तीन पुनर्प्राप्ति मॉडल के अंतर्गत कार्य करता है - पूर्ण, बल्क लॉग और सरल।

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

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

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

लेन-देन लॉग संरचना

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

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

लॉग किस वजह से बढ़ता है?

आइए लिस्टिंग 1 में कोड का उपयोग करके एक छोटा डेटाबेस बनाकर शुरू करें। डेटा फ़ाइल 4MB आकार की है, लॉग फ़ाइल शुरू करने के लिए 2MB है। विशेष रूप से पूर्व-आवंटन . के लोकप्रिय अभ्यास के साथ आपके उत्पादन डेटाबेस कभी भी इस आकार के नहीं होंगे . हमने ऐसे आकार केवल प्रदर्शन उद्देश्यों के लिए चुने हैं।

-- Listing 1: Create a Small Database

create database tranlogexperiment
on primary 
( name = N'tranlogexperiment', filename = N'C:\MSSQL\Data\tranlogexperiment.mdf', size = 4MB , FILEGROWTH = 1024KB )
log on
( name = N'Test1_log', filename = N'E:\MSSQL\Log\Test1_log.ldf' , size = 2MB , FILEGROWTH = 1024KB );
go

उस डेटाबेस में, हम आगे डेटा मैनिपुलेशन लैंग्वेज (डीएमएल) स्टेटमेंट्स (लिस्टिंग 2) के लिए सिंगल टेबल बनाते हैं।

-- Listing 2: Create a Table

use tranlogexperiment
go
create table txn_log (
ID int
, FName varchar(50)
, LName varchar(50)
, CountryCode char (2)
)

लिस्टिंग 3 में कोड निष्पादित करके, हम जाँचते हैं और सत्यापित करते हैं कि हमने क्या किया है।

-- Listing 3: Check Recovery Model and File Sizes
select name, recovery_model_desc, log_reuse_wait_desc from sys.databases where name='tranlogexperiment';

select DB_NAME(database_id) [Database Name]
, type_desc [Database Name]
, name [Logical file Name]
, physical_name [Physical file Name]
, size*8/1024 [File Size (MB)]
, growth*8/1024 [File Growth (MB)]
from sys.master_files where database_id=DB_ID('tranlogexperiment');

फ़ाइल आकार पर ध्यान दें कॉलम। हम INSERTs और DELETEs को 100,000 बार चलाकर ट्रांजेक्शन लॉग ग्रोथ को लागू करने के लिए आगे बढ़ते हैं (लिस्टिंग 4)।

-- Listing 4: Create a Small Table
use tranlogexperiment
go
insert into txn_log values (1, 'Kenneth','Igiri', 'NG');
delete from txn_log where ID=1;
go 100000

लिस्टिंग 4 txn_log . में एक ही पंक्ति सम्मिलित करता है तालिका बनाता है और उसी पंक्ति को हटाता है, इस क्रिया को 100,000 बार दोहराता है।

कुल मिलाकर, इस गतिविधि के कारण तालिका नहीं बढ़ती है, लेकिन लेन-देन लॉग महत्वपूर्ण रूप से बढ़ता है। जब हम लिस्टिंग 4 से DML स्टेटमेंट चलाने के बाद लिस्टिंग 3 में क्वेरी को दोहराते हैं, तो हम देखते हैं कि लेन-देन लॉग कितना बढ़ गया है:

इस गतिविधि के कारण लेन-देन लॉग 4MB से बढ़कर 40MB हो गया, भले ही डेटा फ़ाइल का आकार नहीं बदला गया हो। यह हमें स्पष्ट रूप से दिखाता है कि लेन-देन लॉग आकार का डेटा आकार से बहुत कम लेना-देना है। आकार पर प्रभाव डेटाबेस पर हो रही गतिविधि (डीएमएल) से होता है।

हम लेन-देन लॉग कैसे प्रबंधित करते हैं?

डेटाबेस व्यवस्थापक जो IaaS स्थापना के SQL सर्वर के ऑन-प्रिमाइसेस इंस्टेंस का प्रबंधन करते हैं, उन्हें नियमित रूप से लेन-देन लॉग का बैकअप लेना चाहिए। डिजास्टर रिकवरी कॉन्फिगरेशन जैसे लॉग शिपिंग या ऑलवेजऑन एजी . का होना मददगार है . ऐसे कॉन्फ़िगरेशन बैकअप स्वचालित रूप से करते हैं।

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

लिस्टिंग 6 में कोड लेन-देन लॉग के आकार को दिखाता है और इसमें हमारे पास कितनी खाली जगह है।

-- Listing 6: Change Recovery Model
USE [tranlogexperiment]
GO
SELECT DB_NAME() AS [Database Name], 
    name AS [Logical File Name], 
    type_desc,
    size/128.0 AS [Current Size (MB)],  
    size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT)/128.0 AS [Free Space (MB)]
FROM sys.database_files
WHERE type IN (0,1);

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

हम log_reuse_wait_desc . को क्वेरी कर सकते हैं sys.databases . पर कॉलम लेन-देन लॉग को सिकुड़ने से रोकने वाली किसी भी स्थिति को निर्धारित करने के लिए कैटलॉग दृश्य। ध्यान दें कि हमने लिस्टिंग 3 में इस कॉलम से पूछताछ की है।

ऐसी स्थितियां एक लंबित चेकपॉइंट, एक लंबित लॉग बैकअप, चल रहे बैकअप या पुनर्स्थापना, एक सक्रिय लंबे समय तक चलने वाला लेनदेन और डेटाबेस में इसी तरह की गतिविधियां हो सकती हैं।

-- Listing 7: Change Recovery Model
USE [tranlogexperiment]
GO
DBCC SHRINKFILE (N'Test1_log' , 0, TRUNCATEONLY)
GO

हम डेटाबेस का बैकअप लेने के लिए लिस्टिंग 8 में कोड का उपयोग करते हैं। हमारे विशेष मामले में, हमें पहले एक पूर्ण बैकअप बनाना होगा क्योंकि लॉग बैकअप हमेशा एक पूर्ण बैकअप का संदर्भ देता है। पॉइंट-इन-टाइम पुनर्प्राप्ति से निपटने के दौरान "अंतिम" पूर्ण बैकअप श्रृंखला शुरू करता है।

-- Listing 8: Backup Transaction Log
backup database tranlogexperiment to disk='tranlogexperiment.bkp';
backup log tranlogexperiment to disk='tranlogexperiment_log.trn';

सरल पुनर्प्राप्ति मोड में डेटाबेस चलाते समय, लेन-देन लॉग प्रत्येक चेकपॉइंट . पर छोटा हो जाता है . इस मोड में, लॉग बैकअप संभव नहीं है।

लेन-देन लॉग फ़ाइल का स्थान लंबे समय तक चलने वाले लेन-देन को समायोजित करने के लिए ठीक से आकार में होना चाहिए जो कभी-कभी होता है। अन्यथा, लेन-देन लॉग अभी भी डिस्क स्थान भर सकता है। चित्र 4 दिखाता है कि बैकअप लेने पर आंतरिक रूप से लॉग का क्या होता है। ध्यान दें कि भौतिक फ़ाइल अभी भी 40 एमबी है, लेकिन अब हमारे पास लगभग 37 एमबी खाली स्थान है।

साधारण पुनर्प्राप्ति मोड में क्या होता है?

अब, हम tranlogexperiment . सेट करते हैं सरल पुनर्प्राप्ति मोड के लिए डेटाबेस।

-- Listing 9: Change Recovery Model
use master
go
alter database tranlogexperiment set recovery simple;

जब हम पहले लिस्टिंग 4 में प्रस्तुत कोड को निष्पादित करते हैं, तो हमें थोड़ा अलग व्यवहार मिलेगा।

जब हम लिस्टिंग 4 में कोड निष्पादित करते हैं तो चित्र 6 सरल पुनर्प्राप्ति मोड में लेनदेन लॉग वृद्धि दिखाता है। भौतिक लॉग फ़ाइल का आकार केवल 15 एमबी है। यह पहले के फुल रिकवरी मॉडल के मुकाबले आधा कम है। साथ ही, 11.5 एमबी के खाली स्थान पर ध्यान दें।

क्या इसका मतलब यह है कि लॉग वृद्धि कम थी?

सं. चित्र 7 से पता चलता है कि जब सत्र चल रहा था, हमारे SQL सर्वर ने कई चौकियों का भी प्रदर्शन किया। इसने लॉग को छोटा कर दिया और लेन-देन के लिए अंतराल पर बढ़ते लॉग को फिर से शुरू करने के लिए जगह दी।

निष्कर्ष

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

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

संदर्भ एस

1. लेन-देन लॉग
2. SQL सर्वर डेटाबेस और संग्रहण

यह भी पढ़ें

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