DELETE + REORG मुक्त डिस्कस्पेस (DB2) क्यों नहीं करता है?

Question

DB2 में मेरे पास एक टेबल है जिसमें बड़े बाइनरी डेटा हैं। अब मैंने पूरी मेज को शुद्ध किया और रनस्टैट्स, रीगॉर, रनस्टेट्स को चलाया, लेकिन डिस्क स्थान की मात्रा में बदलाव नहीं हुआ। यहां क्या गलत हो सकता है?

तालिका अपने स्वयं के टेबलस्पेस में रहती है जिसे मैंने निम्न प्रकार से बनाया है:

CREATE BUFFERPOOL "MY_BP" SIZE 250 AUTOMATIC PAGESIZE 4096;
CREATE LARGE TABLESPACE MY_TBS IN DATABASE PARTITION GROUP IBMDEFAULTGROUP PAGESIZE 4096 MANAGED BY AUTOMATIC STORAGE EXTENTSIZE 64 PREFETCHSIZE 64 BUFFERPOOL MY_BP OVERHEAD 10.500000 TRANSFERRATE 0.140000 FILE SYSTEM CACHING;

मैंने निम्न के रूप में हटाया / पुनर्प्राप्त किया:

DELETE FROM MY_TBL
RUNSTATS ON TABLE MY_TBL WITH DISTRIBUTION AND DETAILED INDEXES ALL
REORG TABLE MY_TBL
RUNSTATS ON TABLE MY_TABLE WITH DISTRIBUTION AND DETAILED INDEXES ALL
ALTER TABLESPACE MY_TBS REDUCE

सारणी MY_TBL ने इससे पहले 2.5GB तक का समय लिया और हटाने / वापस करने के बाद यह केवल 3 एमबी कम उपयोग करता है ।

FWIW: मैं DB2 / NT v9.5.2 चला रहा हूं।

Comments

क्या यह db2 v8 पर सिस्टम के लिए काम करता है?

— टोनी

Answer 1

मैं एक अनुमान लगाने जा रहा हूं कि आप स्वचालित भंडारण का उपयोग कर रहे हैं। (ऐसा नहीं है कि यह अन्यथा हो सकता है ... स्वचालित भंडारण के साथ ऐसा होना आसान है।

यह समस्या सबसे अधिक संभावना है कि आपके डेटाबेस ने अपने लिए स्थान पुनः प्राप्त कर लिया लेकिन डिस्क को ऑपरेटिंग सिस्टम पर वापस नहीं छोड़ा। तालिकाओं के लिए हाई वॉटर मार्क की जांच करके इसे बहुत आसानी से दिखाया जा सकता है।

एक निम्नलिखित करें

db2 list tablespaces show detail

यह आपको प्रत्येक टेबलस्पेस दिखाएगा और डिस्क पर इसका क्या उपयोग कर रहा है। Used pagesडेटाबेस के उपयोग के कितने पृष्ठ डिस्क है। तुलना करने पर कि total pages(डिस्क पर मौजूद कुल दावा) और High water mark (pages)आपको दिखाएगा कि क्या आप वास्तव में जरूरत से ज्यादा "दावा" कर रहे हैं। (यानी, कम उपयोग किए गए पृष्ठ, बहुत उच्च कुल पृष्ठ और कुल पृष्ठों के करीब एक हाई वॉटर मार्क)।

इस अप्रयुक्त स्थान से छुटकारा पाने के लिए और इसे ऑपरेटिंग सिस्टम पर वापस करने के लिए आप निम्नलिखित (स्वचालित भंडारण के तहत) जारी करेंगे db2 alter tablespace <tablespace name> reduce max:। उदाहरण

db2 alter tablespace ts1 reduce max;

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

यदि आप बिना स्वचालित भंडारण के डीएमएस का उपयोग कर रहे हैं, तो आपको कुछ अलग प्रकार के कमांड का उपयोग करने की आवश्यकता है:

db2 alter tablespace <tablespace name> lower high water mark;
db2 alter tablespace reduce (<containter name> or [all containers] integer K|M|G or integer PERCENT);

उदाहरण

db2 alter tablespace ts1 lower high water mark;
db2 alter tablespace reduce (all containers 500 M);

जहां हम काम करते हैं, हम इसे अपनी कुछ रखरखाव लिपियों में डालते हैं ताकि हम यह सुनिश्चित करने के बाद कि हम पुन: निर्माण कर सकें, यह सुनिश्चित करने के लिए कि हम पुनरावर्ती स्थान को पुन: व्यवस्थित करें। हमारे मामले में हम DB2 LUW 9.7 FP 4 का उपयोग करते हैं, इसलिए यह सुनिश्चित करने के लिए कि आपके पास अपने संस्करण के लिए सही जानकारी तक पहुंच है, यह सुनिश्चित करने के लिए 9.5 के लिए सूचना केंद्र को दोगुना करने के लिए चोट नहीं पहुंचाता है।

EDIT: यदि आपके टेबलस्पेस डेटाबेस से DB2 9.7 में अपग्रेड किए गए हैं, तो संभवतः आपके पास पुनः प्राप्त करने योग्य भंडारण विशेषता सेट नहीं होगी। यदि आप DMS से स्वचालित संग्रहण में अपग्रेड करते हैं, तो भी यह सत्य है। किसी भी तरह से काटता है क्योंकि आप वास्तव में उच्च पानी के निशान को कम नहीं कर सकते हैं। आपको टेबल को डंप करना होगा और डेटा बाहर करना होगा, टेबलस्पेस को ड्रॉप करना होगा। फिर स्वचालित भंडारण का उपयोग करके टेबलस्पेस को फिर से बनाएं और अपनी तालिकाओं के लिए डेटा आयात करें।

Comments

+1 - साइट पर योगदान करने वाले एक DB2 विशेषज्ञ को देखने के लिए अच्छा है। हम अतीत में उस डोमेन में कमजोर रहे हैं।

— फिलो

बस एक त्वरित टिप्पणी, DB2 9.5 में, आप alter tablespace <tbsp> lower high watermarkया alter tablespace <tbsp> reduce maxवाक्यविन्यास का उपयोग नहीं कर सकते हैं - ये DB2 9.7 तक पेश नहीं किए गए थे।

— इयान बेजरोवदे

जैसा कि मैंने अपनी प्रारंभिक पोस्ट में उल्लेख किया है, मैंने पहले से ही ज्यादातर कोशिश की और यह काम नहीं किया। अब तक मुझे यह समाधान मिल गया था कि मेरा स्व: डिस्क स्थान को पुनः प्राप्त नहीं किया जा सकता है क्योंकि मैंने LONGLOBDATA विकल्प को निर्दिष्ट नहीं किया है, जो यदि आप BLOB या CLOBs से डिस्क स्थान को पुनः प्राप्त करना चाहते हैं तो यह आवश्यक प्रतीत होता है। कृपया मेरे अपने प्रश्न का उत्तर यहां देखें। वैसे भी मैं आपके उत्तर में डाले गए प्रयास की सराहना करता हूं, +1!

— अलेक्जेंडर टोबियास बोकस्टालर

Answer 2

तालिका MY_TBLमें एक BLOBकॉलम में बड़े बाइनरी डेटा हैं । REORGकमांड के प्रलेखन का कहना है कि DB2 ऐसी वस्तुओं को पुनर्गठित करने से बचता है क्योंकि यह समय लेने वाली है और क्लस्टरिंग में सुधार नहीं करती है। हालांकि, LONGLOBDATAविकल्प निर्दिष्ट होने पर DB2 को LOB डेटा को पुनर्गठित करने के लिए मजबूर किया जा सकता है। अप्रयुक्त स्थान को DB2 द्वारा पुन: उपयोग किया जा सकता है, इसलिए नया डेटा सम्मिलित करने से नए को आवंटित करने से पहले मौजूदा, अप्रयुक्त पृष्ठों को भरना होगा।

चल रहा है

REORG TABLE MY_TBL LONGLOBDATA

सफलतापूर्वक खाली स्थान का उपयोग कर रहे डिस्क स्थान के 2.5GB को पुनः प्राप्त किया।

मुझे इस विकल्प के बारे में नहीं पता था और मैंने इसे पहली बार प्रलेखन पढ़ा था।

Comments

अच्छी बात। हालाँकि, जो मैंने अभी एक DB2NightShow एपिसोड "द अटैक ऑफ द ब्लब" पर सीखा है, आप LONGLOBDATA विकल्प को अक्सर नहीं चलाना चाहते हैं क्योंकि इसमें अधिक समय लगता है और / या प्रदर्शन समस्याओं का कारण बनता है (यदि आप ऑनलाइन रीग्रो करने की कोशिश कर रहे हैं) ।

— क्रिस एल्ड्रिच

हम जिन डेटाबेस से काम कर रहे हैं, वे औद्योगिक मशीनों से लॉग डेटा होते हैं। ऐसे डेटाबेस के खिलाफ प्रश्न समय के लिए महत्वपूर्ण नहीं हैं, इसलिए यदि प्रदर्शन एक रीग के दौरान गिरता है, तो यह कोई समस्या नहीं है।

— अलेक्जेंडर टोबियास बॉकस्टैलर