ईआरपी के लिए सबसे अच्छा डिफ़ॉल्ट लेनदेन अलगाव स्तर क्या है, यदि कोई है?

Question

लघु पृष्ठभूमि: हम सिर्फ विस्थापित करने के लिए/हाइबरनेट साथ जावा के लिए एक ERP प्रणाली reimplement, प्रणाली का उपयोग कर 50-100 उपयोगकर्ताओं का एक समवर्ती उपयोगकर्ता की संख्या को निशाना बनाने शुरू कर रहे हैं। हम डेटाबेस सर्वर के रूप में एमएस एसक्यूएल सर्वर का उपयोग करते हैं, जो इस भार के लिए पर्याप्त है।

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

अब सवाल: एक अच्छा/उचित डिफ़ॉल्ट एक ईआरपी सिस्टम के लिए उपयोग करने के लिए लेनदेन अलगाव स्तर क्या होगा, लगभग 85% ओएलटीपी और 15% ओलाप के उपयोग के बाद? या क्या मुझे हमेशा प्रति कार्य आधार पर निर्णय लेना चाहिए, किस लेनदेन स्तर का उपयोग करना है?

और एक चेतावनी के रूप में चार लेन-देन अलगाव का स्तर: पढ़ें अप्रतिबद्ध, पढ़ें प्रतिबद्ध है, repeatable पढ़ें, serializable

Answer 1

100 में से 99 बार, पढ़ने के लिए प्रतिबद्ध सही जवाब है। यही कारण है कि यह सुनिश्चित करता है कि आप केवल परिवर्तन है कि अन्य सत्र द्वारा प्रतिबद्ध किया गया है देखते हैं (और, इस प्रकार, परिणाम है कि संगत कर रहे हैं, तो आप अपने लेन-देन को सही ढंग से तैयार किया है यह सोचते हैं)। लेकिन यह ताला भूमि के ऊपर लागू नहीं करता (विशेष रूप से गैर Oracle डेटाबेस में) है कि repeatable पढ़ने या serializable थोपना।

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

सीरियलज़ेबल और दोहराने योग्य पढ़ने का कभी-कभी उपयोग किया जाता है जब आपके पास ऐसी प्रक्रिया होती है जिसे पूरे रन पर डेटा के लगातार सेट को देखने की आवश्यकता होती है, भले ही उस समय अन्य लेन-देन क्या कर रहे हों। यह एक माह के अंत में सुलह प्रक्रिया, उदाहरण के लिए, serializable करने के लिए सेट करने के लिए अगर वहाँ procedureal कोड का एक बहुत, एक संभावना है कि उपयोगकर्ताओं को जबकि प्रक्रिया चल रही है बदलाव करने जा रहे हैं और एक आवश्यकता है कि इस प्रक्रिया की जरूरत है उपयुक्त हो सकता है यह सुनिश्चित करें कि यह हमेशा डेटा को देख रहा है क्योंकि समझौता शुरू होने के समय अस्तित्व में था।

Answer 2

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

Answer 3

SNAPSHOT के बारे में मत भूलना, जो नीचे से नीचे है।

यह इस बात पर निर्भर करता है कि रिपोर्ट में डेटा सटीक होना कितना महत्वपूर्ण है। यह वास्तव में एक कार्य-कार्य-कार्य चीज है।

Answer 4

यह वास्तव में आपके एप्लिकेशन को डिज़ाइन करने के तरीके पर निर्भर करता है, आसान उत्तर केवल READ_COMMITTED पर चलाया जाता है।

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

आपके प्रश्नों को प्रभावित करने के तरीके अलगाव स्तर आपके लक्षित डेटाबेस पर निर्भर करता है। Sybase और MSSQL की तरह उदाहरण डेटाबेस अधिक संसाधनों लॉक कर देना चाहिए के लिए आप READ_COMMITTED चलते हैं तो, ओरेकल जैसे डेटाबेस से।

Answer 5

असामान्य पढ़ें निश्चित रूप से अधिकांश मंचों में अंडरगॉग है।हालांकि, इसका उपयोग करने के कई कारण हैं जो "गति बनाम शुद्धता" के मामले से परे जाते हैं जिन्हें अक्सर इंगित किया जाता है।

मान लीजिए कि आप करते हैं:

• लेनदेन टी 1: बी लिखते हैं, एक पढ़ता है, (कुछ और काम), प्रतिबद्ध होते हैं।
• लेनदेन टी 2: लिखता है ए, पढ़ता है बी, (कुछ और काम), Commit।

पढ़ने के साथ, ऊपर दिए गए लेनदेन तब तक जारी नहीं होंगे जब तक कि काम नहीं किया जाता। फिर आप ऐसी परिस्थिति में भाग सकते हैं जहां टी 1 टी 2 को रिलीज करने के लिए टी 2 की प्रतीक्षा कर रहा है, और टी 2 टी को रिलीज करने के लिए टी 1 की प्रतीक्षा कर रहा है। यहां दो लेनदेन लॉक में टकराते हैं।

आप इस परिदृश्य से बचने के लिए उन प्रक्रियाओं को फिर से लिख सकते हैं (उदाहरण: हमेशा वर्णमाला क्रम में संसाधन प्राप्त करें!)। फिर भी, बहुत से समवर्ती उपयोगकर्ताओं और कोड की हजारों लाइनों के साथ, यह समस्या निदान और हल करने के लिए बहुत संभव और बहुत मुश्किल हो सकती है।

विकल्प असामान्य पढ़ें का उपयोग कर रहा है। फिर आप अपने लेन-देन को मानते हैं कि गंदा पढ़ा जा सकता है। मैं व्यक्तिगत रूप से इस समस्या को इंटरलॉकिंग रेलवे की तुलना में अधिक स्थानीय और इलाज योग्य पाते हैं।

गंदा से मुद्दों पढ़ने से

• (1) रोलबैक रोका जा सकता है: नहीं। हार्डवेयर विफलता, नेटवर्क विफलता या प्रोग्राम क्रैश के मामले में यह रक्षा की आखिरी पंक्ति होनी चाहिए।

• (2) एक ताला तंत्र है जो अमूर्त के एक उच्च स्तर है, जहां प्रत्येक ताला एक वास्तविक दुनिया संसाधन या कार्रवाई के करीब है पर संचालित बनाने के लिए आवेदन ताले का प्रयोग करें।