ओरेकल डेटाबेस पर पुराने डेटा को हटाने के लिए तकनीक

Question

हमारे पास परिपक्व ओरेकल डेटाबेस एप्लिकेशन (10 वर्षों से अधिक उत्पादन में) है, और उस समय के दौरान, हम पुराने डेटा को हटाने के लिए अपने स्वयं के निर्माण की स्क्रिप्ट का उपयोग कर रहे हैं जो अब आवश्यक नहीं है । वे I/o के साथ सिस्टम को अधिभारित करने या बहुत अधिक पूर्ववत स्थान का उपयोग करने से बचने के लिए, लगातार चलने वाले लूप में उपयुक्त तालिकाओं के खिलाफ हटाए गए बयानों को जारी करके काम करते हैं।

वे अधिकांश भाग के लिए ठीक काम करते हैं। वे प्रतिदिन चलते हैं, और सिस्टम से डेटा के पुराने दिनों के मूल्य को हटाने में लगभग एक घंटा लगते हैं। मेरी मुख्य चिंताओं में टेबल और इंडेक्स पर प्रभाव पड़ता है कि ये सभी हटाना हो सकता है, और तथ्य यह है कि भले ही वे सिस्टम को अत्यधिक लोड नहीं करते हैं, फिर भी उस कम समय में एक दिन के डेटा को हटाने से इसका प्रभाव पड़ता है उदाहरण बफर कैश के परिणामस्वरूप, अगले कुछ घंटों के लिए बाद में पूछे जाने वाले प्रश्न थोड़ा धीमे चलते हैं क्योंकि कैश धीरे-धीरे बहाल हो जाता है।

वर्षों से हम बेहतर तरीकों पर विचार कर रहे हैं। अतीत में, मैंने सुना था कि लोगों ने पुराने डेटा काटने के लिए विभाजित टेबल का उपयोग किया - उदाहरण के लिए एक महीने प्रति माह, और मासिक आधार पर सबसे पुराना विभाजन छोड़ना। इस दृष्टिकोण के लिए मुख्य दोष यह है कि हमारे काटने के नियम "महीने एक्स निकालें" से आगे जाते हैं। उपयोगकर्ताओं को यह निर्दिष्ट करने की अनुमति है कि कुंजी मानों के आधार पर सिस्टम में कितना समय रहना चाहिए (उदाहरण के लिए, चालान तालिका में, खाता foo को 3 महीने बाद हटाया जा सकता है, लेकिन खाता बार को 2 साल तक रहने की आवश्यकता हो सकती है)।

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

कैश blowouts के लिए, मैंने समर्पित बफर कैश स्थापित करने के बारे में थोड़ा सा पढ़ा है, लेकिन ऐसा लगता है कि यह प्रति-उपयोगकर्ता आधार पर अधिक है, प्रति उपयोगकर्ता या प्रति लेनदेन के आधार पर। कैश को संरक्षित करने के लिए, मुझे वास्तव में किसी भी समय कैश में एक लेनदेन के डेटा को रखने के लिए रीपिंग नौकरी पसंद है, क्योंकि डेटा को एक बार हटाए जाने की आवश्यकता नहीं है।

क्या हम निकट भविष्य के लिए हटाए गए उपयोगों से फंस गए हैं, या क्या अन्य, अधिक से अधिक चालाक तरीके से निपटने के लिए निपटने के तरीके हैं?

Answer 1

अधिकांश भाग के लिए मुझे लगता है कि आप हटाए गए हैं।

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

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

Answer 2

हटाएं यह बुरा नहीं है, प्रदान किया गया है कि आपने अपनी अनुक्रमणिका का पुनर्निर्माण किया है। ओरेकल उन पृष्ठों को पुनर्प्राप्त करेगा जिनमें अब डेटा नहीं है।

हालांकि, 8i (और शायद अभी भी) के रूप में, यह इंडेक्स पृष्ठों को ठीक से पुनर्प्राप्त नहीं करेगा जिसमें अब वैध संदर्भ नहीं हैं। इससे भी बदतर, चूंकि सूचकांक की पत्तियों को जंजीर कर दिया गया था, इसलिए आप एक ऐसी स्थिति में आ सकते हैं जहां यह पंक्ति खोजने के लिए पत्ती नोड्स चलना शुरू कर देगी।यह प्रदर्शन में एक महत्वपूर्ण गिरावट का कारण बनता है: सामान्य रूप से सेकंड लेने वाले प्रश्नों में कुछ मिनट लग सकते हैं। बूंद भी बहुत अचानक थी: एक दिन यह ठीक होगा, अगले दिन यह नहीं होगा।

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

Answer 3

क्या होगा यदि आप अस्थायी रूप से इंडेक्स को निष्क्रिय करते हैं, हटाते हैं और फिर उन्हें पुनर्निर्माण करते हैं? क्या यह आपके डेलेट के प्रदर्शन में सुधार करेगा? बेशक, इस मामले में आपको यह सुनिश्चित करना होगा कि स्क्रिप्ट सही हैं और उचित हटाने का आदेश और संदर्भित अखंडता सुनिश्चित करें।

Answer 4

हमें एक ही रणनीति का उपयोग करके एक ही समस्या है। यदि स्थिति वास्तव में खराब हो जाती है (इंडेक्स, टेबल, ... के बहुत खंडित आवंटन), हम अंतरिक्ष पुनर्विचार क्रियाओं को लागू करने का प्रयास करते हैं।

टेबल्स को पंक्ति आंदोलन की अनुमति देना है (जैसे फ्लैशबैक के लिए): तालिका बदलें टीटीटी पंक्ति आंदोलन को सक्षम करता है; तालिका बदलें टीटीटी अंतरिक्ष को छोटा करें; और फिर सभी अनुक्रमणिका का पुनर्निर्माण करें।

मुझे नहीं पता कि आप रखरखाव खिड़कियों के साथ कैसे हैं, अगर आवेदन हर समय उपयोग करने योग्य है, तो यह कठिन है, अगर नहीं, तो आप ऑफ़लाइन होने पर कुछ "repacking" कर सकते हैं। "टेबल टीटीटी हिल टेबलस्पेस एसएसएसएस बदलें" मेस को साफ करने के बहुत सारे काम करता है क्योंकि तालिका को फिर से लिखा जाता है। आप नए स्टोरेज पैरामीटर भी निर्दिष्ट कर सकते हैं जैसे हद प्रबंधन, आकार, ... दस्तावेज़ों में एक नज़र डालें।

मैं इस तरह एक स्क्रिप्ट का उपयोग पूरे डेटाबेस के लिए एक स्क्रिप्ट बनाने के लिए:

SET SQLPROMPT "-- " 
SET ECHO OFF 
SET NEWPAGE 0 
SET SPACE 0 
SET PAGESIZE 0 
SET FEEDBACK OFF 
SET HEADING OFF 
SET TRIMSPOOL ON 
SET TERMOUT OFF 
SET VERIFY OFF 
SET TAB OFF 
spool doit.sql 
select 'prompt Enabling row movement in '||table_name||'...'||CHR (10)||'alter table '||table_name||' enable row movement;' from user_tables where table_name not like '%$%' and table_name not like '%QTAB' and table_name not like 'SYS_%'; 
select 'prompt Setting initial ext for '||table_name||'...'||CHR (10)||'alter table '||table_name||' move storage (initial 1m);' from user_tables where table_name not like '%$%' and table_name not like '%QTAB' and table_name not like 'SYS_%'; 
select 'prompt Shrinking space for '||table_name||'...'||CHR (10)||'alter table '||table_name||' shrink space;' from user_tables where table_name not like '%$%' and table_name not like '%QTAB' and table_name not like 'SYS_%'; 
select 'prompt Rebuilding index '||index_name||'...'||CHR (10)||'alter index '||index_name||' rebuild;' from user_indexes where status = 'UNUSABLE'; 
spool off 
prompt now check and then run @doit.sql 
exit