SQL सर्वर कॉम्पैक्ट संस्करण डेटाबेस फ़ाइलों में भ्रष्टाचार का समाधान

Question

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

हमारा उत्पाद एक 3-स्तरीय आर्किटेक्चर है जो सर्वर के साथ रिच क्लाइंट्स से जुड़े विंडोज सेवा के रूप में चल रहा है। नेट रीमोटिंग के माध्यम से। हमारा उत्पाद 2006 से SQLCE का उपयोग करता है। हम v3.1 से v3.5 और अब v4.0 में स्थानांतरित हो गए हैं। हमारे पास कुछ विशिष्ट आवश्यकताओं के लिए कस्टम ओआर-मैपिंग टूल है। हमें v3.1 के साथ सीमित समस्याओं का सामना करना पड़ा है, हमने v3.5 और v4.0 के साथ अधिक सामना किया है।

प्रारंभ में v3.5 के साथ, हमने SqlCeEngine.Repair लागू किया। लेकिन यह केवल दूषित डेटा छोड़ देता है, और स्थिर डीबी को फिर से बनाने की कोशिश करता है। हमने पाया कि प्रभावित टेबल की विदेशी कुंजी गायब हो गई। हमें तुरंत इसके साथ दूर करना पड़ा। हमने उपयोगकर्ताओं को डीबी भ्रष्टाचार के बारे में सूचित करना शुरू किया, और अंतिम बैकअप को पुनर्स्थापित किया। यह केवल एक अस्थायी राहत प्रदान की; भ्रष्टाचार की समस्या अभी भी खड़ी थी।

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

Answer 1

यहाँ चला जाता है कि हम कैसे समस्या हल [क्वेरी और समाधान को अलग]:

ए) समापन/निपटान

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

बी) स्वत: हटना अक्षम करना: एक आवेदन चलाने के बीच में होने वाली एकमात्र प्रक्रिया, जिस पर हमारा कोई नियंत्रण नहीं था, ऑटो-हटना था। जब हम एप्लिकेशन शुरू करते हैं तो हम SqlCeEngine.Compact को कॉल कर रहे थे। हमने कॉम्पैक्टिंग और ऑटो-सिंकिंग दोनों को दूर करने का फैसला किया। और हमारे आश्चर्य के लिए, हमने भ्रष्टाचार को 48% तक घटा दिया। यह अंधेरे में एक शॉट था, और हम विश्वास नहीं कर सके कि ऑटो-श्रिंकिंग ऐसी समस्याओं का कारण बन सकती है। हमने व्यावहारिक रूप से उस अद्यतन के साथ समस्या हल की।

सी) सिंक्रनाइज़ डेटाबेस लेनदेन: कुछ डेटाबेस भ्रष्टाचार अभी भी हो रहा है। स्पष्ट कारणों से पता चला, हमने डेटाबेस लेनदेन को सिंक्रनाइज़ करने का निर्णय लिया! मुझे पता है कि बहुत सारे डेटाबेस लोग इसे पसंद नहीं करेंगे। मुझे यह पसंद नहीं है। हमने यह सुनिश्चित करने के लिए हमारे मध्य स्तर में ताले लगाए हैं कि एक ही समय में केवल एक कॉल डेटाबेस को संशोधित कर रहा है। हमारा सबसे बड़ा कार्यान्वयन 55 सिस्टम एक साथ हमारे सिस्टम का उपयोग कर रहा है। किसी भी दृश्य प्रदर्शन विलंब के परिणामस्वरूप डेटाबेस कॉल को सिंक्रनाइज़ करना मुश्किल से हुआ। इसके बजाय, सिंक्रनाइज़िंग ने हमें नियमित अंतराल पर SqlCeEngine.Compact को टाइमर-संचालित कॉल लागू करने की अनुमति दी। हम जानते थे कि कॉम्पैक्ट अपराधी नहीं था, और हमने महसूस किया कि कॉम्पैक्शन एक आवश्यक कॉल है क्योंकि यह डीबी को पुनर्निर्मित करता है (हमारा समाधान बहुत सारे आवेषण और हटा देता है)। हालांकि, इसे विशेष रूप से कार्य करने की आवश्यकता है; कॉम्पैक्ट कॉल करते समय कोई डेटाबेस कॉल नहीं करता है। सिंक्रनाइज़ेशन ने हमें एप्लिकेशन चलाने के दौरान नियंत्रित करने की अनुमति दी। चूंकि हमने ऐसा किया है, हमें एक डेटाबेस भ्रष्टाचार समस्या नहीं मिली है। यह अब एक महीने से अधिक रहा है। एक सप्ताह में लगभग 5 ग्राहकों से, एक महीने में शून्य तक।

मूल तर्क जो हमें बी और सी के विचारों का नेतृत्व करता है वह यह है कि SQLCE एक एम्बेडेड डेटाबेस है। भ्रष्टाचार प्रत्येक एम्बेडेड डेटाबेस समाधान के लिए आम हैं। एक पूर्ण पैमाने पर डेटाबेस समाधान 24x7 डीबी-सर्वर प्रबंधन कनेक्शन और अन्य कार्यों द्वारा स्वतंत्र रूप से समर्थित काम करता है। एक एम्बेडेड डेटाबेस सिस्टम में ऐसी कोई समर्थन प्रणाली नहीं है। जब एक कनेक्शन खोला जाता है तो एकमात्र चरण होता है।

कुछ और पॉइंटर्स: 1) हम CommitMode.Imedimediate के साथ प्रतिबद्धता लागू करते हैं, जो फ्लश-अंतराल की संपत्ति को अनावश्यक बनाता है। 2) ऑटोश्रिंक 100 पर सेट है, जो पूरी तरह से प्रक्रिया को अक्षम करता है 3) मैंने सिंक्रनाइज़ डेटाबेस कॉल को आसानी से काम करने की अनुमति देने के लिए कनेक्शन टाइमआउट बढ़ा दिया है। 4) आवेदन शुरू होने पर कॉम्पैक्ट कहा जाता है। ऐसे मामलों में जहां ग्राहक अपनी मशीन को बंद नहीं करते हैं, हमने टाइमर को प्रत्येक 24-घंटे कॉम्पैक्ट कॉल करने के लिए लागू किया।

आशा है कि यह पोस्ट समस्याओं को हल करने में मदद करेगी।

Answer 2

यदि SQL सर्वर सीई 4.0 का उपयोग करना एक ज्ञात समस्या है जो डेटा को डिस्क पर फ़्लश करने से रोक सकती है (सभी पर)। https://support.microsoft.com/en-us/kb/2979868 और हॉटफिक्स https://support.microsoft.com/en-us/kb/2960153

अपने स्वयं के शब्दों में:

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

हॉटफिक्स कि इस समस्या का समाधान करता है एसक्यूएल सर्वर कॉम्पैक्ट के लिए एक मांग पर हॉटफिक्स अद्यतन पैकेज में 4.0 सर्विस पैक 1. शामिल है

वैकल्पिक हल आपूर्ति ब्लॉक के चारों ओर transaction.Commit(CommitMode.Immediate) उपयोग करने के लिए आप यह सुनिश्चित करना चाहते है