SQL सर्वर लेनदेन संबंधी प्रतिकृति मुद्दे

हमने पहले SQL सर्वर ट्रांजेक्शनल प्रतिकृति मुद्दों के बारे में बात करना शुरू किया था। अब, हम कुछ और व्यावहारिक डेमो के साथ जारी रखने जा रहे हैं जो अक्सर सामना किए जाने वाले प्रतिकृति प्रदर्शन के मुद्दों को समझते हैं और उन्हें सही तरीके से कैसे हल करते हैं।

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

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

• प्रदर्शन के मुद्दे
  • प्रकाशक डेटाबेस में लंबे समय से चल रहे सक्रिय लेन-देन
  • लेखों पर थोक INSERT/अद्यतन/हटाएं कार्रवाई
  • एक ही लेन-देन में विशाल डेटा परिवर्तन
  • वितरण डेटाबेस में अवरोध
• भ्रष्टाचार से संबंधित मुद्दे
  • प्रकाशक डेटाबेस भ्रष्टाचार
  • वितरण डेटाबेस भ्रष्टाचार
  • ग्राहक डेटाबेस भ्रष्टाचार
  • MSDB डेटाबेस भ्रष्टाचार

प्रदर्शन संबंधी समस्याएं

SQL सर्वर ट्रांजेक्शनल प्रतिकृति एक जटिल वास्तुकला है जिसमें प्रकाशक डेटाबेस, वितरक (वितरण) डेटाबेस, सब्सक्राइबर डेटाबेस और SQL सर्वर एजेंट नौकरियों के रूप में निष्पादित कई प्रतिकृति एजेंट जैसे कई पैरामीटर शामिल हैं।

जैसा कि हमने अपने पिछले लेखों में इन सभी मदों पर विस्तार से चर्चा की है, हम प्रतिकृति कार्यक्षमता के लिए प्रत्येक के महत्व को जानते हैं। इन घटकों को प्रभावित करने वाली कोई भी चीज़ SQL सर्वर प्रतिकृति प्रदर्शन को प्रभावित कर सकती है।

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

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

यह मानते हुए कि प्रकाशक, सब्सक्राइबर और डिस्ट्रीब्यूटर डेटाबेस सर्वर सही तरीके से कॉन्फ़िगर किए गए हैं, नीचे दिए गए परिदृश्यों का सामना करने पर भी हमारे पास प्रतिकृति प्रदर्शन समस्याएँ हो सकती हैं।

प्रकाशक डेटाबेस में लंबे समय से चल रहे सक्रिय लेन-देन

जैसा कि नाम से संकेत मिलता है, लंबे समय तक चलने वाले सक्रिय लेनदेन से पता चलता है कि लेनदेन के दायरे में एक एप्लिकेशन कॉल या एक उपयोगकर्ता ऑपरेशन है जो लंबे समय तक निष्पादित होता है।

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

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

हम नीचे दिए गए चरणों का पालन करके लंबे समय से चल रहे सक्रिय लेनदेन परिदृश्य का परीक्षण कर सकते हैं:

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

MSRepl_Commands में उपलब्ध रिकॉर्ड की स्थिति की जांच करने के लिए हम नीचे दिए गए प्रश्नों को निष्पादित कर सकते हैं टेबल या sp_browsereplcmds . का उपयोग करके वितरण डेटाबेस में प्रक्रिया:

exec sp_browsereplcmds
GO
SELECT * FROM MSrepl_commands

अब, एक नई क्वेरी विंडो खोलें और AdventureWorks पर एक लंबे समय से चल रहे सक्रिय लेनदेन को बनाने के लिए नीचे दी गई स्क्रिप्ट को निष्पादित करें। डेटाबेस। ध्यान दें कि नीचे दी गई स्क्रिप्ट में कोई रोलबैक या कमिट ट्रांज़ेक्शन कमांड शामिल नहीं है। इसलिए, हम सलाह देते हैं कि इस प्रकार के कमांड को प्रोडक्शन डेटाबेस पर न चलाएं।

BEGIN TRANSACTION 

SET IDENTITY_INSERT Person.ContactType ON;
insert into person.ContactType (ContactTypeId, Name, ModifiedDate) values ( 22, 'Test New Position', GETDATE());
SET IDENTITY_INSERT Person.ContactType OFF;

हम सत्यापित कर सकते हैं कि यह नया रिकॉर्ड सब्सक्राइबर डेटाबेस में दोहराया नहीं गया है। उसके लिए, हम Person.ContactType पर सेलेक्ट स्टेटमेंट को निष्पादित करेंगे। सब्सक्राइबर डेटाबेस में तालिका:

आइए सत्यापित करें कि क्या उपरोक्त INSERT कमांड को लॉग रीडर एजेंट द्वारा पढ़ा गया था और वितरण डेटाबेस में लिखा गया था।

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

अब एक नई क्वेरी खोलें यह देखने के लिए कि क्या लॉग रीडर एजेंट लंबे समय से चल रहे सक्रिय लेन-देन को छोड़ने और इस अद्यतन विवरण द्वारा किए गए परिवर्तनों को पढ़ने में सक्षम था या नहीं, यह देखने के लिए विंडो और नीचे अद्यतन स्क्रिप्ट निष्पादित करें।

UPDATE AdventureWorks.dbo.AWBuildVersion
SET ModifiedDate  = GETDATE()

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

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

Person.ContactType . पर INSERT करें प्रकाशक डेटाबेस में INSERT लेनदेन किए जाने के बाद ही सब्सक्राइबर डेटाबेस में दोहराया जाएगा। प्रतिबद्ध होने से पहले, हम जल्दी से जांच सकते हैं कि लंबे समय से चल रहे सक्रिय लेनदेन की पहचान कैसे करें, इसे समझें और इसे कुशलता से संभालें।

लंबे समय से चल रहे सक्रिय लेन-देन की पहचान करें

किसी भी डेटाबेस पर किसी भी लंबे समय से चल रहे सक्रिय लेनदेन की जांच करने के लिए, एक नई क्वेरी विंडो खोलें और संबंधित डेटाबेस से कनेक्ट करें जिसे हमें जांचने की आवश्यकता है। DBCC OPENTRAN निष्पादित करें कंसोल कमांड - निष्पादन के समय डेटाबेस में खुले लेनदेन को देखने के लिए यह एक डेटाबेस कंसोल कमांड है।

USE AdventureWorks
GO
DBCC OPENTRAN

अब हम जानते हैं कि एक SPID था (सर्वर प्रक्रिया आईडी ) 69 लंबे समय से चल रहा है। आइए सत्यापित करें कि DBCC INPUTBUFFER का उपयोग करके उस लेन-देन पर कौन सा आदेश निष्पादित किया गया था कंसोल कमांड (एक डेटाबेस कंसोल कमांड का उपयोग कमांड या ऑपरेशन की पहचान करने के लिए किया जाता है जो चयनित सर्वर प्रोसेस आईडी पर हो रहा है)।

पठनीयता के लिए, मैं EventInfo को कॉपी कर रहा हूं फ़ील्ड मान और इसे उस कमांड को दिखाने के लिए स्वरूपित करना जो हमने पहले निष्पादित किया है।

यदि चयनित डेटाबेस पर कोई लंबे समय तक चलने वाला सक्रिय लेनदेन नहीं है, तो हमें निम्न संदेश प्राप्त होगा:

DBCC OPENTRAN . के समान कंसोल कमांड, हम चयन कर सकते हैं DMV . से नाम sys.dm_tran_database_transactions अधिक विस्तृत परिणाम प्राप्त करने के लिए (अधिक डेटा के लिए MSDN आलेख देखें)।

अब, हम जानते हैं कि लंबे समय तक चलने वाले लेनदेन की पहचान कैसे करें। हम लेन-देन कर सकते हैं और देख सकते हैं कि INSERT कथन कैसे दोहराया जाता है।

उस विंडो पर जाएं जहां हमने Person.ContactType . में रिकॉर्ड डाला है लेन-देन के दायरे में तालिका और नीचे दिखाए अनुसार कमिट ट्रांजेक्शन निष्पादित करें:

COMMIT TRANSACTION के निष्पादन ने प्रकाशक डेटाबेस में रिकॉर्ड को प्रतिबद्ध किया। इसलिए, यह वितरण डेटाबेस और सब्सक्राइबर डेटाबेस में दिखाई देना चाहिए:

यदि आपने देखा है, वितरण एजेंट क्लीन-अप कार्य द्वारा वितरण डेटाबेस से पुराने रिकॉर्ड साफ़ किए गए थे। INSERT के लिए Person.ContactType . पर नया रिकॉर्ड तालिका MSRepl_cmds . में दिखाई दे रही थी टेबल।

हमारे परीक्षण से, हमने निम्नलिखित बातें सीखी हैं:

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

बल्क SQL INSERT/अद्यतन/लेखों पर संचालन हटाएं

प्रकाशक डेटाबेस में रहने वाले विशाल डेटा के साथ, हम अक्सर INSERT या UPDATE की आवश्यकताओं के साथ समाप्त होते हैं या प्रतिकृति तालिकाओं में विशाल रिकॉर्ड हटाते हैं।

यदि INSERT, या UPDATE, या DELETE संचालन एक ही लेन-देन में किया जाता है, तो यह निश्चित रूप से लंबे समय से अटकी प्रतिकृति में समाप्त हो जाएगा।

मान लें कि हमें एक प्रतिरूपित तालिका में 10 मिलियन रिकॉर्ड डालने की आवश्यकता है। उन रिकॉर्ड्स को एक ही शॉट में सम्मिलित करने से प्रदर्शन संबंधी समस्याएं उत्पन्न होंगी।

INSERT INTO REplicated_table
SELECT * FROM Source_table

इसके बजाय, हम जबकि में 0.1 या 0.5 मिलियन रिकॉर्ड के बैच में रिकॉर्ड दर्ज कर सकते हैं लूप या कर्सर लूप , और यह तेजी से प्रतिकृति सुनिश्चित करेगा। हमें INSERT कथनों के लिए प्रमुख मुद्दे प्राप्त नहीं हो सकते हैं, जब तक कि अन्यथा शामिल तालिका में बहुत सारी अनुक्रमणिकाएँ न हों। हालांकि, UPDATE या DELETE स्टेटमेंट्स के लिए इसका एक बड़ा प्रदर्शन हिट होगा।

मान लें कि हमने प्रतिकृति तालिका में एक नया कॉलम जोड़ा है जिसमें लगभग 10 मिलियन रिकॉर्ड हैं। हम इस नए कॉलम को डिफ़ॉल्ट मान के साथ अपडेट करना चाहते हैं।

आदर्श रूप से, नीचे दिया गया आदेश सभी 10 मिलियन रिकॉर्ड को डिफ़ॉल्ट मान के साथ Abc . के रूप में अद्यतन करने के लिए ठीक काम करेगा :

-- UPDATE 10 Million records on Replicated Table with some DEFAULT values
UPDATE Replicated_table
SET new_column = 'Abc'

हालांकि, प्रतिकृति पर प्रभाव से बचने के लिए, हमें प्रदर्शन के मुद्दों से बचने के लिए उपरोक्त अद्यतन ऑपरेशन को 0.1 या 0.5 मिलियन रिकॉर्ड के बैचों में निष्पादित करना चाहिए।

-- UPDATE in batches to avoid performance impacts on Replication
WHILE 1 = 1
BEGIN
	UPDATE TOP(100000) Replicated_Table
	SET new_Column = 'Abc'
	WHERE new_column is NULL

	IF @@ROWCOUNT = 0
	BREAK
END

इसी तरह, अगर हमें किसी रेप्लिकेटेड टेबल से लगभग 10 मिलियन रिकॉर्ड्स को हटाना है, तो हम इसे बैचों में कर सकते हैं:

-- DELETE 10 Million records on Replicated Table with some DEFAULT values
DELETE FROM Replicated_table

-- UPDATE in batches to avoid performance impacts on Replication
WHILE 1 = 1
BEGIN
	DELETE TOP(100000) Replicated_Table

	IF @@ROWCOUNT = 0
	BREAK
END

बल्क इंसर्ट, या अपडेट या DELETE को कुशलतापूर्वक संभालने से प्रतिकृति मुद्दों को हल करने में मदद मिल सकती है।

प्रो टिप :प्रकाशक डेटाबेस में एक प्रतिकृति तालिका में विशाल डेटा सम्मिलित करने के लिए, SSMS में आयात/निर्यात विज़ार्ड का उपयोग करें, क्योंकि यह 10000 के बैच में रिकॉर्ड सम्मिलित करेगा या SQL सर्वर द्वारा तेजी से गणना किए गए रिकॉर्ड आकार के आधार पर होगा।

एकल लेन-देन के भीतर विशाल डेटा परिवर्तन

एप्लिकेशन या विकास के दृष्टिकोण से डेटा अखंडता बनाए रखने के लिए, कई अनुप्रयोगों में महत्वपूर्ण संचालन के लिए स्पष्ट लेनदेन परिभाषित होते हैं। हालाँकि, यदि बहुत सारे ऑपरेशन (INSERT, UPDATE, या DELETE) एक ही लेन-देन के दायरे में प्रदर्शन करते हैं, तो लॉग रीडर एजेंट पहले लेन-देन के पूरा होने की प्रतीक्षा करेगा, जैसा कि हमने पहले देखा है।

एक बार जब लेन-देन एप्लिकेशन द्वारा प्रतिबद्ध हो जाता है, तो लॉग रीडर एजेंट को प्रकाशक डेटाबेस लेनदेन लॉग पर किए गए उन विशाल डेटा परिवर्तनों को स्कैन करने की आवश्यकता होती है। उस स्कैन के दौरान, हम लॉग रीडर एजेंट में चेतावनियां या सूचनात्मक संदेश देख सकते हैं जैसे

लॉग रीडर एजेंट लेनदेन लॉग को स्कैन कर रहा है ताकि आदेशों को दोहराया जा सके। पास में लगभग xxxxxx लॉग रिकॉर्ड स्कैन किए गए हैं # xxxx जिनमें से प्रतिकृति, बीता हुआ समय xxxxxxxxx (ms) के लिए चिह्नित किया गया था

इस परिदृश्य के समाधान की पहचान करने से पहले, हमें यह समझने की आवश्यकता है कि लॉग रीडर एजेंट लेनदेन संबंधी लॉग से रिकॉर्ड कैसे स्कैन करता है और वितरण डेटाबेस में रिकॉर्ड सम्मिलित करता है MSrepl_transactions और MSrepl_cmds टेबल.

SQL सर्वर में आंतरिक रूप से ट्रांजेक्शनल लॉग्स के अंदर एक लॉग सीक्वेंस नंबर (LSN) होता है। लॉग रीडर एजेंट क्रम में SQL सर्वर प्रतिकृति के लिए चिह्नित परिवर्तनों को स्कैन करने के लिए LSN मानों का उपयोग करता है।

लॉग रीडर एजेंट sp_replcmds को निष्पादित करता है प्रकाशक डेटाबेस के लेन-देन लॉग से प्रतिकृति के लिए चिह्नित आदेशों को लाने के लिए विस्तारित संग्रहीत कार्यविधि।

Sp_replcmds @maxtrans . नामक इनपुट पैरामीटर स्वीकार करता है लेनदेन की अधिकतम संख्या लाने के लिए। डिफ़ॉल्ट मान 1 होगा जिसका अर्थ है कि यह वितरण डेटाबेस में भेजे जाने वाले लॉग से उपलब्ध लेनदेन की संख्या को स्कैन करेगा। यदि एक लेनदेन के माध्यम से 10 INSERT संचालन किए गए हैं और प्रकाशक डेटाबेस में प्रतिबद्ध हैं, तो एक बैच में 10 आदेशों के साथ 1 लेनदेन हो सकता है।

यदि कम कमांड वाले कई लेन-देन की पहचान की जाती है, तो लॉग रीडर एजेंट कई लेन-देन या XACT को जोड़ देगा। एकल प्रतिकृति बैच के लिए अनुक्रम संख्या। लेकिन यह एक अलग XACT . के रूप में संग्रहीत होता है अनुक्रम संख्या MSRepl_transactions . में टेबल। उस लेन-देन से संबंधित व्यक्तिगत आदेश MSRepl_commands . में कैप्चर किए जाएंगे टेबल।

जिन चीजों की हमने ऊपर चर्चा की है, उन्हें सत्यापित करने के लिए, मैं संशोधित तिथि . को अपडेट कर रहा हूं dbo.AWBuildVersion . का कॉलम आज की तारीख की तालिका और देखें कि क्या होता है:

UPDATE AdventureWorks.dbo.AWBuildVersion
SET ModifiedDate  = GETDATE()

अद्यतन क्रियान्वित करने से पहले, हम MSrepl_commands में मौजूद अभिलेखों को सत्यापित करते हैं और MSrepl_transactions टेबल:

अब, उपरोक्त अद्यतन स्क्रिप्ट निष्पादित करें और उन 2 तालिकाओं में मौजूद रिकॉर्ड को सत्यापित करें:

अद्यतन समय के साथ एक नया रिकॉर्ड MSrepl_transactions . में डाला गया था निकट प्रवेश_समय . के साथ तालिका . इस पर कमांड की जाँच xact_seqno sp_browsereplcmds का उपयोग करके तार्किक रूप से समूहीकृत आदेशों की सूची दिखाएगा प्रक्रिया।

प्रतिकृति मॉनिटर में, हम प्रकाशक से वितरक को 1 आदेश (ओं) के साथ 1 लेनदेन (ओं) के तहत कब्जा कर लिया गया एक अद्यतन विवरण देख सकते हैं।

और हम एक ही कमांड को डिस्ट्रीब्यूटर से सब्सक्राइबर तक एक सेकंड के अंतर के एक अंश में डिलीवर होते हुए देख सकते हैं। यह इंगित करता है कि प्रतिकृति ठीक से हो रही है।

अब, यदि एक ही xact_seqno में बड़ी संख्या में लेन-देन संयुक्त हैं , हम देख सकते हैं कि 10 लेनदेन (ओं) के साथ 5000 आदेश वितरित किए गए ।

आइए एक ही समय में 2 अलग-अलग तालिकाओं पर UPDATE को क्रियान्वित करके इसकी जांच करें:

हम MSrepl_transactions . में दो लेन-देन रिकॉर्ड देख सकते हैं तालिका दो अद्यतन संचालन से मेल खाती है और फिर नहीं। उस तालिका में रिकॉर्ड की संख्या से मेल खाता है। रिकॉर्ड अपडेट किए गए।

MSrepl_transactions . से परिणाम तालिका:

MSrepl_commands . से परिणाम तालिका:

हालांकि, हमने देखा है कि इन 2 लेन-देन को तार्किक रूप से लॉग रीडर एजेंट द्वारा समूहीकृत किया जाता है और एक बैच में 109225 कमांड के साथ 2 लेनदेन के रूप में संयोजित किया जाता है।

लेकिन इससे पहले, हम प्रतिकृति लेनदेन वितरित करना, xact गणना:1, कमांड गणना 46601 जैसे संदेश देख सकते हैं। ।

यह तब तक होगा जब तक लॉग रीडर एजेंट परिवर्तनों के पूरे सेट को स्कैन नहीं करता है और यह पहचानता है कि 2 अद्यतन लेनदेन लेनदेन संबंधी लॉग से पूरी तरह से पढ़े गए थे।

लेन-देन लॉग से कमांड पूरी तरह से पढ़ने के बाद, हम देखते हैं कि लॉग रीडर एजेंट द्वारा 109225 कमांड के साथ 2 लेनदेन वितरित किए गए थे:

चूंकि वितरण एजेंट एक बड़े लेन-देन के दोहराने की प्रतीक्षा कर रहा है, इसलिए हमें प्रतिकृति लेनदेन वितरित करना जैसा संदेश दिखाई दे सकता है। यह दर्शाता है कि एक बड़ा लेन-देन दोहराया जा रहा था, और हमें इसके पूरी तरह से दोहराने के लिए प्रतीक्षा करने की आवश्यकता है।

एक बार दोहराने के बाद, हम वितरण एजेंट में भी नीचे दिया गया संदेश देख सकते हैं:

इन समस्याओं को हल करने के लिए कई तरीके मददगार होते हैं।

तरीका 1:नई SQL संग्रहीत प्रक्रिया बनाएं

आपको एक नई संग्रहीत कार्यविधि बनाने और लेन-देन के दायरे में एप्लिकेशन लॉजिक को उसमें समाहित करने की आवश्यकता है।

एक बार यह बन जाने के बाद, उस संग्रहित प्रक्रिया लेख को प्रतिकृति में जोड़ें और लेख संपत्ति को बदलें संग्रहीत प्रक्रिया का निष्पादन विकल्प।

यह हो रहे सभी व्यक्तिगत डेटा परिवर्तनों को दोहराने के बजाय सब्सक्राइबर पर संग्रहीत प्रक्रिया लेख को निष्पादित करने में मदद करेगा।

आइए समीक्षा करें कि संग्रहीत प्रक्रिया का निष्पादन . कैसे होता है प्रतिकृति के लिए विकल्प प्रतिकृति पर भार को कम करता है। ऐसा करने के लिए, हम एक परीक्षण संग्रहित प्रक्रिया बना सकते हैं जैसा कि नीचे दिखाया गया है:

CREATE procedure test_proc
AS
BEGIN
UPDATE AdventureWorks.dbo.AWBuildVersion
SET ModifiedDate  = GETDATE()

UPDATE TOP(10) Production.TransactionHistoryArchive
SET ModifiedDate  = GETDATE()

UPDATE TOP(10) Person.Person
SET ModifiedDate  = GETDATE()
END

उपरोक्त प्रक्रिया AWBuildVersion . पर एकल रिकॉर्ड को अपडेट करेगी Production.TransactionHistoryArchive . पर प्रत्येक तालिका और 10 रिकॉर्ड और व्यक्ति.व्यक्ति कुल 21 रिकॉर्ड परिवर्तन वाली तालिकाएँ।

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

एक बार हो जाने के बाद, हम MSrepl_transactions . में उपलब्ध रिकॉर्ड को सत्यापित कर सकते हैं और MSrepl_commands टेबल.

अब, यह देखने के लिए कि कितने रिकॉर्ड ट्रैक किए गए हैं, प्रकाशक डेटाबेस में प्रक्रिया निष्पादित करें।

हम वितरण तालिकाओं पर निम्नलिखित देख सकते हैं MSrepl_transactions और MSrepl_commands :

तीन xact_seqno MSrepl_transactions . में तीन अद्यतन संचालन के लिए बनाए गए थे तालिका, और 21 आदेश MSrepl_commands . में सम्मिलित किए गए टेबल।

प्रतिकृति मॉनिटर खोलें और देखें कि क्या उन्हें 3 अलग-अलग प्रतिकृति बैचों के रूप में या 3 लेनदेन के साथ एक बैच के रूप में भेजा जाता है।

हम देख सकते हैं कि तीन xact_seqno एकल प्रतिकृति बैच के रूप में समेकित किया गया। इसलिए, हम देख सकते हैं कि 21 आदेशों के साथ 3 लेनदेन सफलतापूर्वक वितरित किए गए।

आइए प्रतिकृति से प्रक्रिया को हटा दें और इसे दूसरे संग्रहीत प्रक्रिया का निष्पादन के साथ वापस जोड़ें विकल्प। अब, प्रक्रिया को निष्पादित करें और देखें कि रिकॉर्ड कैसे दोहराए जा रहे हैं।

वितरण तालिकाओं से अभिलेखों की जाँच निम्न विवरण दिखाती है:

अब, प्रकाशक डेटाबेस पर प्रक्रिया निष्पादित करें और देखें कि वितरण तालिकाओं में कितने रिकॉर्ड लॉग हो रहे हैं। एक प्रक्रिया का निष्पादन पहले की तरह 21 रिकॉर्ड (1 रिकॉर्ड, 10 रिकॉर्ड और 10 रिकॉर्ड) अपडेट किया गया।

वितरण तालिका का सत्यापन नीचे दिया गया डेटा दिखाता है:

आइए प्राप्त वास्तविक आदेश को देखने के लिए sp_browsereplcmds पर एक त्वरित नज़र डालें:

कमांड है “{call “dbo”।”test_proc” }” जिसे सब्सक्राइबर डेटाबेस पर निष्पादित किया जाएगा।

प्रतिकृति मॉनिटर में, हम देख सकते हैं कि प्रतिकृति के माध्यम से केवल 1 लेनदेन (ओं) को 1 कमांड के साथ वितरित किया गया था:

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

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

तरीका 2:MaxCmdsInTran, ReadBatchSize, और ReadBatchThreshold लॉग रीडर एजेंट पैरामीटर कॉन्फ़िगर करना

MaxCmdsInTran - प्रकाशक डेटाबेस के लेन-देन लॉग से डेटा पढ़ते समय और वितरण डेटाबेस को लिखे जाने के दौरान तार्किक रूप से एक लेनदेन में समूहीकृत किए जा सकने वाले आदेशों की अधिकतम संख्या को इंगित करता है।

हमारे पहले के परीक्षणों में, हमने देखा कि लगभग 109225 कमांड एक ही प्रतिकृति सटीक अनुक्रम में जमा हो गए, जिसके परिणामस्वरूप थोड़ी धीमी या विलंबता हुई। अगर हम MaxCmdsInTran . सेट करते हैं 10000 के लिए पैरामीटर, एकल सटीक अनुक्रम संख्या 11 . में विभाजित हो जाएगी xact अनुक्रमों के परिणामस्वरूप प्रकाशक से वितरक तक आदेशों का तेजी से वितरण . भले ही यह विकल्प वितरण डेटाबेस के विवाद को कम करने में मदद करता है और डेटा को प्रकाशक से सब्सक्राइबर डेटाबेस में तेजी से दोहराने में मदद करता है, इस विकल्प का उपयोग करते समय सावधान रहें। यह मूल लेनदेन के दायरे के अंत से पहले सब्सक्राइबर डेटाबेस को डेटा वितरित कर सकता है और सब्सक्राइबर डेटाबेस टेबल से इसे एक्सेस कर सकता है।

पढ़ें बैच आकार - यह पैरामीटर एक विशाल लेनदेन परिदृश्य के लिए सहायक नहीं हो सकता है। हालाँकि, यह तब मदद करता है जब प्रकाशक डेटाबेस पर बहुत सारे और बहुत सारे छोटे लेन-देन हो रहे हों।

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

बैच दहलीज पढ़ें - पूर्ण लॉग फ़ाइल को स्कैन करने के लिए 0 के डिफ़ॉल्ट मान के साथ सब्सक्राइबर को भेजे जाने से पहले प्रकाशक डेटाबेस के ट्रांजेक्शनल लॉग से पढ़ी जाने वाली कमांड की संख्या को इंगित करता है। हालांकि, हम इस तरह के 10000 या 100000 कमांड तक सीमित करके डेटा को तेज़ी से भेजने के लिए इस मान को कम कर सकते हैं।

तरीका 3:SubscriptionStreams पैरामीटर के लिए सर्वोत्तम मानों को कॉन्फ़िगर करना

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

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

वितरण डेटाबेस में अवरोध

वितरण डेटाबेस SQL ​​सर्वर ट्रांजेक्शनल प्रतिकृति का दिल है और यदि इसे ठीक से बनाए नहीं रखा जाता है, तो बहुत सारे प्रदर्शन मुद्दे होंगे।

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

1. वितरण डेटाबेस की डेटा फ़ाइलें उच्च IOPS ड्राइव पर रखी जानी चाहिए। यदि प्रकाशक डेटाबेस में बहुत सारे डेटा परिवर्तन होंगे, तो हमें यह सुनिश्चित करने की आवश्यकता है कि वितरण डेटाबेस उच्च IOPS वाले ड्राइव पर रखा गया है। यह लॉग रीडर एजेंट से लगातार डेटा प्राप्त करेगा, वितरण एजेंट के माध्यम से सब्सक्राइबर डेटाबेस को डेटा भेज रहा है। डिस्ट्रीब्यूशन क्लीन-अप जॉब के माध्यम से हर 10 मिनट में डिस्ट्रीब्यूशन डेटाबेस से सभी प्रतिकृति डेटा को शुद्ध कर दिया जाएगा।
2. प्रकाशक डेटाबेस गतिविधि स्तरों के आधार पर अनुशंसित मानों के साथ वितरण डेटाबेस के प्रारंभिक फ़ाइल आकार और ऑटोग्रोथ गुणों को कॉन्फ़िगर करें। अन्यथा, यह डेटा और लॉग फ़ाइलों के विखंडन की ओर ले जाएगा जिससे प्रदर्शन संबंधी समस्याएं हो सकती हैं।
3. वितरण डेटाबेस को सर्वर पर कॉन्फ़िगर किए गए नियमित इंडेक्स रखरखाव कार्यों में शामिल करें जहां वितरण डेटाबेस स्थित है।
4. किसी विशिष्ट समस्या के निवारण के लिए वितरण डेटाबेस को पूर्ण बैकअप कार्य शेड्यूल में शामिल करें।
5. सुनिश्चित करें कि वितरण सफाई:वितरण कार्य डिफ़ॉल्ट शेड्यूल के अनुसार हर 10 मिनट में चल रहा है। अन्यथा, वितरण डेटाबेस का आकार बढ़ता रहता है और प्रदर्शन समस्याओं का कारण बनता है।

जैसा कि हमने अब तक देखा है, वितरण डेटाबेस में शामिल प्रमुख तालिकाएं हैं MSrepl_transactions और MSrepl_commands . रिकॉर्ड्स को लॉग रीडर एजेंट जॉब द्वारा डाला जाता है, डिस्ट्रीब्यूशन एजेंट जॉब द्वारा चुना जाता है, सब्सक्राइबर डेटाबेस पर लागू किया जाता है, और फिर डिस्ट्रीब्यूशन क्लीन-अप एजेंट जॉब द्वारा डिलीट या साफ किया जाता है।

यदि वितरण डेटाबेस ठीक से कॉन्फ़िगर नहीं किया गया है, तो हम इन 2 तालिकाओं में सत्र अवरोधों का सामना कर सकते हैं, जिसके परिणामस्वरूप SQL सर्वर प्रतिकृति प्रदर्शन समस्याएँ होंगी।

SQL सर्वर के वर्तमान उदाहरण में उपलब्ध ब्लॉकिंग सत्रों को देखने के लिए हम किसी भी डेटाबेस में नीचे दी गई क्वेरी को निष्पादित कर सकते हैं:

SELECT * 
FROM sys.sysprocesses
where blocked > 0
order by waittime desc

यदि उपरोक्त क्वेरी कोई परिणाम देती है, तो हम DBCC INPUTBUFFER(spid) निष्पादित करके उन अवरुद्ध सत्रों पर कमांड की पहचान कर सकते हैं। कंसोल कमांड और उसके अनुसार कार्रवाई करें।

भ्रष्टाचार से संबंधित मुद्दे

SQL सर्वर डेटाबेस डेटा को तालिकाओं में संग्रहीत करने और इसे विस्तार या पृष्ठों में रखने के लिए अपने एल्गोरिथ्म या तर्क का उपयोग करता है। डेटाबेस भ्रष्टाचार एक ऐसी प्रक्रिया है जिसके द्वारा डेटाबेस से संबंधित फाइलों/विस्तार/पृष्ठों की भौतिक स्थिति सामान्य से अस्थिर या गैर-पुनर्प्राप्ति स्थिति में बदल जाती है जिससे डेटा पुनर्प्राप्ति कठिन या असंभव हो जाती है।

सभी SQL सर्वर डेटाबेस डेटाबेस भ्रष्टाचार से ग्रस्त हैं। इसके कारण हो सकते हैं:

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

यदि हम बिना किसी डेटा हानि के डेटाबेस को पुनर्प्राप्त या मरम्मत कर सकते हैं, तो SQL सर्वर प्रतिकृति प्रभावित नहीं होगी। हालांकि, अगर भ्रष्ट डेटाबेस को पुनर्प्राप्त करने या मरम्मत करते समय कोई डेटा हानि होती है, तो हमें बहुत सारे डेटा अखंडता मुद्दे प्राप्त होने लगेंगे जिनकी चर्चा हमने अपने पिछले लेख में की थी।

विभिन्न घटकों में भ्रष्टाचार हो सकता है, जैसे:

• प्रकाशक डेटा/लॉगफ़ाइल भ्रष्टाचार
• सदस्य डेटा/लॉगफ़ाइल भ्रष्टाचार
• वितरण डेटाबेस डेटा/लॉग फ़ाइल भ्रष्टाचार
• Msdb डेटाबेस डेटा/लॉग फ़ाइल भ्रष्टाचार

यदि हम भ्रष्टाचार के मुद्दों को ठीक करने के बाद बहुत सारी डेटा अखंडता के मुद्दे प्राप्त करते हैं, तो यह अनुशंसा की जाती है कि प्रतिकृति को पूरी तरह से हटा दें, प्रकाशक, ग्राहक या वितरक डेटाबेस में सभी भ्रष्टाचार मुद्दों को ठीक करें और फिर इसे ठीक करने के लिए प्रतिकृति को फिर से कॉन्फ़िगर करें। Otherwise, data integrity issues will persist and lead to data inconsistency across the Publisher and Subscriber. The time required to fix the Data integrity issues in case of Corrupted databases will be much more compared to configuring Replication from scratch. Hence identify the level of Corruption encountered and take optimal decisions to resolve the Replication issues faster.

Wondering why msdb database corruption can harm Replication? Since msdb database hold all details related to SQL Server Agent Jobs including Replication Agent jobs, any corruption on msdb database will harm Replication. To recover quickly from msdb database corruptions, it is recommended to restore msdb database from the last Full Backup of msdb database. This also signifies the importance of taking Full Backups of all system databases including msdb database.

निष्कर्ष

Thanks for successfully going through the final power-packed article about the Performance issues in the SQL Server Transactional Replication. If you have gone through all articles carefully, you should be able to troubleshoot almost any Transactional Replication-based issues and fix them out efficiently.

If you need any further guidance or have any Transactional Replication-related issues in your environment, you can reach out to me for consultation. And if I missed anything essential in this article, you are welcome to point to that in the Comments section.