SQL सर्वर लेनदेन संबंधी प्रतिकृति समस्याओं का निवारण

SQL सर्वर ट्रांजेक्शनल प्रतिकृति सबसे आम प्रतिकृति तकनीकों में से एक है जिसका उपयोग कई गंतव्यों में डेटा की प्रतिलिपि बनाने या वितरित करने के लिए किया जाता है।

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

एसक्यूएल प्रतिकृति मुद्दे

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

हम सभी SQL प्रतिकृति मुद्दों को नीचे की श्रेणियों में वर्गीकृत कर सकते हैं (मेरे अनुभव के आधार पर):

कॉन्फ़िगरेशन समस्याएं

• अधिकतम पाठ प्रतिकृति आकार
• SQL सर्वर एजेंट सेवा स्वचालित मोड प्रारंभ करने के लिए सेट नहीं है
• अनियमित प्रतिकृति उदाहरण एक अप्रारंभिक सदस्यता स्थिति में आ जाते हैं
• एसक्यूएल सर्वर में ज्ञात समस्याएं

अनुमति संबंधी समस्याएं

• एसक्यूएल सर्वर एजेंट नौकरी अनुमति मुद्दे
• स्नैपशॉट एजेंट जॉब क्रेडेंशियल स्नैपशॉट फ़ोल्डर पथ तक नहीं पहुंच सकता
• लॉग रीडर एजेंट जॉब क्रेडेंशियल प्रकाशक/वितरण डेटाबेस से कनेक्ट नहीं हो सकता
• डिस्ट्रीब्यूशन एजेंट जॉब क्रेडेंशियल डिस्ट्रीब्यूशन/सब्सक्राइबर डेटाबेस से कनेक्ट नहीं हो सकता

कनेक्टिविटी संबंधी समस्याएं

• प्रकाशक सर्वर नहीं मिला या पहुंच योग्य नहीं था
• वितरण सर्वर नहीं मिला या पहुंच योग्य नहीं था
• सदस्य सर्वर नहीं मिला या पहुंच योग्य नहीं था

डेटा अखंडता मुद्दे

• प्राथमिक कुंजी या अनन्य कुंजी उल्लंघन त्रुटियां
• पंक्ति नहीं मिली त्रुटियां
• विदेशी कुंजी या अन्य बाधा उल्लंघन त्रुटियां

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

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

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

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

डेमो पर्यावरण तैयारी

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

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

बदलें 1 - व्यक्ति में रिकॉर्ड सम्मिलित करना। संपर्क प्रकार तालिका

Person.ContacType . में रिकॉर्ड डालने से पहले तालिका, आइए उस तालिका संरचना, कुछ डिफ़ॉल्ट बाधाओं और नीचे दी गई स्क्रिप्ट में संशोधित विस्तारित गुणों पर एक नज़र डालें:

CREATE TABLE [Person].[ContactType](
	[ContactTypeID] [int] IDENTITY(1,1) NOT FOR REPLICATION NOT NULL,
	[Name] [dbo].[Name] NOT NULL,
	[ModifiedDate] [datetime] NOT NULL,
 CONSTRAINT [PK_ContactType_ContactTypeID] PRIMARY KEY CLUSTERED 
(
	[ContactTypeID] ASC
) ON [PRIMARY]
) ON [PRIMARY]
GO

मैंने इस तालिका को इसलिए चुना है क्योंकि इसमें कम कॉलम हैं। यह परीक्षण उद्देश्यों के लिए अधिक सुविधाजनक है। अब, आइए देखें कि हमें इसकी संरचना के बारे में क्या मिला है:

• ContactTypeId एक पहचान कॉलम के रूप में परिभाषित किया गया है - यह प्राथमिक कुंजी मानों को स्वत:उत्पन्न करेगा और प्रतिकृति के लिए नहीं।
• प्रतिकृति के लिए नहीं एक विशेष संपत्ति है जिसका उपयोग विभिन्न वस्तु प्रकारों जैसे टेबल्स, बाधाओं जैसे विदेशी कुंजी बाधाओं, चेक बाधाओं, ट्रिगर्स, और पहचान कॉलम पर प्रकाशक या सब्सक्राइबर पर केवल किसी भी प्रतिकृति पद्धति का उपयोग करते समय किया जा सकता है। यह डीबीए की योजना बनाने या प्रतिकृति को लागू करने देता है ताकि यह सुनिश्चित हो सके कि प्रतिकृति का उपयोग करते समय प्रकाशक/सब्सक्राइबर में कुछ कार्यात्मकता अलग-अलग व्यवहार करती है।
• हमारे मामले में, हम SQL सर्वर को केवल प्रकाशक डेटाबेस पर उत्पन्न पहचान मूल्यों का उपयोग करने का निर्देश देते हैं। Person.ContactType . पर IDENTITY प्रॉपर्टी का इस्तेमाल नहीं किया जाना चाहिए सब्सक्राइबर डेटाबेस में तालिका। इसी तरह, जब इस विकल्प का उपयोग करके प्रतिकृति को कॉन्फ़िगर किया जाता है, तो हम बाधाओं या ट्रिगर्स को अलग तरीके से व्यवहार करने के लिए संशोधित कर सकते हैं।
• 2 अन्य NOT NULL कॉलम तालिका में उपलब्ध हैं।
• तालिका में ContactTypeId . पर परिभाषित एक प्राथमिक कुंजी है . बस याद करने के लिए, प्राथमिक कुंजी प्रतिकृति के लिए एक अनिवार्य आवश्यकता है। टेबल पर इसके बिना, हम टेबल लेख को दोहराने में सक्षम नहीं होंगे।

अब, व्यक्ति . के लिए एक नमूना रिकॉर्ड दर्ज करें .संपर्क प्रकार AdventureWorks_REPL . में तालिका डेटाबेस:

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

 SET IDENTITY_INSERT AdventureWorks_REPL.Person.ContactType ON;

 INSERT INTO AdventureWorks_REPL.Person.ContactType(ContactTypeID, Name, ModifiedDate)
 VALUES (21, 'Test Position', GETDATE())
SET IDENTITY_INSERT AdventureWorks_REPL.Person.ContactType OFF;

SET IDENTITY_INSERT विकल्प जोड़ने के बाद, हम Person.ContactType में सफलतापूर्वक रिकॉर्ड दर्ज कर सकते हैं टेबल।

टेबल पर सेलेक्ट को एक्जीक्यूट करना नया डाला गया रिकॉर्ड दिखाता है:

हमने केवल सब्सक्राइबर डेटाबेस में एक नया रिकॉर्ड जोड़ा है जो Person.ContactType पर प्रकाशक डेटाबेस में उपलब्ध नहीं है। टेबल।

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

बदलें 2 - व्यक्ति से 2 रिकॉर्ड हटाना। संपर्क प्रकार तालिका

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

अब, हम इन 2 ContactTypeId को हटा सकते हैं निम्नलिखित कथन का उपयोग करते हुए:

DELETE FROM AdventureWorks_REPL.Person.ContactType
WHERE ContactTypeID IN (19,20)

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

हमारे पास विदेशी कुंजी संदर्भ है जो Person.ContactType से इन 2 रिकॉर्ड को हटाने से रोकता है टेबल। हम अस्थायी रूप से चाइल्ड टेबल पर विदेशी कुंजी बाधा को अक्षम करके इस परिदृश्य को संभाल सकते हैं। स्क्रिप्ट नीचे है:

ALTER TABLE [Person].[BusinessEntityContact] NOCHECK CONSTRAINT [FK_BusinessEntityContact_ContactType_ContactTypeID];

एक बार विदेशी कुंजी अक्षम हो जाने पर, हम Person.ContactType . से रिकॉर्ड सफलतापूर्वक हटा सकते हैं तालिका:

इसने 2 टेबलों में फॉरेन की रेफरेंशियल बाधा को भी संशोधित किया है। हम इस परिदृश्य के आधार पर SQL प्रतिकृति समस्याओं का अनुकरण करने का प्रयास कर सकते हैं।

हमारे वर्तमान परिदृश्य में, हम जानते हैं कि Person.ContactType तालिका में प्रकाशक और सब्सक्राइबर के बीच डेटा सिंक्रनाइज़ नहीं था।

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

यहाँ Microsoft से समाधान आता है जो हमें प्रकाशक और सब्सक्राइबर में तालिकाओं में डेटा विसंगतियों को सत्यापित करने की अनुमति देता है। जी हां, आपने सही अनुमान लगाया। यह TableDiff उपयोगिता है जिस पर हमने पिछले लेखों में चर्चा की थी।

टेबलडिफ यूटिलिटी

TableDiff उपयोगिता मुख्य रूप से प्रतिकृति वातावरण में उपयोग की जाती है। हम इसे अन्य मामलों के लिए भी उपयोग कर सकते हैं जहां हमें गैर-अभिसरण के लिए 2 SQL सर्वर तालिकाओं की तुलना करने की आवश्यकता होती है। हम उनकी तुलना कर सकते हैं और इन 2 तालिकाओं के बीच के अंतरों की पहचान कर सकते हैं। तब उपयोगिता गंतव्य . को सिंक्रनाइज़ करने में मदद करती है टेबल स्रोत . को टेबल आवश्यक INSERT/UPDATE/DELETE स्क्रिप्ट तैयार करके।

TableDiff एक स्टैंडअलोन प्रोग्राम tablediff.exe है जो डिफ़ॉल्ट रूप से C:\Program Files\Microsoft SQL Server\130\COM पर स्थापित होता है जब हम प्रतिकृति घटक स्थापित कर लेते हैं। कृपया ध्यान दें कि डिफ़ॉल्ट पथ SQL सर्वर स्थापना पैरामीटर के अनुसार भिन्न हो सकता है। पथ में 130 नंबर SQL सर्वर संस्करण (SQL Server 2016) को इंगित करता है। इसलिए, यह SQL सर्वर स्थापना के प्रत्येक भिन्न संस्करण के लिए भिन्न होगा।

आप TableDiff उपयोगिता को कमांड प्रॉम्प्ट या केवल बैच फ़ाइलों से एक्सेस कर सकते हैं। उपयोगिता के पास उपयोग करने के लिए फैंसी विज़ार्ड या जीयूआई नहीं है। TableDiff सुविधा का विस्तृत सिंटैक्स MSDN आलेख में है। हमारा वर्तमान लेख केवल कुछ आवश्यक विकल्पों पर केंद्रित है।

TableDiff उपयोगिता का उपयोग करके 2 तालिकाओं की तुलना करने के लिए, हमें स्रोत और गंतव्य तालिकाओं के लिए अनिवार्य विवरण प्रदान करने की आवश्यकता है, जैसे कि स्रोत सर्वर का नाम, स्रोत डेटाबेस का नाम, स्रोत स्कीमा का नाम, स्रोत तालिका का नाम, गंतव्य सर्वर का नाम, गंतव्य डेटाबेस का नाम, गंतव्य स्कीमा का नाम, और गंतव्य तालिका का नाम।

आइए Person.ContactType . के साथ TableDiff का परीक्षण करने का प्रयास करें प्रकाशक और सब्स्क्राइबर में भिन्नता रखने वाली तालिका।

कमांड प्रॉम्प्ट खोलें और TableDiff उपयोगिता पथ पर नेविगेट करें (यदि वह पथ पर्यावरण चर में नहीं जोड़ा गया है)।

सभी उपलब्ध मापदंडों की सूची देखने के लिए, "tablediff-?" कमांड टाइप करें। उपलब्ध सभी विकल्पों और मापदंडों को सूचीबद्ध करने के लिए। परिणाम नीचे हैं:

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

tablediff -sourceserver RRJ -sourcedatabase AdventureWorks -sourceschema Person -sourcetable ContactType -destinationserver RRJ -destinationdatabase AdventureWorks_REPL -destinationschema Person -destinationtable ContactType

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

सही कमांड निष्पादन के परिणाम:

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

अब, विविध . पर एक नज़र डालते हैं TableDiff उपयोगिता के लिए उपलब्ध विकल्प।

• -et - परिणाम सारांश को गंतव्य तालिका में लॉग करता है
• -dt - यदि परिणाम पहले से मौजूद है तो गंतव्य तालिका को छोड़ देता है
• -f - गंतव्य तालिका को स्रोत तालिका के साथ अभिसरण में लाने के लिए INSERT/UPDATE/DELETE कथनों के साथ एक टी-एसक्यूएल डीएमएल स्क्रिप्ट उत्पन्न करता है।
• -o - आउटपुट फ़ाइल नाम यदि विकल्प -f अभिसरण फ़ाइल उत्पन्न करने के लिए प्रयोग किया जाता है।

हम -f . के साथ एक अभिसरण फ़ाइल बनाएंगे और -o हमारे पहले के आदेश के विकल्प:

tablediff -sourceserver RRJ -sourcedatabase AdventureWorks -sourceschema Person -sourcetable ContactType -destinationserver RRJ -destinationdatabase AdventureWorks_REPL -destinationschema Person -destinationtable ContactType -f -o C:\PersonContactType.sql

अभिसरण फ़ाइल सफलतापूर्वक बनाई गई है:

जैसा कि आप देख सकते हैं, सुरक्षा कारणों से C:ड्राइव के रूट फ़ोल्डर में एक नई फ़ाइल के निर्माण की अनुमति नहीं है। इसलिए, यह एक त्रुटि संदेश दिखाता है और आउटपुट फ़ाइल बनाता है DIFFIX.*.sql फ़ाइल TableDiff उपयोगिता फ़ोल्डर में। जब हम उस फ़ाइल को खोलते हैं, तो हम नीचे दिए गए विवरण देख सकते हैं:

INSERT स्क्रिप्ट 2 हटाए गए रिकॉर्ड के लिए बनाई गई थीं, और DELETE स्क्रिप्ट को सब्सक्राइबर डेटाबेस में डाले गए रिकॉर्ड के लिए बनाया गया था। यह टूल गंतव्य के लिए आवश्यक IDENTITY_INSERT विकल्पों का उपयोग करने पर भी ध्यान देता है टेबल। इसलिए, जब भी किसी DBA को दो तालिकाओं को सिंक्रनाइज़ करने की आवश्यकता होती है, तो यह उपकरण बहुत काम का होगा।

हमारे मामले में, मैं स्क्रिप्ट निष्पादित नहीं करूंगा, क्योंकि हमें अपने SQL प्रतिकृति मुद्दों को अनुकरण करने के लिए इन भिन्नताओं की आवश्यकता है।

टेबलडिफ यूटिलिटी के लाभ

टेबलडिफ यूटिलिटी की सीमाएं

हालाँकि, इन सीमाओं के साथ भी, TableDiff उपयोगिता का उपयोग किसी भी SQL सर्वर तालिका में त्वरित डेटा सत्यापन या अभिसरण जाँच के लिए किया जा सकता है। हालांकि, आप एक अच्छा तृतीय-पक्ष टूल भी खरीद सकते हैं।

अब, आइए विभिन्न SQL प्रतिकृति मुद्दों पर विस्तार से विचार करें।

कॉन्फ़िगरेशन समस्याएं

अपने अनुभव से, मैंने अक्सर छूटे प्रतिकृति कॉन्फ़िगरेशन विकल्पों को वर्गीकृत किया है जो गंभीर SQL प्रतिकृति समस्याओं का कारण बन सकते हैं कॉन्फ़िगरेशन . के रूप में मुद्दे। उनमें से कुछ नीचे हैं।

अधिकतम पाठ प्रतिकृति आकार

अधिकतम टेक्स्ट प्रतिकृति आकार बाइट्स में अधिकतम टेक्स्ट प्रतिकृति आकार . को संदर्भित करता है . यह सभी डेटाटाइप पर लागू होता है जैसे char(max), nvarchar(max), varbinary(max), text, ntext, varbinary, xml, और छवि ।

SQL सर्वर के पास 65536 के रूप में दोहराने के लिए अधिकतम स्ट्रिंग डेटाटाइप कॉलम लंबाई (बाइट्स में) को सीमित करने के लिए एक डिफ़ॉल्ट विकल्प है बाइट्स।

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

मान को -1 में बदलना इंगित करता है कि कोई सीमा नहीं है। हालांकि, हम अनुशंसा करते हैं कि आप अधिकतम स्ट्रिंग लंबाई का मूल्यांकन करें और उस मान को कॉन्फ़िगर करें।

हम SSMS या T-SQL का उपयोग करके अधिकतम टेक्स्ट प्रतिकृति आकार को कॉन्फ़िगर कर सकते हैं।

SSMS में, सर्वर नाम> गुणों . पर राइट-क्लिक करें > उन्नत :

बस 65536 . पर क्लिक करें इसे संशोधित करने के लिए। परीक्षणों के लिए, मैंने 65536 को बदलकर 1000000 कर दिया है और ठीक . पर क्लिक किया है :

टी-एसक्यूएल के माध्यम से मैक्स टेक्स्ट रेप्ल साइज विकल्प को कॉन्फ़िगर करने के लिए, एक नई क्वेरी विंडो खोलें और मास्टर डेटाबेस के खिलाफ नीचे दी गई स्क्रिप्ट को निष्पादित करें:

EXEC sys.sp_configure N'max text repl size (B)', N'-1'
GO
RECONFIGURE WITH OVERRIDE
GO

यह क्वेरी प्रतिकृति को उपरोक्त डेटाटाइप कॉलम के आकार को प्रतिबंधित नहीं करने देगी।

सत्यापित करने के लिए, हम sys.configurations . पर एक चयन कर सकते हैं DMV और value_in_use की जांच करें नीचे के रूप में कॉलम:

SQL सर्वर एजेंट सेवा स्वचालित मोड प्रारंभ करने के लिए सेट नहीं है

प्रतिकृति प्रतिकृति एजेंटों पर निर्भर करती है जिन्हें SQL सर्वर एजेंट कार्य के रूप में निष्पादित किया जाता है। इसलिए, कुछ SQL सर्वर एजेंट सेवा के साथ किसी भी समस्या का प्रतिकृति कार्यक्षमता पर सीधा प्रभाव पड़ेगा।

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

यदि नहीं किया जाता है, तो प्रतिकृति लंबे समय तक नहीं चल सकती है, जो अन्य SQL सर्वर एजेंट कार्यों को भी प्रभावित करती है।

गैर-निगरानी प्रतिकृति उदाहरण एक गैर-आरंभिक सदस्यता राज्य में प्रवेश करें

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

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

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

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

यह सुनिश्चित करने के लिए कि हम इनमें से किसी भी अनियंत्रित समस्या का सामना नहीं करते हैं, डेटाबेस मेल को सभी कार्य विफलताओं की रिपोर्ट करने के लिए कॉन्फ़िगर किया जाना चाहिए या त्वरित कार्रवाई के लिए संबंधित टीम के सदस्यों को पुनः प्रयास करना चाहिए।

SQL सर्वर में ज्ञात समस्याएं

कुछ SQL सर्वर संस्करणों को RTM संस्करण या पुराने संस्करणों में प्रतिकृति समस्याओं का पता था। इन समस्याओं को बाद के सर्विस पैक या CU पैक में ठीक किया गया था। इसलिए, यह अनुशंसा की जाती है कि सभी SQL सर्वर के लिए उपलब्ध नवीनतम सर्विस पैक या CU पैक को QA वातावरण में परीक्षण करने के बाद लागू करें। भले ही यह SQL सर्वर चलाने वाले सर्वरों के लिए एक सामान्य अनुशंसा है, यह प्रतिकृति के लिए भी लागू है।

अनुमति संबंधी समस्याएं

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

एसक्यूएल सर्वर एजेंट नौकरी अनुमति मुद्दे

सभी प्रतिकृति एजेंट SQL सर्वर एजेंट कार्य का उपयोग करते हैं। स्नैपशॉट या लॉग रीडर एजेंट, या वितरण से संबंधित प्रत्येक SQL सर्वर एजेंट कार्य को कुछ Windows या SQL लॉगिन क्रेडेंशियल के तहत निष्पादित किया जाता है जैसा कि नीचे दिखाया गया है:

SQL सर्वर एजेंट कार्य प्रारंभ करने के लिए, आपके पास SQLAgentOperatorRole . होना चाहिए सभी कार्य प्रारंभ करने के लिए या SQLAgentUserRole या SQLAgentReaderRole नौकरी शुरू करने के लिए जो आपके पास है। यदि कोई कार्य ठीक से प्रारंभ नहीं हो पाता है, तो जांच लें कि उस कार्य को निष्पादित करने के लिए उस कार्य के स्वामी के पास आवश्यक अधिकार हैं या नहीं।

स्नैपशॉट एजेंट जॉब क्रेडेंशियल स्नैपशॉट फ़ोल्डर पथ तक नहीं पहुंच सकता

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

यदि स्नैपशॉट एजेंट के पास इस स्नैपशॉट फ़ाइल स्थान तक पहुँच नहीं है, तो हमें त्रुटि प्राप्त हो सकती है:

पथ 'C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\repldata\unc\XXXX\YYYYMMDDHHMISS\' तक पहुंच अस्वीकृत है।

समस्या को हल करने के लिए, फ़ोल्डर पथ C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\repldata\unc\ तक पूर्ण पहुंच प्रदान करना बेहतर है। उस खाते के लिए जिसके अंतर्गत स्नैपशॉट एजेंट निष्पादित करता है। हमारे कॉन्फ़िगरेशन में, हम SQL सर्वर एजेंट खाते का उपयोग करते हैं, और SQL सर्वर एजेंट सेवा RRJ\RRJ खाते के अंतर्गत चल रही है।

लॉग रीडर एजेंट जॉब क्रेडेंशियल प्रकाशक/वितरण डेटाबेस से कनेक्ट नहीं हो सकता

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

यदि प्रकाशक डेटाबेस का डेटाबेस स्वामी ठीक से सेट नहीं है, तो हमें निम्न त्रुटियाँ प्राप्त हो सकती हैं:

प्रक्रिया 'RRJ' पर 'sp_replcmds' निष्पादित नहीं कर सकी।

या

डेटाबेस प्रिंसिपल के रूप में निष्पादित नहीं किया जा सकता क्योंकि प्रिंसिपल "डीबीओ" मौजूद नहीं है, इस प्रकार के प्रिंसिपल का प्रतिरूपण नहीं किया जा सकता है, या आपके पास अनुमति नहीं है।

इस समस्या को हल करने के लिए, सुनिश्चित करें कि प्रकाशक डेटाबेस की डेटाबेस स्वामी संपत्ति sa . पर सेट है या कोई अन्य मान्य खाता (नीचे देखें)।

प्रकाशक पर राइट-क्लिक करें डेटाबेस (AdventureWorks )> गुण > फ़ाइलें . सुनिश्चित करें कि स्वामी फ़ील्ड सा . पर सेट है या कोई मान्य लॉगिन और रिक्त नहीं ।

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

डिस्ट्रीब्यूशन एजेंट जॉब क्रेडेंशियल, डिस्ट्रीब्यूशन/सब्सक्राइबर डेटाबेस से कनेक्ट नहीं हो सकता

यदि खाते को वितरण डेटाबेस तक पहुँचने या सब्सक्राइबर डेटाबेस से कनेक्ट करने की अनुमति नहीं है, तो वितरण एजेंट के पास अनुमति समस्याएँ हो सकती हैं। इस मामले में, हमें निम्नलिखित त्रुटियां मिल सकती हैं:

चरण 2 का निष्पादन प्रारंभ करने में असमर्थ (कारण:प्रॉक्सी RRJ\RRJ को प्रमाणित करने में त्रुटि, सिस्टम त्रुटि:उपयोगकर्ता नाम या पासवर्ड गलत है।)

प्रक्रिया सब्सक्राइबर 'आरआरजे' से कनेक्ट नहीं हो सकी।

प्रयोक्ता 'RRJ\RRJ' के लिए लॉगिन विफल रहा।

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

कनेक्टिविटी संबंधी समस्याएं

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

ऐसे मुद्दों के मामले में, प्रतिकृति एजेंट (लॉग रीडर या वितरण एजेंट) नीचे दी गई त्रुटियों की रिपोर्ट कर सकते हैं:

प्रकाशक सर्वर नहीं मिला या पहुंच योग्य नहीं था

वितरण सर्वर नहीं मिला या पहुंच योग्य नहीं था

सदस्य सर्वर नहीं मिला या पहुंच योग्य नहीं था

इन समस्याओं के निवारण के लिए, हम SSMS में प्रकाशक, वितरक, या सब्सक्राइबर डेटाबेस से कनेक्ट करने का प्रयास कर सकते हैं ताकि यह जाँचा जा सके कि हम इन SQL सर्वर इंस्टेंस से बिना किसी समस्या के कनेक्ट करने में सक्षम हैं या नहीं।

यदि कनेक्टिविटी की समस्या बार-बार होती है, तो हम किसी भी पैकेट नुकसान की पहचान करने के लिए सर्वर को लगातार पिंग करने का प्रयास कर सकते हैं। साथ ही, हमें उन मुद्दों को हल करने के लिए आवश्यक टीम के सदस्यों के साथ काम करना होगा और डेटा स्थानांतरित करने के लिए प्रतिकृति के लिए सर्वर को ऊपर और चलाना होगा।

डेटा अखंडता मुद्दे

चूंकि लेन-देन प्रतिकृति एकतरफा तंत्र है, इसलिए सब्सक्राइबर (मैन्युअल रूप से या एप्लिकेशन से) पर होने वाला कोई भी डेटा परिवर्तन प्रकाशक पर दिखाई नहीं देगा। इससे प्रकाशक और सब्सक्राइबर में डेटा भिन्नताएं हो सकती हैं।

आइए डेटा अखंडता से संबंधित उन मुद्दों की समीक्षा करें और देखें कि उन्हें कैसे हल किया जाए। ध्यान दें कि हमने Person.ContactType . में एक रिकॉर्ड डाला है तालिका और Person.ContactType . से 2 रिकॉर्ड हटाए गए सब्सक्राइबर डेटाबेस में तालिका। हम त्रुटियों को खोजने के लिए इन 3 अभिलेखों का उपयोग करने जा रहे हैं।

प्राथमिक कुंजी या अद्वितीय कुंजी उल्लंघन त्रुटियां

मैं Person.ContactType . पर INSERT रिकॉर्ड का परीक्षण करने जा रहा हूँ टेबल। आइए उस रिकॉर्ड को प्रकाशक डेटाबेस में डालें और देखें कि क्या होता है:

यह कैसे जाता है यह देखने के लिए प्रतिकृति मॉनिटर लॉन्च करें। हमें त्रुटि मिलती है:

प्रकाशक का विस्तार करना और प्रकाशन , हमें निम्नलिखित विवरण मिलते हैं:

यदि हमने प्रतिकृति अलर्ट कॉन्फ़िगर किया है और संबंधित व्यक्तियों को उनकी मेल अलर्ट प्राप्त करने के लिए असाइन किया है, तो हमें त्रुटि संदेश के साथ उपयुक्त ईमेल सूचनाएं प्राप्त होंगी:ऑब्जेक्ट 'Person.ContactType' में अद्वितीय अनुक्रमणिका 'AK_ContactType_Name' के साथ एक डुप्लिकेट कुंजी पंक्ति सम्मिलित नहीं कर सकता ' . डुप्लिकेट कुंजी मान (परीक्षण स्थिति) है। (स्रोत:MSSQLServer, त्रुटि संख्या:2601)

अद्वितीय कुंजी उल्लंघनों या प्राथमिक कुंजी मुद्दों से संबंधित समस्या को हल करने के लिए, हमारे पास कई विकल्प हैं:

• विश्लेषण करें कि यह त्रुटि क्यों हुई है, सब्सक्राइबर डेटाबेस में रिकॉर्ड कैसे उपलब्ध था, और इसे किसने किन कारणों से डाला। पहचानें कि यह आवश्यक था या नहीं।
• स्काइपर्सजोड़ें त्रुटि संख्या 2601 को छोड़ने के लिए वितरण एजेंट प्रोफ़ाइल के पैरामीटर या त्रुटि संख्या 2627 प्राथमिक कुंजी उल्लंघन के मामले में।

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

DELETE from Person.ContactType
where ContactTypeID = 21

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

हम वितरण एजेंट की नौकरी . में बदलाव करके इसे लागू कर सकते हैं > कदम > रन एजेंट नाम के 2 जॉब स्टेप पर क्लिक करें > क्लिक करें संपादित करें उपलब्ध कमांड देखने के लिए:

अब, -SkipErrors 2601 जोड़ें अंत में कीवर्ड (2601 त्रुटि संख्या है - हम प्रतिकृति के भाग के रूप में प्राप्त किसी भी त्रुटि संख्या को छोड़ सकते हैं) और ठीक पर क्लिक करें ।

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

The Replication Monitor displays that one of the error records is skipped from the Replication, that started working fine.

Since the Replication issue is resolved successfully, we’d recommend removing the -SkipErrors parameter from the Distribution Agent job. Then, restart the job to get the changes reflected.

Thus, we’ve fixed the replication issue, but let’s compare the data across the same Person.ContactType in the Publisher and Subscriber databases. The results show the data variance, or the data integrity issue :

ModifiedDate is different across the Publisher and Subscriber databases. It happens because the data in the Subscriber database was inserted earlier (when we were preparing the test data), and the data in the Publisher database has just been inserted.

If we deleted the record from the Subscriber database, the record from the Publisher would have been inserted to match the data across the Publisher and the Subscriber databases.

Most of the newbie DBAs simply add the -SkipErrors option to get the replication working immediately without detailed investigations of the issue. Hence, it is recommended not to use the -SkipErrors option as a primary solution without proper examination of the problem. The Person.ContactType table had only 3 columns. Assume that the table has over 20 columns. Then, we have just screwed up the Data integrity of this table with that -SkipErrors आदेश।

We used this approach just to illustrate the usage of that option. The best way is to examine and clarify the reason for variance and then perform the appropriate DELETE statements on the Subscriber database to maintain the Data Integrity across the Publisher and Subscriber databases.

Row Not Found Errors

Let’s try to perform an UPDATE on one of the records that were deleted from the Subscriber database:

Let’s check the Replication Monitor to see the performance. We have the following error:

The row was not found at the Subscriber when applying the replicated UPDATE command for Table ‘[Person].[ContactType]’ with Primary Key(s):[ContactTypeID] =19 (Source:MSSQLServer, Error number:20598).

There are two ways to resolve this error. First, we can use -SkipErrors for Error Number 20598 . Or, we can INSERT the record with ContactTypeID =19 (shown in the error message) to get the data changes reflected.

If we skip this error, we’ll lose the record with ContactTypeId =19 from the Subscriber database permanently. It can cause data inconsistency issues. Hence, we aren’t going to use the -SkipErrors विकल्प। Instead, we’ll apply the INSERT approach.

The Replication resumes correctly by sending the UPDATE to the Subscriber database.

It is the same when we try to delete the ContactTypeId =20 from the Publisher database and see the error popping up in the Replication Monitor.

The Replication Monitor shows us a message similar to the one we already noticed:

The row was not found at the Subscriber when applying the replicated DELETE command for Table ‘[Person].[ContactType]’ with Primary Key(s):[ContactTypeID] =20 (Source:MSSQLServer, Error number:20598)

Similar to the previous error, we need to identify the missing record and insert it back to the Subscriber database for the DELETE statement to get replicated properly. For DELETE scenario, using -SkipErrors doesn’t have any issues but can’t be considered as a safe option, as both missing UPDATE or missing DELETE record are captured with the same error number 20598 and adding -SkipErrors 20598 will skip applying all records from the Subscriber database.

We can also get more details about the problematic command by using the sp_browsereplcmds stored procedure which we have discussed earlier as well. Let’s try to use sp_browsereplcmds stored procedure for the previous error we have received out as shown below.

exec sp_browsereplcmds @xact_seqno_start = '0x000000A500001160000600000000'
			, @xact_seqno_end = '0x000000A500001160000600000000'
			, @publisher_database_id = 1
			, @command_id = 1

@xact_seqno_start and @xact_seqno_end will be the same value. We can fetch that value from the Transaction Sequence number in the Replication Monitor along with Command ID.

@publisher_database_id can be fetched from the id column of the distribution..MSPublisher_databases DMV.

select * from MSpublisher_databases 

Foreign Key or Other Constraint Violation Errors

The error messages related to Foreign keys or any other data issues are slightly different. Microsoft has made these error messages detailed and self-explanatory for anyone to understand what the issue is about.

To identify the exact command that was executed on the Publisher and resolve it efficiently, we can use the sp_browsereplcmds procedure explained above and identify the root cause of the issue.

Once the commands are identified as INSERT/UPDATE/DELETE which caused the errors, we can take corresponding actions to resolve the problems correctly which is more efficient compared to simply adding -SkipErrors approach. Once corrective measures are taken, Replication will start resuming fine immediately.

Word of Caution Using -SkipErrors Option

Those who are comfortable using -SkipErrors option to resolve error quickly should remember that -SkipErrors option is added at the Distribution agent level and applies to all Published articles in that Publication. Command -SkipErrors will result in skipping any number of commands related to that particular error across all published articles any number of times resulting in discrepancies we have seen in demo resulting in data discrepancies across Publisher and Subscriber without knowing how many tables are having discrepancies and would require efforts to compare the tables and fix it out.

निष्कर्ष

Thanks for going through another robust article. I hope it was helpful for you to understand the SQL Server Transactional Replication issues and methods of troubleshooting them. In our next article, we’ll continue the discussion about the SQL Transaction Replication issues, examine other types, such as Corruption-related issues, and learn the best methods of handling them.