कॉग्नोस ऑडिटिंग ब्लॉग - बड़े और उच्च वॉल्यूम वातावरण के लिए टिप्स और ट्रिक्स

जॉन बॉयर और माइक नॉरिस का एक ब्लॉग।

परिचय

आपके उपयोगकर्ता समुदाय द्वारा कॉग्नोस का उपयोग कैसे किया जा रहा है, यह जानने और समझने के लिए कॉग्नोस ऑडिटिंग क्षमता का काम करना महत्वपूर्ण है और जैसे सवालों के जवाब देने में मदद करें:

• • सिस्टम का उपयोग कौन कर रहा है?
  • वे क्या रिपोर्ट चला रहे हैं?
  • रिपोर्ट चलाने का समय क्या है?
  • अन्य टूल्स की सहायता से, जैसे MotioCI, कौन सी सामग्री अप्रयुक्त है?

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

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

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

चैलेंज

• • ऑडिट डेटाबेस की असीम वृद्धि कॉग्नोस पर्यावरण के स्वास्थ्य पर नकारात्मक प्रभाव डाल रही है
  • ऑडिट डेटाबेस की रिपोर्टिंग धीमी या अनुपयोगी हो गई है
  • कॉग्नोस को ऑडिट डेटाबेस में रिकॉर्ड किए जा रहे रिकॉर्ड में देरी का अनुभव होता है
  • ऑडिट डेटाबेस में डिस्क स्थान समाप्त हो रहा है

इसका मतलब यह है कि यह केवल रिपोर्ट नहीं है जो ऑडिट डेटाबेस पर निर्भर है, जो पीड़ित है, बल्कि अक्सर पूरी प्रणाली है। यदि ऑडिट डेटाबेस कॉग्नोस सामग्री स्टोर के समान सर्वर पर है, तो उस वातावरण में कॉग्नोस की सभी चीजों का प्रदर्शन प्रभावित होगा।

सेटअप

हम यह मानते है कि:

1. 1. कॉग्नोस एनालिटिक्स स्थापित और चल रहा है
   2. कॉग्नोस को ऑडिट डेटाबेस में लॉग इन करने के लिए कॉन्फ़िगर किया गया है
   1. • एक ऑडिट डेटाबेस रखें
      • कॉग्नोस प्रशासन में उपयुक्त ऑडिट लॉगिंग स्तर सेट करें
      • कॉग्नोस द्वारा डेटाबेस को रिकॉर्ड लिखा जा रहा है
   3. ऑडिट डेटाबेस एक साल से अधिक समय से उपयोग में है
   4. पर्यावरण उपयोगकर्ताओं और निष्पादन के साथ बहुत सक्रिय है
   5. ऑडिट पैकेज का उपयोग कॉग्नोस के उपयोग डेटा को सामने लाने के लिए किया जा रहा है
   6. हम ऑडिट डेटाबेस रिपोर्टिंग प्रदर्शन में सुधार करना चाहते हैं
   7. पुराने रिकॉर्ड को शुरू करना या हटाना हमेशा एक विकल्प नहीं होता है

यदि आपने अभी तक Cognos ऑडिट स्थापित और कॉन्फ़िगर नहीं किया है, तो Lodestar Solutions, a Motio साथी, एक उत्कृष्ट . है पद कॉग्नोस बीआई / सीए में ऑडिट सक्षम करने पर।

समाधान

कुछ संभावित समाधान हैं जो जल्दी से खुद को प्रस्तुत करते हैं:

1. 1. डेटा की मात्रा कम करें:
   1. • कुछ पुराने डेटा को दूसरे डेटाबेस में ले जाना
      • कुछ पुराने डेटा को उसी डेटाबेस में दूसरी तालिका में ले जाना
   2. बस हटाएं या चापhive कुछ डेटा और इसके बारे में चिंता न करें
   3. इसके साथ जियो। कैन को किक डाउन करें road और प्रदर्शन के लिए डेटाबेस व्यवस्थापक को पुश करें
      स्कीमा के परिवर्तन की अनुमति न देकर उन्हें हथकड़ी लगाते समय सुधार या
      अनुक्रमणिका

हम विकल्प 3 से निपटने नहीं जा रहे हैं। विकल्प 2, डेटा हटाना, एक अच्छा विकल्प नहीं है और मैं कम से कम 18 महीने के मूल्य को कम से कम रखने की सलाह दूंगा। लेकिन, यदि आप इतने इच्छुक हैं, आईबीएम एक उपयोगिता प्रदान करता है, ऑडिटडीबीसीक्लीनअप (कॉग्नोस बीआई) या ए लिपि (कॉग्नोस एनालिटिक्स) जो ठीक यही करेगा। Cognos BI की उपयोगिता टाइमस्टैम्प के आधार पर रिकॉर्ड हटा देती है जबकि Cognos Analytics की स्क्रिप्ट केवल अनुक्रमणिका और तालिकाओं को हटा देती है।

इस पर हमने पहले ग्राहकों को जो सिफारिशें की हैं, वे दो डेटाबेस में विभाजित करने के लिए थीं:

1. 1. ऑडिट - लाइव: इसमें हाल के सप्ताह का डेटा शामिल है
   2. लेखा परीक्षा - ऐतिहासिक: ऐतिहासिक डेटा शामिल है (एन वर्ष तक)

संक्षेप में, ऑडिट लाइव से ऑडिट हिस्टोरिकल में सबसे हाल के रिकॉर्ड को स्थानांतरित करने के लिए प्रक्रिया साप्ताहिक चलती है। इस प्रक्रिया के चलने के बाद ऑडिट लाइव एक खाली स्लेट के रूप में शुरू होता है।

1. 1. लाइव डीबी तेज और चुस्त है, जिससे इंसर्ट जितनी जल्दी हो सके हो सके
   2. लेखापरीक्षा प्रश्न विशेष रूप से ऐतिहासिक डीबी को निर्देशित किए जाते हैं

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

कॉग्नोस एडमिनिस्ट्रेशन में, आप ऑडिट डेटा सोर्स के लिए दो अलग-अलग कनेक्शन जोड़ सकते हैं। जब कोई उपयोगकर्ता ऑडिट पैकेज के खिलाफ रिपोर्ट चलाता है, तो उन्हें संकेत मिलता है कि वे किस कनेक्शन का उपयोग करना चाहते हैं:

यदि आप ऐतिहासिक ऑडिट डेटा के बजाय लाइव ऑडिट डेटा देखना चाहते हैं, तो संकेत मिलने पर आप केवल "ऑडिट - लाइव" कनेक्शन चुनें (अपवाद होना चाहिए, मानक नहीं।)

यदि आप वास्तव में लाइव और ऐतिहासिक दोनों का एक समेकित दृश्य प्रदान करना चाहते हैं, तो आप ऐसा कर सकते हैं, लेकिन यह प्रदर्शन को प्रभावित करेगा।

उदाहरण के लिए, आप "ऑडिट - समेकित दृश्य" नामक एक तीसरा डेटाबेस बना सकते हैं और फिर, ऑडिट स्कीमा में प्रत्येक तालिका के लिए: एक समान रूप से नामित दृश्य बनाएं जो लाइव डीबी में तालिका और तालिका में तालिका के बीच एक SQL संघ है। ऐतिहासिक डीबी। इसी तरह, यह फ्रेमवर्क मैनेजर मॉडल में भी हासिल किया जा सकता है, लेकिन, फिर से, प्रदर्शन एक महत्वपूर्ण विचार होगा।

हमारे कुछ ग्राहकों ने एक समेकित दृष्टिकोण बनाया है। यह हमारी राय है कि यह अधिक होने की संभावना है। इस समेकित दृश्य में प्रदर्शन हमेशा खराब रहेगा और हमें ऐसे कई उपयोग मामले नहीं मिले हैं जो लाइव डेटा सेट और ऐतिहासिक दोनों का उपयोग करते हैं। लाइव का उपयोग समस्या निवारण के लिए और ऐतिहासिक प्रवृत्ति रिपोर्टिंग के लिए किया जा रहा है।

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

जिन प्रमुख तालिकाओं में अधिकांश प्रशासकों की रुचि होगी, वे 6 तालिकाएँ हैं जो सिस्टम में उपयोगकर्ता गतिविधि और रिपोर्टिंग गतिविधि को लॉग करती हैं।

• COGIPF_USERLOGON : उपयोगकर्ता लॉगऑन (लॉग ऑफ सहित) जानकारी संग्रहीत करता है
• COGIPF_RUNREPORT : रिपोर्ट निष्पादन के बारे में जानकारी संग्रहीत करता है
• COGIPF_VIEWREPORT : रिपोर्ट देखने के अनुरोधों के बारे में जानकारी संग्रहीत करता है
• COGIPF_EDITQUERY : क्वेरी रन के बारे में जानकारी संग्रहीत करता है
• COGIPF_RUNJOB : नौकरी के अनुरोधों के बारे में जानकारी संग्रहीत करता है
• COGIPF_ACTION : कॉग्नोस में उपयोगकर्ता की क्रियाओं को रिकॉर्ड करता है (यह तालिका अन्य की तुलना में बहुत अधिक तेजी से बढ़ सकती है)

आउट-ऑफ़-द-बॉक्स कॉन्फ़िगरेशन इस तरह दिखता है:

अनुशंसित विन्यास:

कॉग्नोस ऑडिट डेटाबेस - लाइव में 1 सप्ताह का ऑडिट डेटा होता है। 1 सप्ताह से अधिक पुराने डेटा को कॉग्नोस ऑडिट डेटाबेस - ऐतिहासिक में स्थानांतरित कर दिया गया है।

कॉग्नोस ऑडिट डेटाबेस से लाइन - लाइव टू कॉग्नोस ऑडिट डेटाबेस - आरेख में ऐतिहासिक इसके लिए जिम्मेदार है:

• लाइव ऑडिट से ऐतिहासिक ऑडिट में डेटा कॉपी करना
• लाइव ऑडिट में उन सभी पंक्तियों को हटा दें जो 1 सप्ताह से अधिक पुरानी हैं
• ऐतिहासिक ऑडिट में x वर्ष से पुरानी सभी पंक्तियों को हटा दें
• COGIPF_ACTION में 6 महीने से पुरानी सभी पंक्तियों को हटा दें

अनुक्रमित

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

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

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

आईबीएम समर्थन की सिफारिश की प्रदर्शन में सुधार के लिए निम्न तालिकाओं के लिए कॉलम "COGIPF_REQUESTID", "COGIPF_SUBREQUESTID", और "COGIPF_STEPID" पर एक इंडेक्स बनाना:

• COGIPF_NATIVEQUERY
• COGIPF_RUNJOB
• COGIPF_RUNJOBSTEP
• COGIPF_RUNरिपोर्ट
• COGIPF_EDITQUERY

इसके अलावा अन्य कम उपयोग की जाने वाली तालिकाओं पर:

• COGIPF_POWERPLAY
• COGIPF_HUMANTASKSERVICE
• COGIPF_HUMANTASKSERVICE_DETAIL

आप इसे एक शुरुआती बिंदु के रूप में उपयोग कर सकते हैं, लेकिन मैं आपके संगठन के लिए सबसे अच्छे उत्तर पर पहुंचने के लिए उपरोक्त प्रश्नों के उत्तर देने की प्रक्रिया से गुजरूंगा।

अन्य बातें

1. ऑडिट एफएम मॉडल। याद रखें कि आईबीएम द्वारा प्रदान किया जाने वाला फ्रेमवर्क मैनेजर मॉडल डिफ़ॉल्ट तालिकाओं और क्षेत्रों पर आधारित होता है। रिपोर्टिंग टेबल में आपके द्वारा किए गए किसी भी बदलाव को मॉडल में दिखाना होगा। इन परिवर्तनों की सहजता या जटिलता - या इन परिवर्तनों को करने के लिए आपकी संगठनात्मक क्षमता - आपके द्वारा चुने गए समाधान को प्रभावित कर सकती है।
2. अतिरिक्त फ़ील्ड। यदि आप इसे करने जा रहे हैं, तो अब ऑडिट रिपोर्टिंग को बेहतर बनाने के लिए संदर्भ या संदर्भ डेटा के लिए अतिरिक्त फ़ील्ड जोड़ने का समय है।
3. सारांश तालिकाएँ। डेटा को केवल अपनी ऐतिहासिक तालिका में कॉपी करने के बजाय, इसे संपीड़ित करें। रिपोर्टिंग के लिए इसे और अधिक कुशल बनाने के लिए आप डेटा को दिन के स्तर तक एकत्रित कर सकते हैं।
4. तालिकाओं के बजाय दृश्य। अन्य कहते हैं, "इसलिए, 'वर्तमान' डेटाबेस और 'ऐतिहासिक' डेटाबेस होने के बजाय, आपके पास केवल एक डेटाबेस होना चाहिए, और इसमें सभी तालिकाओं को 'ऐतिहासिक' के साथ जोड़ा जाना चाहिए। फिर, आपको दृश्यों का एक सेट बनाना चाहिए, प्रत्येक तालिका के लिए एक जिसे आप 'वर्तमान' के रूप में देखना चाहते हैं, और प्रत्येक दृश्य को उन ऐतिहासिक पंक्तियों को फ़िल्टर करना चाहिए जिन्हें आप नहीं देखना चाहते हैं और केवल वर्तमान वाले को ही गुजरने दें।"
   https://softwareengineering.stackexchange.com/questions/276395/two-database-architecture-operational-and-historical/276419#276419

निष्कर्ष

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

कॉग्नोस ऑडिट डेटाबेस आर्किटेक्चर में प्रस्तावित परिवर्तन प्रत्यक्ष रिपोर्टिंग के साथ-साथ तीसरे पक्ष के अनुप्रयोगों में प्रदर्शन में सुधार करेंगे जो इस पर भरोसा करते हैं, जैसे Motioहै ReportCard और इन्वेंटरी।

वैसे, यदि आपने अपने DBA के साथ वह वार्तालाप किया है, तो हमें इसके बारे में सुनना अच्छा लगेगा। हमें यह जानकर भी खुशी होगी कि क्या आपने खराब प्रदर्शन करने वाले ऑडिट डेटाबेस की समस्या का समाधान किया है और आपने इसे कैसे किया।