एक मिररिंग सत्र के समय विफल होने का कारण क्या हो सकता है?

हमारे पास संचयी अद्यतन के साथ SQL सर्वर 2005 SP4 चलाने वाले दो उत्पादन SQL सर्वर हैं। दोनों सर्वर भौतिक मशीनों पर चलते हैं जो समान हैं। डेल PowerEdge R815 4 x 12 कोर CPU और 512GB (हाँ GB) के साथ, 10GB iSCSI SAN सभी SQL डेटाबेस और लॉग के लिए कनेक्टेड ड्राइव के साथ। OS Microsoft Windows Server 2008 R2 एंटरप्राइज़ संस्करण है जिसमें सभी SP और विंडोज़ अपडेट हैं। ओएस ड्राइव 3 x 72 जीबी 2.5 "15k एसएएस ड्राइव का एक RAID 5 सरणी है। सैन 48 एक्स 10 के एसएएस 3.5" ड्राइव के साथ एक डेल इक्वलोगिक 6510 है, RAID 50 में कॉन्फ़िगर किया गया, 2 एसक्यूएल समर्थकों के लिए विभिन्न एलयूएन में कटा हुआ है और साझा भी किया गया है। एक एक्सचेंज मशीन और कई VMWare सर्वर के साथ।

हमारे पास 20 से अधिक डेटाबेस हैं, जिनमें से 11 को साक्षी सर्वर का उपयोग करके उच्च उपलब्धता के साथ प्रतिबिंबित किया जाता है। साक्षी सर्वर SQL सर्वर इंस्टेंस को चलाने वाली एक कम शक्ति वाली मशीन है जिसका उपयोग गवाह सेवाएं प्रदान करने के अलावा और कुछ नहीं के लिए किया जाता है। सबसे बड़ा प्रतिबिम्बित डेटाबेस 450GB है और लगभग 100-300 iops उत्पन्न करता है। डेटाबेस मिररिंग मॉनिटर एक वर्तमान भेजने की दर को 100kb से 10mb प्रति सेकंड के आसपास बताता है, और (आमतौर पर) 0 मिलीसेकंड के ऊपर एक दर्पण प्रतिबद्ध होता है। दर्पण सर्वर को प्रिंसिपल के साथ रखने में कोई समस्या नहीं है।

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

मैं समस्या की पहचान करने के प्रयास के लिए कई समस्या निवारण चरणों से गुजरा हूं, लेकिन अभी तक समस्या का समाधान नहीं कर पाया है:

1) मशीन एक ब्रॉडकॉम बीसीएम 5709 सी नेटएक्सट्रीम II 4 पोर्ट गीगाबिट नेटवर्क एडेप्टर के साथ आई थी जिसे हमने शुरू में प्राथमिक नेटवर्क कनेक्शन के रूप में इस्तेमाल किया था। हमने NIC को समस्या के रूप में समाप्त करने के लिए दोनों मशीनों पर Intel (R) PRO / 1000 PT दोहरी पोर्ट सर्वर एडाप्टर स्थापित किया है।

2) मिररिंग में शामिल डेटाबेस के लिए लॉग बैकअप के साथ सभी डेटाबेस में रात में एक स्वचालित पूर्ण बैकअप होता है। लॉग फ़ाइल के उपयोग की निगरानी की जाती है और शायद ही कभी इसका उपयोग 15% से ऊपर हो जाता है। मुख्य डेटाबेस के लिए लॉग फ़ाइल 125GB है, जिसमें 159 आभासी लॉग फाइलें शामिल हैं, जो आकार में 511MB से 1GB तक हैं। TempDB यह अपने LUN पर है, और इसमें 24 x 2GB फाइलें हैं।

3) गवाह पर SQL सर्वर लॉग के अलावा कोई त्रुटि नहीं दिखाता है: "TCP: //SQL02.DOMAIN.INET: 5022" के लिए मिररिंग कनेक्शन 30 सेकंड के बाद प्रतिक्रिया के बिना डेटाबेस "डेटा" के लिए समय समाप्त हो गया है। सेवा और नेटवर्क कनेक्शन की जाँच करें।

प्राथमिक और द्वितीयक सर्वर पर SQL सर्वर लॉग मिररिंग से संबंधित संदेश दिखाते हैं:

"TCP: //SQL01.DOMAIN.INET: 5022" का मिररिंग कनेक्शन 30 सेकंड के बाद प्रतिक्रिया के बिना डेटाबेस "डेटा" के लिए समाप्त हो गया है। सेवा और नेटवर्क कनेक्शन की जाँच करें।

मिरर किए गए डेटाबेस "डेटा" रोल सिंक के कारण "PRINCIPAL" से "MIRROR" में भूमिकाएं बदल रहा है। (सिंक्रनाइज़ेशन यहाँ उद्देश्य पर गलत वर्तनी है क्योंकि यह वास्तविक संदेश कैसे प्रदर्शित होता है।)

मिरर किए गए डेटाबेस "डेटा" फेलओवर के कारण "PRINCIPAL" से "MIRROR" में भूमिकाएं बदल रहा है।

मिरर किए गए डेटाबेस "डेटा" पार्टनर से फेलओवर के कारण "MIRROR" से "PRINCIPAL" में भूमिकाएं बदल रहा है।

SQL सर्वर सेवाएँ चलती रहती हैं और नेटवर्क कनेक्शन बना रहता है। हमारे पास लगातार प्रत्येक सर्वर से जुड़े 500 से 2500 सत्र हैं (मुख्य रूप से रोबोट अनुप्रयोग जो एकल डेटाबेस पर सेवा दलाल कतारों से जुड़ते हैं)।

4) टीसीपी चिमनी और आरएसएस आदि को नेट एसएच सिंटैक्स का उपयोग करके अक्षम किया गया है।

5) मैंने दोनों मशीनों के खिलाफ SQL सर्वर 2005 सर्वश्रेष्ठ अभ्यास विश्लेषक चलाया है और बहुत सामयिक अनुप्रयोग ईवेंट लॉग त्रुटि 833 के अलावा और कुछ नहीं पाया, जिनमें से कोई भी असफल घटनाओं के साथ संयोग नहीं है:

SQL सर्वर ने डेटाबेस [डेटा] (9) में फ़ाइल [F: \ Data.MDF] को पूरा करने में I / O अनुरोधों की 1 घटना (15) से अधिक समय लिया है। OS फ़ाइल हैंडल 0x00000000000010A0 है। नवीनतम आई / ओ की ऑफसेट है: 0x000007d4b10000)।

6) कभी-कभी हम देखते हैं "क्लाइंट SPID XXX के साथ एक सत्र का पुन: उपयोग करने में असमर्थ था, जो कनेक्शन पूलिंग के लिए रीसेट किया गया था। यह त्रुटि पहले के ऑपरेशन विफल होने के कारण हो सकती है। इस त्रुटि संदेश से पहले तुरंत विफल संचालन के लिए त्रुटि लॉग की जाँच करें। । " दोनों सर्वर द्वारा उत्पन्न। ऐसा प्रतीत होता है कि कोई "पहले" संदेश नहीं हैं जो किसी भी समस्या का संकेत देते हैं।

7) कभी-कभी डेटाबेस मेल एप्लिकेशन ईवेंट लॉग में एक त्रुटि लिखता है:

अपवाद प्रकार: Microsoft.SqlServer.Management.SqlIMail.Server.Common.BaseException संदेश: कनेक्शन पर कोई त्रुटि थी। कारण: समय समाप्त हो गया। ऑपरेशन पूरा होने से पहले का समय समाप्त हो गया है या सर्वर जवाब नहीं दे रहा है।, कनेक्शन पैरामीटर: सर्वर नाम: MGSQL02, डेटाबेस का नाम: msdb डेटा: System.Collections.ListDictionaryInternal TargetSite: Void OpenConnection (Microsoft.SqlServer.Management.Common)। SqlConnectionInfo) हेल्पलिंक: पूर्ण स्रोत: DatabaseMailEngine

StackTrace सूचना Microsoft.qlServer.Management.SqlIMail.Server.DataAccess.ConnectionManager.OpenConnection (SqlConnectionInfo ci) पर Microsoft। ) Microsoft.SqlServer.Management.SqlIMail.IMailProcess.QueueItemProcesser.ProcessQueueItems (स्ट्रिंग dbName, स्ट्रिंग dbServerName, Int32 LifeMinimumSec, LogLevel लॉगिंग लिवेल) पर

मेरा मानना है कि टाइमआउट असफलता का कारण बन रहे हैं; इन समयबाह्य का क्या कारण हो सकता है? जाहिर है कि अगर कोई वास्तविक नेटवर्क समस्या थी जैसे कि एक खराब केबल, या एक बुरा स्विच, जो पैकेट हानि का कारण हो सकता है और इसलिए समयबाह्य हो सकता है, हालांकि अन्य चीजें क्या समयबाह्य हो सकती हैं? ब्लॉक कर रहा है? यदि MSDB, या कुछ अन्य सिस्टम डेटाबेस में I / O टाइमआउट था, जो मिररिंग फेलओवर का कारण बन सकता है?

किसी भी सलाह के लिए धन्यवाद!

MSDN के पास टाइमआउट तंत्र के बारे में कहने के लिए निम्नलिखित हैं :

मिररिंग टाइम-आउट तंत्र

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

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

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

netsh interface tcp show global दिखाता है:

Receive-Side Scaling State          : disabled
Chimney Offload State               : disabled
NetDMA State                        : enabled
Direct Cache Acess (DCA)            : disabled
Receive Window Auto-Tuning Level    : disabled
Add-On Congestion Control Provider  : ctcp
ECN Capability                      : disabled
RFC 1323 Timestamps                 : disabled

netsh interface ipv4 show dynamicportrange tcp

Protocol tcp Dynamic Port Range

Start Port      : 1025
Number of Ports : 64510

SELECT name, value_in_use FROM sys.configurations

    तदर्थ वितरित प्रश्न ०         
    आत्मीयता I / O मास्क 0         
    आत्मीयता का मुखौटा ०         
    affinity64 I / O मास्क 0         
    आत्मीयता का मुखौटा ०         
    एजेंट XP 1         
    अद्यतन की अनुमति दें 0         
    विस्मय सक्षम 0         
    अवरुद्ध प्रक्रिया दहलीज 5         
    c2 ऑडिट मोड 0         
    clr सक्षम 1         
    सामान्य मानदंड अनुपालन सक्षम 0         
    समानता 4 के लिए लागत सीमा         
    क्रॉस डीबी स्वामित्व चाइनिंग 0         
    कर्सर दहलीज -1        
    डेटाबेस मेल XPs 1         
    डिफ़ॉल्ट पूर्ण-पाठ भाषा 1033      
    डिफ़ॉल्ट भाषा ०         
    डिफ़ॉल्ट ट्रेस सक्षम 1         
    ट्रिगर से परिणामों को अस्वीकार करें 0         
    भरने का कारक (%) 0         
    फुट क्रॉल बैंडविड्थ (अधिकतम) 100       
    फुट क्रॉल बैंडविड्थ (न्यूनतम) 0         
    फीट सूचित बैंडविड्थ (अधिकतम) 100       
    फुट सूचित बैंडविड्थ (न्यूनतम) 0         
    index create memory (KB) 0         
    इन-शक xact संकल्प 0         
    हल्का पूलिंग 0         
    ताले ०         
    समानता 6 की अधिकतम डिग्री         
    अधिकतम पूर्ण-पाठ क्रॉल श्रेणी 4         
    अधिकतम सर्वर मेमोरी (एमबी) 393216    
    अधिकतम पाठ उत्तर आकार (B) 65536     
    अधिकतम कार्यकर्ता धागे 0         
    मीडिया प्रतिधारण 0         
    न्यूनतम स्मृति प्रति क्वेरी (KB) 2048      
    मिनट सर्वर मेमोरी (एमबी) 52427     
    नेस्टेड ट्रिगर्स 1         
    नेटवर्क पैकेट का आकार (B) 1400      
    Ole स्वचालन प्रक्रिया 1         
    खुली हुई वस्तु ०         
    PH टाइमआउट (एस) 60        
    precompute रैंक 0         
    प्राथमिकता में वृद्धि ०         
    क्वेरी गवर्नर लागत सीमा 0         
    क्वेरी प्रतीक्षा (s) -1        
    वसूली अंतराल (मिनट) 0         
    दूरस्थ पहुंच १         
    दूरस्थ व्यवस्थापक कनेक्शन 0         
    दूरस्थ लॉगिन टाइमआउट (s) 20        
    दूरस्थ खरीद ट्रांस 0         
    दूरस्थ क्वेरी टाइमआउट (एस) 600       
    प्रतिकृति XPs 0         
    स्टार्टअप procs 0 के लिए स्कैन करें         
    सर्वर ट्रिगर पुनरावृत्ति 1         
    काम कर रहे सेट का आकार ०         
    उन्नत विकल्प दिखाएं 1         
    एसएमओ और डीएमओ एक्सपी 1         
    SQL मेल XP 0         
    शोर शब्द बदलना 0         
    दो अंकों का वर्ष कटऑफ 2049      
    उपयोगकर्ता कनेक्शन 0         
    उपयोगकर्ता विकल्प 4216      
    वेब सहायक प्रक्रिया 0         
    xp_cmdshell 1

कुछ समय पहले, मैंने मैन्युअल रूप mirroring_connection_timeoutसे समस्या को दूर करने के लिए सभी प्रतिबिंबित डेटाबेस के लिए मूल्य को 30 सेकंड में संशोधित किया; यह बस विफलता घटनाओं के बीच समय की मात्रा में वृद्धि हुई है। mirroring_connection_timeout10 सेकंड के डिफ़ॉल्ट पर सेटिंग सेट के साथ , हम बहुत अधिक विफलताओं को देखते हैं ।

एक टिप्पणी ने मुझे यह सुनिश्चित करने के लिए कहा था कि IPSec अक्षम है, इसलिए मैं कई netshकमांड की सामग्री पोस्ट कर रहा हूं जो ऑपरेटिंग सिस्टम के IPSec कॉन्फ़िगरेशन को प्रदर्शित करता है:

C: \> netsh ipsec डायनामिक शो सभी
वर्तमान में कोई नीति नहीं दी गई है
मेनमोड नीतियां उपलब्ध नहीं हैं।
क्विकमोड नीतियां उपलब्ध नहीं हैं।
जेनेरिक मेनमोड फिल्टर उपलब्ध नहीं है।
विशिष्ट मेनमोड फिल्टर उपलब्ध नहीं हैं।
जेनेरिक क्विकमोड फिल्टर उपलब्ध नहीं है।
विशिष्ट क्विकमोड फ़िल्टर उपलब्ध नहीं हैं।
IPsec MainMode Security Associates उपलब्ध नहीं हैं।
IPsec QuickMode सुरक्षा संघ उपलब्ध नहीं हैं।

IPsec कॉन्फ़िगरेशन पैरामीटर
------------------------------
स्ट्रांग सर्किल: 1
IPsecexempt: 3

IPsec सांख्यिकी
----------------
सक्रिय Assoc: 0
उतार भार: ०
लंबित कुंजी: 0
कुंजी जोड़ता है: 0
प्रमुख दोष: ०
ReKeys: 0
सक्रिय सुरंग: 0
खराब एसपीआई Pkts: 0
Pkts अस्वीकृत नहीं: 0
Pkts प्रमाणित नहीं: 0
रिप्ले डिटेक्शन के साथ पीकेटी: 0
गोपनीय बाइट भेजे गए: 0
गोपनीय बाइट्स प्राप्त: 0
प्रमाणित बाइट्स भेजे गए: 0
प्रमाणित बाइट्स प्राप्त: 0
परिवहन बाइट्स भेजे गए: 0
परिवहन बाइट्स प्राप्त: 0
सुरंगों में भेजे गए बाइट्स: 0
बाइट्स सुरंगों में प्राप्त: 0
भेजा गया बाइट्स: 0
ऑफलोड किए गए बाइट्स प्राप्त: 0

C: \> netsh ipsec स्थिर शो
ERR IPsec [05072]: पॉलिसी स्टोर में कोई नीतियां नहीं

अद्यतन: 2012-12-20

हमने अब SQL Server 2012 पर अपने उत्पादन सिस्टम को स्थानांतरित कर दिया है। हम इसे 17 दिसंबर की सुबह से चला रहे हैं - अभी तक कोई भी विफल नहीं है। हालाँकि, कुछ दिनों के भीतर अच्छी तरह से है जो हमने 2005-आधारित प्रणालियों के साथ देखा था।

हमारे नए सिस्टम के प्रदर्शन का दस्तावेजीकरण करने के प्रयास में, मैं sys.dm_os_wait_statsअधिक ध्यान से देख रहा हूं ; और ध्यान दिया गया DBMIRROR_DBM_EVENT, जो एक अनिर्धारित प्रतीक्षा प्रकार है। Microsoft में ग्राहम केंट में अनपेक्षित विफलताओं और इस प्रतीक्षा प्रकार के निवारण के बारे में एक दिलचस्प लेख है । मैं उनके निष्कर्ष यहाँ लाऊँगा:

ग्राहक एक उच्च मात्रा वाले OLTP डेटाबेस पर निर्मित एक विशाल अवरोधन श्रृंखला का अनुभव कर रहा था, जहाँ सभी हेड ब्लॉकर DBMIRROR_DBM_EVENT पर प्रतीक्षा कर रहे थे। यहाँ उन घटनाओं का क्रम है जिनसे मैं गुज़रा:

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

(ए) [बैकअपसेट] तालिका को देखें कि क्या समस्या के समय निर्मित लॉग का आकार सामान्य से अधिक है या नहीं। यदि वे असाधारण रूप से बड़े थे तो यह हो सकता है कि दर्पण लेन-देन से भर गया था और बस वॉल्यूम के साथ नहीं रख सकता था। यही कारण है कि पुस्तकें ऑनलाइन आपको कभी-कभी मिररिंग को अक्षम करने के लिए कहेंगी यदि आपको एक असाधारण बड़े लॉग ऑपरेशन जैसे कि एक इंडेक्स पुनर्निर्माण करने की आवश्यकता है। (यह http://technet.microsoft.com/en-us/library/cc917681.aspx पर क्यों है के लिए संदर्भ )। यहाँ मैंने निम्नलिखित TSQL का इस्तेमाल किया

SELECT backup_set_id,backup_start_date,database_name,has_bulk_logged_data,backup_size / 1000
FROM [backupset]
where backup_start_date between '2011-01-05 14:00:00' and '2011-01-05 19:30:00'
go

select round((AVG(backup_size)/1000),0)
FROM [backupset]
where database_name = 'mydatabase'

(b) दूसरी बात मैंने डेटा को तालिकाओं [dbm_monitor_data] में देखा। यहाँ कुंजी उस समय-सीमा का पता लगाना है जिसमें हमें कोई समस्या थी और फिर देखें कि क्या हम निम्नलिखित में से किसी में भी महत्वपूर्ण परिवर्तन का अनुभव कर रहे हैं:

log_flush_rate
send_queue_size
send_rate
redo_queue_size
redo_rate

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

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

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

डिफ़ॉल्ट ट्रेस फ़ाइलों की समीक्षा करें - इस परिदृश्य में मुझे डिफ़ॉल्ट निशान प्रदान नहीं किए गए थे, हालांकि वे डीबीएम समस्या की जानकारी के शानदार स्रोत हैं, क्योंकि वे सभी भागीदारों पर राज्य परिवर्तन की घटनाओं को दर्ज करते हैं। यह यहां दर्ज़ है:

डेटाबेस मिररिंग स्टेट चेंज इवेंट क्लास

यह अक्सर आपको परिदृश्यों की एक शानदार तस्वीर देता है जैसे कि जब एक या सभी भागीदारों के बीच नेटवर्क कनेक्टिविटी विफल हो गई और फिर साझेदारी की स्थिति आगे क्या हो गई।

निष्कर्ष:

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

कुछ या सभी भागीदारों के बीच कनेक्टिविटी पर हार्डवेयर समस्याएं।
दर्पण सर्वर पर सीपीयू थकावट - केवल रीडोस के साथ रखने में असमर्थ - सीपीयू थकावट स्वयं SQL सर्वर के बाहर या इस दर्पण साझेदारी के बाहर की प्रक्रिया से हो सकती है।
मिररिंग कोड के साथ एक समस्या (हमें वास्तव में इसकी पुष्टि के लिए कुछ मेमोरी डंप की आवश्यकता होगी)।

अनुभव के आधार पर मुझे 1 या 2 पर संदेह होगा, लेकिन मैं हमेशा 3 के बारे में एक खुला दिमाग रखता हूं, हम इस समस्या को और अधिक विस्तार से देखने के लिए अब कुछ और डेटा एकत्र करने की कोशिश कर रहे हैं।

— मैक्स वर्नन
स्रोत

जाँच करने के लिए एक और चीज IPSec होगी। अक्सर IPSec कनेक्शन के प्रयास में देरी या अवरोध कर सकता है। IPSec अक्षम करें यह देखने के लिए कि क्या समय समाप्त हो गया है।

— रॉबर्ट एल डेविस