डेटाबेस आर्काइविंग

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

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

एप्लिकेशन कोड को ऑप्टिमाइज़ करें;
डेटाबेस क्वेरीज को ऑप्टिमाइज़ करें;
डेटाबेस संरचना (इंडेक्स, पार्टिशन, टेबल) को ऑप्टिमाइज़ करें;
डेटा को आर्काइव करें;
उपयोग के मामलों को फिर से परिभाषित करें।

यदि आप डेटा आर्काइवल पर विचार करते हैं तो आपके पास दो और विकल्प हैं:

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

डेटा को किसी अन्य गंतव्य पर ले जाना

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

हालांकि, ध्यान रखें कि यदि आपके पास पहले से ही अपनी तालिका के लिए कुछ इंडेक्स सेट हैं, तो रिकॉर्ड हटाने से प्रभावी रूप से फ्रेगमेंटेशन बढ़ जाएगा। फ्रेगमेंटेशन की जांच के लिए आप sys.dm_db_index_physical_stats पर क्वेरी कर सकते हैं। फ्रेगमेंटेशन स्तर के आधार पर आप इसे ठीक करने के लिए दो में से एक विधि का उपयोग कर सकते हैं:

फ्रेगमेंटेशन <5%-10%; 30%) - रीऑर्गनाइज ALTER INDEX index_name REORGANIZE; (हमेशा ऑनलाइन, Oracle के साथ उपलब्ध नहीं);
फ्रेगमेंटेशन <30%; 100%) - रीबिल्ड ALTER INDEX REBUILD [ONLINE];। यदि आपके पास एक स्पेशियल पार्टिशन्ड इंडेक्स है, तो आपको ALTER INDEX index_name REBUILD PARTITION partition_name; क्वेरी का उपयोग करना होगा। टेबल इंडेक्स प्रदर्शित करने के लिए SELECT * FROM all_indexes; कॉल करें, और पार्टिशन नामों की जांच के लिए SELECT * FROM ALL_TAB_PARTITIONS;।

Oracle इन-डेटाबेस आर्काइविंग

Oracle अधिक लोकप्रिय डेटाबेस में से एक है। 12c में Oracle ने इन-डेटाबेस आर्काइविंग नामक एक सुविधा पेश की है। यह एक बहुत ही रोचक विशेषता है। मूल रूप से, आप इसे एक चुनी हुई तालिका पर लागू करते हैं और Oracle एक अतिरिक्त कॉलम ora_archive_state बनाता है जिसे मान 0 के साथ आरंम्भ किया जाता है। इस मान का मतलब है कि पंक्ति आर्काइव नहीं की गई है। इस कॉलम को किसी अन्य मान पर सेट करने से पंक्ति को प्रभावी रूप से आर्काइव के रूप में चिह्नित किया जाएगा। आर्काइव की गई पंक्ति अनिवार्य रूप से है:

डिफ़ॉल्ट रूप से दिखाई नहीं देती ALTER SESSION SET ROW ARCHIVAL VISIBILITY = ACTIVE;
सत्र विशेषता सेट करने के बाद दिखाई देती है ALTER SESSION SET ROW ARCHIVAL VISIBILITY = ALL;
ora_archive_state कॉलम स्वचालित रूप से दृश्यता मान के आधार पर मान के साथ प्रश्नों में जोड़ा जाता है।

इन-डेटाबेस आर्काइवल को सक्षम और अक्षम करना दो कमांड का उपयोग करके किया जाता है:

ALTER TABLE table_name ROW ARCHIVAL;
ALTER TABLE table_name NO ROW ARCHIVAL;

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

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

हालांकि, ध्यान रखें कि किसी भी कनेक्शन पूल का उपयोग करते समय, कनेक्शन बंद करने के बाद यह एक बदले हुए सत्र के साथ पूल में वापस चला जाता है, जो प्रभावी रूप से कनेक्शन पूल को संक्रमित करता है और आर्काइवल को अर्थहीन बना देता है। तो, सुरक्षित तरीका यह होगा कि इसे बंद करने से पहले सत्र को वापस बदल दिया जाए (जहां तक JDBC कनेक्शन थ्रेड्स के बीच साझा नहीं किया जाता है जो आम तौर पर सच होना चाहिए) या और भी सुरक्षित - आर्काइवल दृश्यता उपयोग के लिए अपने स्वयं के कनेक्शन पूल के साथ एक अलग डेटा स्रोत तैयार करना।

आर्काइवल के बाद प्रदर्शन में सुधार

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

प्रदर्शन में सुधार करने का एक और तरीका है जो विशेष रूप से इन-डेटाबेस आर्काइविंग के अनुकूल है - टेबल पार्टिशनिंग। यह सुविधा एक दोधारी तलवार है:

पार्टिशनिंग सही तरीके से किए जाने पर एक तालिका पर प्रदर्शन में भारी सुधार कर सकती है, लेकिन गलत तरीके से या जब जरूरत न हो तो यह प्रदर्शन को और खराब कर सकती है, यहां तक कि अनुपयोगी भी। [severalnines.com]

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

इन-डेटाबेस आर्काइविंग के मामले में ora_archive_state एक पार्टिशन की के लिए एक संभावित उम्मीदवार है। ज्यादातर समय आप सक्रिय, गैर-आर्काइव डेटा के लिए क्वेरी करेंगे। ऑप्टिमाइज़र को उन पार्टिशन में नहीं खोजना चाहिए जिनमें प्रासंगिक जानकारी नहीं है। सिस्टम घटक जिन्हें आर्काइव किए गए डेटा तक पहुंच की आवश्यकता होती है, वे धीमा प्रदर्शन करेंगे। हालाँकि, डेटा को हटाने के बजाय, इंटरफ़ेस में पुराने डेटा तक पहुंच को सही ढंग से इंगित करके, उपयोगकर्ता अधिक क्षमाशील और समझदार होंगे। आर्काइव किए गए रिकॉर्ड वाले पार्टिशन को और कंप्रेस किया जा सकता है यदि आप प्रदर्शन की परवाह नहीं करते हैं लेकिन इस सिद्धांत का पालन करते हैं कि बचाया गया हर बाइट एक पैसा कमाया है।

आर्काइव स्थिति कॉलम पर पार्टिशन की गई तालिका बनाने के लिए, आप कुछ इस तरह का उपयोग कर सकते हैं (एक अलग कॉलम द्वारा पार्टिशनिंग के मामले में सब-पार्टिशन का उपयोग भी संभव है):

CREATE TABLE table_name (
  --...
)
  ROW ARCHIVAL
  ENABLE ROW MOVEMENT
  PARTITION BY LIST ( ORA_ARCHIVE_STATE )
  (
    PARTITION p0 VALUES ('0'),
    PARTITION p1 VALUES ('1')
  );

यदि आपने पहले ही तालिका बना ली है लेकिन यह अभी तक पार्टिशन नहीं है, तो इसे एक पार्टिशन तालिका में बदलना संभव है:

ALTER TABLE table_name MODIFY
  PARTITION BY LIST ( ORA_ARCHIVE_STATE )
  (
    PARTITION p0 VALUES ('0'),
    PARTITION p1 VALUES ('1')
  ) [ONLINE];

सबसे जटिल मामला तब होता है जब तालिका पहले से ही पार्टिशन होती है। ऐसी स्थिति में आपके पास दो विकल्प होते हैं: