तेज़ VPN भी सिंक्रोनस SQL कमिट को धीमा क्यों करता है
कमिट सिंक्रोनस रेप्लिका की ओर भवन से बाहर जाता है। प्रतीक्षा प्रकार से भेजने और redo कतारों तक चलें, फिर तय करें कि असिंक्रोनस सही सौदा है या नहीं।
प्राथमिक पर क्वेरी सत्र खोलें और देखें कि साधारण लेखन किसका इंतज़ार कर रहा है। यदि डेटाबेस सिंक्रोनस कमिट वाले उपलब्धता समूह का है और द्वितीयक जुड़ा है, तो उस प्रतीक्षा का एक हिस्सा भवन से बाहर जाता है: लॉग रिकॉर्ड रेप्लिका तक जाते हैं, वहाँ कठोर किए जाते हैं, और उस कठोरता की खबर कमिट पूरा होने से पहले लौट आती है। बैंडविड्थ उस आने-जाने को छोटा नहीं करती। नीचे का विवरण स्क्रीन से दूर की डिस्क तक और वापस आने वाली पावती का पीछा करता है।
प्राथमिक पर प्रतीक्षा प्रकार से शुरू करें
दूर की रेप्लिका पर इंतज़ार करता लेखन CPU या लॉक प्रतीक्षा नहीं बल्कि लॉग से जुड़ी प्रतीक्षा के रूप में दिखता है, और लेन-देन की अवधि पंक्तियों की संख्या नहीं बल्कि आने-जाने का पीछा करती है। बहुत से छोटे कमिट इसे स्पष्ट कर देते हैं, क्योंकि हर एक यात्रा का खर्च अलग से देता है। एक बड़ा बल्क ऑपरेशन उसी लागत को एक लंबी पावती के भीतर छिपा देता है।
लिंक के बारे में कोई निष्कर्ष निकालने से पहले अपने कार्यभार को कमिट आवृत्ति के अनुसार क्रमबद्ध करें।
नेटवर्क पढ़ने से पहले रेप्लिका की स्थिति पढ़ें। महत्वपूर्ण काउंटर भेजने की कतार, redo कतार और सिंक्रोनाइज़ेशन स्थिति हैं, और मिलकर वे दिखाते हैं कि द्वितीयक साथ चल रहा है या पीछे रह रहा है। बढ़ती भेजने की कतार परिवहन की ओर इशारा करती है, जबकि बढ़ती redo कतार द्वितीयक के अपने काम या भंडारण की ओर। ये अलग-अलग मरम्मतें हैं और बैंडविड्थ जोड़ने से कोई नहीं सुधरती।
पावती का द्वितीयक तक पीछा करें
सिंक्रोनस कमिट में प्राथमिक कमिट को पूर्ण घोषित करने से पहले इस पुष्टि की प्रतीक्षा करता है कि संबंधित लॉग द्वितीयक पर कठोर किया गया है। कठोर का अर्थ लॉग में टिकाऊ है, डेटा पृष्ठों में फिर से चलाया गया नहीं। यही अंतर बताता है कि सिंक्रोनस द्वितीयक redo में पीछे क्यों रह सकता है जबकि वह कठोरता की पुष्टि करता रहता है।
मार्ग को क्रम में चलें और पूरे के बजाय हर चरण को मापें। लॉग रिकॉर्ड परिवहन से गुजरते हैं, द्वितीयक उन्हें लिखता और फ्लश करता है, और पावती उसी मार्ग से लौटती है। परिवहन में देरी, द्वितीयक का शेड्यूलिंग और द्वितीयक की लॉग-डिस्क विलंबता सब कुल में आते हैं, और केवल पहला नेटवर्क मालिक का है। जिस द्वितीयक का लॉग आयतन किसी और चीज़ से संतृप्त है, वह लिंक के खाली बैठे रहने पर भी हर कमिट को खींच सकता है।
SELECT ag.name AS ag_name, drs.database_id, drs.synchronization_state_desc,
drs.log_send_queue_size, drs.redo_queue_size
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_groups AS ag ON ag.group_id = drs.group_id;शांत दोपहर में एक बार के बजाय एक प्रतिनिधि लेखन से पहले और बाद में वह स्नैपशॉट लें। अंतर ही बताता है कि कमिट की प्रतीक्षा के दौरान कौन-सी कतार हिली।
लिंक नहीं, मार्ग मापें
थ्रूपुट परीक्षण दो ऐसे बिंदुओं के बीच क्षमता मापता है जो आपकी रेप्लिका नहीं हैं, ऐसे भार के अधीन जो आपका काम नहीं है। नेटवर्क मालिक से वास्तविक रेप्लिका मार्ग पर देरी और हानि माँगें जबकि वास्तविक ट्रैफ़िक चल रहा हो, दोनों दिशाओं में। यहाँ हानि क्षमता से अधिक मायने रखती है, क्योंकि खोया खंड पुनः प्रसारण का खर्च है और हर कमिट एक पावती का इंतज़ार करता है। डाउनलोड परीक्षण में उत्कृष्ट दिखने वाली लिंक भी बातूनी कमिट पैटर्न के लिए अनुपयुक्त हो सकती है।
मापते समय डेटाबेस परिवहन सुरक्षा और पहुँच नियंत्रण अक्षुण्ण रखें। मार्ग मापना उन्हें दरकिनार करने का कारण कभी नहीं है।
समय को अंतर्ज्ञान के बजाय काउंटरों से सहसंबंधित करें। यदि भेजने की कतार खाली रहती है और कमिट फिर भी इंतज़ार करता है, तो देरी पावती में या द्वितीयक के फ्लश में है। यदि भेजने की कतार लगातार बढ़ती है, तो सीमा परिवहन या क्षमता है। लिखें कि किस अवलोकन ने निष्कर्ष का समर्थन किया, ताकि अगला व्यक्ति बहस के बजाय माप दोहरा सके।
असिंक्रोनस मोड वास्तव में क्या बदलता है
असिंक्रोनस कमिट द्वितीयक की कठोरता-पावती की प्रतीक्षा हटा देता है, इसीलिए लेखन तेज़ होता है और इसीलिए आपकी टिकाऊपन स्थिति बदलती है। प्राथमिक उस दूर की पुष्टि के बिना लेन-देन की पुष्टि करता है। फिर द्वितीयक को पीछे रहने दिया जाता है, और वही पिछड़ना जोखिम है।
यदि लॉग के उपयोगी फेलओवर लक्ष्य तक पहुँचने से पहले प्राथमिक खो जाता है, तो उस रेप्लिका पर सेवा को बाध्य करना उन लेन-देनों को फेंक देता है जिनके बारे में एप्लिकेशन को पहले ही बता दिया गया था कि वे कमिट हो चुके हैं।
यह रिकवरी-पॉइंट निर्णय है और डेटाबेस मालिक का है, प्रदर्शन समीक्षा का नहीं। पहले सह्य डेटा-हानि विंडो तय करें, उसे संतुष्ट करने वाला मोड चुनें, फिर उसी सीमा के भीतर अनुकूलन करें। सिंक्रोनस सुरक्षा बनाए रखने वाले विकल्पों में एप्लिकेशन जहाँ अनुमति दे वहाँ टाले जा सकने वाले कमिट दौरों को हटाना, मापे गए परिवहन या भंडारण अवरोध को ठीक करना, और रेप्लिका को खिसकाना शामिल है ताकि पावती कम दूरी तय करे। जिस टिकाऊपन आवश्यकता से आपने शुरू किया था और जो बदली नहीं है, उसके विरुद्ध इन्हें तौलें।