एक संस्करण में जियोडेटाबेस, डेल्टा तालिकाओं और राज्य के पेड़ के क्वेरी प्रदर्शन पर क्या प्रभाव डालते हैं?


9

हमारे पास एक काफी जटिल डेटा मॉडल के साथ एक वर्गाकार आर्क्सड जियोडैटेबेस (आर्कगिस 9.3.1 ऑर्केल 10 जी) है, जिसमें लगभग 100 फीचरक्लास और गैर-स्थानिक तालिकाओं, एक ज्यामितीय नेटवर्क और कई संबंध वर्ग शामिल हैं।

डेटा को रोजाना 5 या 6 arcmap उपयोगकर्ताओं द्वारा संपादित किया जाता है, जो sd वर्जनिंग का उपयोग करता है। इसके अलावा संस्करण स्वचालित सेवाओं द्वारा बनाए जाते हैं जो कि अन्य व्यावसायिक प्रणालियों के साथ जियोडैटबेस में संपादन करने के लिए इंटरफ़ेस करते हैं। क्वेरी प्रदर्शन दिन के दौरान विशेष रूप से विकृत हो जाता है, इसलिए हमने एक पूर्ण संपीड़ित प्राप्त करने के लिए एक रात की स्क्रिप्ट को लागू किया है। ऐसे अवसरों पर जब अपेक्षाकृत बड़ी संख्या में संपादन किए जाते हैं, तो सिस्टम पूरी तरह से संपीड़ित होने तक अनुपयोगी हो सकता है।

इसका सुझाव दिया गया है कि कॉन्फ़िगर के रूप में ओरेकल इन अस्थिर डेल्टा तालिकाओं के साथ सामना करने पर सभ्य निष्पादन योजनाओं के साथ नहीं आ सकता है। क्या यह एक उचित स्पष्टीकरण है? इसे हल करने के लिए क्या दृष्टिकोण अपनाया जाना चाहिए?

टिप्पणियों के जवाब में अपडेट करें

  • दिन के अंत तक, राज्य का पेड़ बहुत रैखिक होता है, जिसमें केवल थोड़ी शाखा होती है।
  • हम रात को संपीड़ित करते हैं (सभी संस्करणों को हटाकर एक पूर्ण सेक प्राप्त करें)।
  • व्यावसायिक तालिकाओं का नियमित रूप से विश्लेषण किया जाता है।
  • डेल्टा टेबल का विश्लेषण नहीं किया जाता है। वे बंद हैं (रिटर्न त्रुटि का विश्लेषण करने का प्रयास "ORA-20005 ऑब्जेक्ट आँकड़े लॉक हैं")। न तो sde स्कीमा में अस्थिर तालिकाएँ हैं - स्टेट्स, STATE_LINEAGES।

क्या आपने जियोडेटाबेस टूलकिट (GDBT) का उपयोग करके राज्य के पेड़ की जांच की है ?
किर्क कुएकेन्डल

नहीं किर्क, मुझे क्या देखना चाहिए?
nef001

क्या आप एक विशिष्ट संस्करण वर्कफ़्लो का उपयोग करते हैं?
रागी यासर बुरहुम

3
आपके Gdbt प्रश्न के बारे में, आप फंकी स्टेट ट्री शाखाओं की तलाश कर रहे हैं जो SDE.DEFAULT से "रैखिक" के विपरीत अधिक रैखिक और दूर से दिखती हैं
रागी यासर बुरहूम

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

जवाबों:


7

डेल्टा टेबल और राज्य ट्री का आपके प्रश्नों पर सीधा प्रभाव पड़ता है।

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

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

ईएसआरआई से वर्जन वर्कफ़्लोज़ दस्तावेज़ पर एक नज़र डालें जो आपको सिखाएगा कि संस्करण राज्य के पेड़ को कैसे नियंत्रण में रखा जाए। पहले और बाद में राज्य के पेड़ को देखने के लिए GDBT का उपयोग करें ताकि आप देख सकें कि एक अच्छा वर्कफ़्लो पेड़ को कैसे प्रभावित करता है।

दूसरा, यदि आप अपने अधिकांश उपयोग के मामलों के लिए जियोमेट्रिक नेटवर्क का उपयोग नहीं करने के साथ दूर हो सकते हैं, तो ऐसा करें। यह शामिल किए जाने वाले फ़ीचरक्लैस को धीमा कर देगा क्योंकि यह प्रत्येक रो :: स्टोर कॉल के लिए जटिल संदेश का उपयोग करता है (जैसा कि तालिका में पंक्ति को संग्रहीत करने और इसके साथ किया जा रहा है)।

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


4

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.