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

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

हमेशा उपलब्धता पर समूह सुविधा सक्षम नहीं है

मान लें कि, SQL सर्वर प्रबंधन स्टूडियो के ऑब्जेक्ट एक्सप्लोरर के तहत, हमेशा उच्च उपलब्धता नोड से एक नया हमेशा उपलब्धता समूह बनाने का प्रयास करते समय, आपको नीचे त्रुटि संदेश का सामना करना पड़ा:

इस उदाहरण पर उपलब्धता समूह बनाने से पहले सर्वर आवृत्ति 'SQL1' के लिए हमेशा उपलब्धता समूह सुविधा सक्षम होनी चाहिए। इस सुविधा को सक्षम करने के लिए, SQL सर्वर कॉन्फ़िगरेशन प्रबंधक खोलें, SQL सर्वर सेवाएँ चुनें, SQL सर्वर सेवा नाम पर राइट-क्लिक करें, गुण चुनें, और सर्वर गुण संवाद के हमेशा उपलब्धता समूह टैब का उपयोग करें। हमेशा उपलब्धता समूहों को सक्षम करने के लिए आवश्यक हो सकता है कि सर्वर इंस्टेंस को Windows सर्वर फ़ेलओवर क्लस्टर (WSFC) नोड द्वारा होस्ट किया जाए। (Microsoft.SqlServer.Management.HadrTasks)

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

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

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

डेटाबेस पूर्व-आवश्यकता सत्यापन समस्या

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

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

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

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

उस समस्या को ठीक करने के लिए, डेटाबेस गुण विंडो के विकल्प टैब से डेटाबेस पुनर्प्राप्ति मॉडल को सरल से पूर्ण में बदलें, फिर उस डेटाबेस से पूर्ण बैकअप लें, जैसा कि नीचे दिखाया गया है:

डेटाबेस चुनें विंडो को रीफ़्रेश करते हुए, डेटाबेस स्थिति को मीट पूर्वापेक्षाओं में बदल दिया जाएगा, जैसा कि नीचे दिखाया गया है:

साझा नेटवर्क स्थान अनुमति समस्या

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

प्राथमिक सर्वर 'SQL1' '\\SQL1\AlwaysON\BackupLocDb_dbb55cb4-af89-4ed3-b189-1fcaad42358c.bak' को नहीं लिख सकता। (Microsoft.SqlServer.Management.HadrModel)

सर्वर 'SQL1' के लिए बैकअप विफल रहा। (Microsoft.SqlServer.SmoExtended)

बैकअप डिवाइस '\\SQL1\AlwaysON\BackupLocDb_dbb55cb4-af89-4ed3-b189-1fcaad42358c.bak' नहीं खोल सकता। ऑपरेटिंग सिस्टम त्रुटि 5(प्रवेश निषेध है।)

बैकअप डेटाबेस असामान्य रूप से समाप्त हो रहा है। (.Net SqlClient डेटा प्रदाता)

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

उस समस्या को ठीक करने के लिए, हमें प्राथमिक और माध्यमिक प्रतिकृतियों के SQL सर्वर सेवा खाते को त्रुटि संदेश में दिखाए गए साझा फ़ोल्डर पर पढ़ने और लिखने की अनुमति देने की आवश्यकता है, फिर सत्यापन प्रक्रिया को फिर से चलाएं, यह सुनिश्चित करने के लिए कि सभी चेक सफल हैं , जैसा कि नीचे दिखाया गया है:

Windows फ़ेलओवर क्लस्टर समस्या

मान लें कि आप मौजूदा हमेशा उपलब्धता समूह साइट की स्थिति की जांच कर रहे हैं, और देखें कि:

• प्राथमिक भूमिका को SQL1 आवृत्ति से SQL2 में स्थानांतरित कर दिया गया है।
• SQL2 में, डेटाबेस सिंक्रनाइज़ स्थिति में हैं।
• SQL1 में, डेटाबेस सिंक्रनाइज़ नहीं होते हैं।
• SQL1 समाधान की स्थिति में है।

जैसा कि आप नीचे दिए गए SSMS ऑब्जेक्ट एक्सप्लोरर से स्पष्ट रूप से देख सकते हैं:

समस्याग्रस्त नोड में SQL सर्वर त्रुटि लॉग की जाँच करते हुए, हम देख सकते हैं कि उपलब्धता समूह प्रतिकृति ऑफ़लाइन हो जाती है और Windows सर्वर फ़ेलओवर क्लस्टर में किसी समस्या के कारण उपलब्धता समूह ने काम करना बंद कर दिया है, जैसा कि नीचे दी गई त्रुटियों में दिखाया गया है:

• हमेशा उपलब्धता समूह पर:स्थानीय Windows सर्वर फ़ेलओवर क्लस्टरिंग नोड अब ऑनलाइन नहीं है . यह केवल सूचनात्मक संदेश है। किसी उपयोगकर्ता कार्रवाई की आवश्यकता नहीं है।
• हमेशा चालू:उपलब्धता प्रतिकृति प्रबंधक ऑफ़लाइन जा रहा है क्योंकि स्थानीय Windows सर्वर फ़ेलओवर क्लस्टरिंग (WSFC) नोड ने कोरम खो दिया है। यह केवल सूचनात्मक संदेश है। किसी उपयोगकर्ता कार्रवाई की आवश्यकता नहीं है।
• हमेशा चालू:उपलब्धता समूह 'डेमोग्रुप' की स्थानीय प्रतिकृति रुक ​​रही है। यह केवल सूचनात्मक संदेश है। किसी उपयोगकर्ता कार्रवाई की आवश्यकता नहीं है।

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

• हमेशा चालू:उपलब्धता समूह 'डेमोग्रुप' की स्थानीय प्रतिकृति समाधान भूमिका में संक्रमण की तैयारी कर रही है . यह केवल सूचनात्मक संदेश है। किसी उपयोगकर्ता कार्रवाई की आवश्यकता नहीं है।
• उपलब्धता समूह 'डेमोग्रुप' को पट्टा नवीनीकरण रोकने के लिए कहा जा रहा है क्योंकि उपलब्धता समूह ऑफ़लाइन हो रहा है . यह केवल सूचनात्मक संदेश है। किसी उपयोगकर्ता कार्रवाई की आवश्यकता नहीं है।
• उपलब्धता समूह 'डेमोग्रुप' में स्थानीय उपलब्धता प्रतिकृति की स्थिति 'PRIMARY_NORMAL' से 'RESOLVING_NORMAL' में बदल गई है। स्थिति बदल गई क्योंकि उपलब्धता समूह ऑफ़लाइन हो रहा है. प्रतिकृति ऑफ़लाइन जा रही है क्योंकि संबद्ध उपलब्धता समूह को हटा दिया गया है, या उपयोगकर्ता ने Windows सर्वर फ़ेलओवर क्लस्टरिंग (WSFC) प्रबंधन कंसोल में संबद्ध उपलब्धता समूह को ऑफ़लाइन ले लिया है, या उपलब्धता समूह किसी अन्य SQL सर्वर आवृत्ति पर विफल हो रहा है। अधिक जानकारी के लिए, SQL सर्वर त्रुटि लॉग या क्लस्टर लॉग देखें। यदि यह एक Windows सर्वर फ़ेलओवर क्लस्टरिंग (WSFC) उपलब्धता समूह है, तो आप WSFC प्रबंधन कंसोल भी देख सकते हैं।

Windows क्लस्टर साइट की स्थिति जाँचने के लिए, हम फ़ेलओवर क्लस्टर प्रबंधक का उपयोग यह देखने के लिए करेंगे कि Windows क्लस्टर का कौन-सा भाग विफल हो रहा है।

लेकिन फ़ेलओवर क्लस्टर प्रबंधक दिखाता है कि पूरा क्लस्टर नीचे है, जैसा कि नीचे दिखाया गया है:

विंडोज फेलओवर क्लस्टर पक्ष से यहां सत्यापित करने वाली पहली चीज क्लस्टर सेवा है, जिसे विंडोज सर्विसेज कंसोल से जांचा जा सकता है, जैसा कि नीचे दिया गया है:

सेवा कंसोल से यह स्पष्ट है कि क्लस्टर सेवा नहीं चल रही है। उस समस्या को ठीक करने के लिए, उस कंसोल से सेवा प्रारंभ करें, फिर फ़ेलओवर क्लस्टर प्रबंधक कंसोल को रीफ़्रेश करके सुनिश्चित करें कि Windows क्लस्टर साइट ऊपर और चल रही है, जैसा कि नीचे दिखाया गया है:

ऑलवेज ऑन अवेलेबिलिटी ग्रुप को फिर से चेक करने पर, आप देखेंगे कि डेटाबेस फिर से सिंक्रोनाइज़ हो गए हैं और ऑलवेज ऑन अवेलेबिलिटी ग्रुप साइट फिर से स्वस्थ स्थिति में है, जैसा कि नीचे दिखाया गया है:

लेन-देन लॉग फ़ाइल प्राथमिक रूप से भरी हुई है

मान लें कि हमेशा उपलब्धता समूह डेटाबेस में से किसी एक पर एक नई क्वेरी निष्पादित करने का प्रयास करते समय आपको निम्न त्रुटि संदेश प्राप्त होता है:

लेन-देन लॉग फ़ाइल को अवरुद्ध कर रहा है और इसे छोटा होने से रोकता है, आप देखेंगे कि इस डेटाबेस की लेनदेन लॉग फ़ाइल को छोटा करने के लिए लॉग बैकअप ऑपरेशन लंबित है, जैसा कि नीचे दिखाया गया है:

उस डेटाबेस के लिए लेन-देन लॉग बैकअप लेना, यदि आप लेन-देन लॉग बैकअप कार्य शेड्यूल करना भूल जाते हैं, तो निम्नानुसार है:

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

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

डैशबोर्ड से, आप देख सकते हैं कि द्वितीयक प्रतिकृति SQL2 प्राथमिक प्रतिकृति के साथ सिंक्रनाइज़ नहीं है, कनेक्टिविटी समस्या के कारण, जैसा कि नीचे दिखाया गया है:

सेकेंडरी रेप्लिका की जांच करना, और सुनिश्चित करना कि SQL सर्वर सर्विस सेकेंडरी साइड पर चल रही है, निम्नानुसार है:

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

हमेशा उपलब्धता समूह विफलता पर गलत कॉन्फ़िगरेशन

मान लें कि प्राथमिक प्रतिकृति एक अनियोजित समस्या के कारण ऑफ़लाइन हो जाती है। जैसा कि अपेक्षित था, सिस्टम प्रभावित नहीं होगा क्योंकि एक स्वचालित विफलता कार्रवाई की जाएगी और द्वितीयक प्रतिकृति नई प्राथमिक प्रतिकृति के रूप में कार्य करेगी।

लेकिन हमारे मामले में, यह सुखद परिदृश्य मान्य नहीं है, जहां द्वितीयक प्रतिकृति को हल करने की स्थिति में बदल दिया गया है और सिस्टम डाउन हो गया है!

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

उपलब्धता समूह डेटाबेस "AdventureWorks2017" भूमिकाओं को "SECONDARY" से "Resolving" में बदल रहा है क्योंकि भूमिका सिंक्रनाइज़ेशन के कारण मिररिंग सत्र या उपलब्धता समूह विफल हो गया है। यह केवल सूचनात्मक संदेश है। किसी उपयोगकर्ता कार्रवाई की आवश्यकता नहीं है।

इसका अर्थ है कि इस उपलब्धता समूह में उपयोग किए जाने वाले सिंक्रनाइज़ेशन मोड के साथ कोई समस्या है। उपयोग किए गए सिंक्रनाइज़ेशन मोड को हमेशा उपलब्धता समूह गुण पृष्ठ से जांचा जा सकता है।

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

इसे फ़ेलओवर मोड को स्वचालित में बदलकर आसानी से ठीक किया जा सकता है, जहाँ किसी भी अनियोजित शटडाउन या रिबूट के मामले में एक स्वचालित फ़ेलओवर ऑपरेशन किया जाएगा:

एक ही समस्या का सामना तब किया जा सकता है जब विंडोज फेलओवर क्लस्टर कोरम को समान संख्या में प्रतिकृतियों के लिए नोड बहुमत के साथ कॉन्फ़िगर किया गया है, जहां सर्वरों में से किसी एक के लिए कोई भी विफलता विंडोज फेलओवर क्लस्टर साइट को ऑफ़लाइन लाएगी। अधिक जानकारी के लिए, SQL सर्वर में हमेशा उपलब्धता समूहों पर Windows फ़ेलओवर क्लस्टर कोरम मोड की जाँच करें:

डेटा हानि के साथ विफलता

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

उस समस्या के कारण की पहचान करने के लिए, हम ऑलवेज ऑन हेल्थ इवेंट्स को ऑलवेज ऑन अवेलेबिलिटी ग्रुप डैशबोर्ड का उपयोग करके ब्राउज़ करेंगे, जो दर्शाता है कि प्राइमरी रेप्लिका सेकेंडरी रेप्लिका से कनेक्शन खोलने में सक्षम नहीं है, ऐश नीचे दिखाया गया है:

प्राथमिक और माध्यमिक के बीच कनेक्टिविटी समस्या को ठीक करने के बाद, प्रतिकृति सूची को ताज़ा करें और आप देखेंगे कि डेटा हानि की समस्या ठीक हो गई है, जैसा कि नीचे दिखाया गया है। कनेक्टिविटी समस्याओं के निवारण के बारे में अधिक जानकारी के लिए, SQL सर्वर डेटाबेस इंजन से कनेक्ट होने में समस्या निवारण की जाँच करें।

उपलब्धता समूह विलंबता पर हमेशा निगरानी करना

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

विलंबता को मापने के बारे में अधिक जानकारी के लिए, उपलब्धता समूह सिंक्रनाइज़ेशन अंतराल मापने की जाँच करें।

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

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

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

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

विलंबता रिपोर्ट के बारे में अधिक जानकारी के लिए, SSMS में नया देखें - हमेशा उपलब्धता समूह विलंबता रिपोर्ट पर।

निम्न रिपोर्ट माध्यमिक प्रतिकृति से उत्पन्न विलंबता रिपोर्ट का एक उदाहरण है, जो सामान्य लॉग परिवहन संचालन दिखाती है:

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