कॉग्नोस ऑडिटिंग ब्लॉग - मोठ्या आणि उच्च आवाजाच्या वातावरणासाठी टिपा आणि युक्त्या

जॉन बॉयर आणि माईक नॉरिस यांचा ब्लॉग.

परिचय

कॉग्नोस ऑडिटिंग क्षमता आपल्या वापरकर्ता समुदायाद्वारे कॉग्नोसचा वापर कसा केला जात आहे हे जाणून घेण्यासाठी आणि समजून घेण्यासाठी काम करणे महत्वाचे आहे आणि यासारख्या प्रश्नांची उत्तरे देण्यात मदत करा:

• • यंत्रणा कोण वापरत आहे?
  • ते कोणते अहवाल चालवत आहेत?
  • रिपोर्ट चालवण्याच्या वेळा काय आहेत?
  • इतर साधनांच्या मदतीने, जसे MotioCI, कोणती सामग्री न वापरलेली आहे?

निरोगी कॉग्नोस अॅनालिटिक्स वातावरण राखणे किती महत्त्वाचे आहे हे लक्षात घेता, मानक उत्पादन दस्तऐवजीकरणाच्या पलीकडे त्याच्या ऑडिटिंग डेटाबेसबद्दल आश्चर्यकारकपणे फारसे लिहिले गेले नाही. कदाचित, ते गृहित धरले गेले असेल, परंतु ज्या संस्थांनी त्याचा वापर केला आहे त्यांना माहित आहे की कालांतराने ऑडिट डेटाबेस सारण्यांची चौकशी करणे हळूहळू सुरू होईल - विशेषत: जर तुमच्या संस्थेमध्ये बरेच वापरकर्ते बरेच अहवाल चालवत असतील आणि त्यांचा खूप इतिहास असेल. एवढेच नाही की ऑडिट अॅक्टिव्हिटी लॉगिंगमध्येच विलंब होऊ शकतो कारण जेव्हा रांगेत असते तेव्हा ते डेटाबेसमध्ये पुरेसे जोडता येत नाही, उदाहरणार्थ. जेव्हा आपण डेटाबेसच्या कामगिरीबद्दल विचार करण्यास सुरवात करता तेव्हा आपण कोणत्याही ऑपरेशनल डेटाबेससह रिपोर्टिंग आवश्यकता असते.

मोठ्या सारण्या सामान्यतः क्वेरी कामगिरी मंद करतात. टेबल जितके मोठे असेल तितके घालण्यास आणि क्वेरी करण्यास जास्त वेळ लागेल. लक्षात ठेवा की हे टेबल आणि ऑडिट डेटाबेस मुळात एक ऑपरेशनल डेटाबेस आहेत; लिखाणे वारंवार घडत आहेत आणि आमच्या विरोधात काम करतात कारण आम्ही त्यांना फक्त डेटा वाचवण्याप्रमाणेच वाचलेल्या ऑपरेशन्सवर लक्ष केंद्रित करू शकत नाही.

सामग्री स्टोअर प्रमाणेच, कॉग्नोस पर्यावरणाचे आरोग्य देखील ऑडिट डेटाबेसचे आरोग्य विचारात घेणे आवश्यक आहे. ऑडिट डेटाबेसची अमर्याद वाढ कालांतराने एक समस्या बनू शकते आणि अखेरीस कॉग्नोस वातावरणाच्या एकूण कामगिरीवर परिणाम करू शकते. बाह्य नियमांसह त्यांच्यावर जोर देणाऱ्या अनेक संस्थांमध्ये, पूर्ण लेखापरीक्षण रेकॉर्ड नसणे त्यांना जबरदस्त परिणामांसह अनुपालन नसलेल्या परिस्थितीत उतरवू शकते. तर ऐतिहासिक लेखापरीक्षण हेतूंसाठी इतका डेटा राखण्यासाठी आम्ही कसे सामोरे जाऊ - काही प्रकरणांमध्ये 10 वर्षांपर्यंत - तरीही आम्हाला पर्यावरण राखण्यासाठी आणि वापरकर्त्यांना कामगिरीवर आनंदी ठेवण्यासाठी आवश्यक असलेला अहवाल मिळतो?

आव्हान

• • ऑडिट डेटाबेसची अमर्याद वाढ कॉग्नोस वातावरणाच्या आरोग्यावर नकारात्मक परिणाम करत आहे
  • लेखापरीक्षण डेटाबेस बंद अहवाल देणे मंद किंवा निरुपयोगी झाले आहे
  • ऑडिट डेटाबेसवर लिहिल्या जात असलेल्या रेकॉर्डमध्ये विलंब झाल्याचा अनुभव कॉग्नोसला येतो
  • ऑडिट डेटाबेस डिस्कची जागा संपत आहे

या सगळ्याचा अर्थ असा आहे की हे केवळ अहवालच नाहीत जे ऑडिट डेटाबेसवर अवलंबून असतात ज्यांना त्रास होतो, परंतु बहुतेकदा संपूर्ण प्रणाली. जर ऑडिट डेटाबेस कॉग्नोस सामग्री स्टोअर सारख्याच सर्व्हरवर असेल, तर कॉग्नोसच्या सर्व गोष्टींच्या कामगिरीवर त्या वातावरणात परिणाम होईल.

सेटअप

आम्ही गृहीत धरतो:

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

आपण अद्याप नसल्यास, कॉग्नोस ऑडिट स्थापित आणि कॉन्फिगर केले आहे, लोडेस्टार सोल्यूशन्स, ए Motio भागीदार, एक उत्कृष्ट आहे पोस्ट कॉग्नोस बीआय /सीए मध्ये ऑडिट सक्षम करण्यावर.

ऊत्तराची

काही संभाव्य उपाय आहेत जे त्वरीत स्वतःला सादर करतात:

1. 1. डेटाचे प्रमाण कमी करा:
   1. • काही जुना डेटा दुसऱ्या डेटाबेसमध्ये हलवणे
      • काही जुना डेटा त्याच डेटाबेसमधील दुसर्या टेबलवर हलवणे
   2. फक्त हटवा किंवा चापhive काही डेटा आणि त्याची काळजी करू नका
   3. त्याच्याबरोबर जगा. कॅन खाली लाथ मारा road आणि कामगिरीसाठी डेटाबेस प्रशासकाला धक्का द्या
      स्कीमामध्ये बदल करण्यास परवानगी न देता त्यांना हातकडी बांधताना सुधारणा किंवा
      अनुक्रमणिका

आम्ही पर्याय 3 ला सामोरे जाणार नाही. पर्याय 2, डेटा हटवणे हा एक चांगला पर्याय नाही आणि मी किमान 18 महिन्यांचे मूल्य किमान ठेवण्याची शिफारस करतो. परंतु, जर तुमचा कल असेल तर, IBM एक उपयुक्तता प्रदान करते, ऑडिट डीबीसी क्लीनअप (कॉग्नोस बीआय) किंवा ए स्क्रिप्ट (Cognos Analytics) जे नक्की करेल. कॉग्नोस बीआयसाठी उपयुक्तता टाइमस्टॅम्पवर आधारित रेकॉर्ड हटवते तर कॉग्नोस अॅनालिटिक्सच्या स्क्रिप्ट फक्त अनुक्रमणिका आणि सारण्या हटवतात.

आम्ही यापूर्वी ग्राहकांना केलेल्या शिफारसी दोन डेटाबेसमध्ये विभाजित केल्या होत्या:

1. 1. ऑडिट - लाइव्ह: सर्वात अलीकडील आठवड्यातील डेटाचा समावेश आहे
   2. लेखापरीक्षण - ऐतिहासिक: ऐतिहासिक डेटा आहे (N वर्षांपर्यंत)

थोडक्यात, ही प्रक्रिया साप्ताहिकपणे ऑडिट लाईव्हवरून ऑडिट हिस्टोरिकलकडे नेली जाते. ही प्रक्रिया पूर्ण झाल्यानंतर रिक्त स्लेट म्हणून ऑडिट लाईव्ह सुरू होते.

1. 1. लाइव्ह डीबी जलद आणि घट्ट आहे, ज्यामुळे इन्सर्ट शक्य तितक्या जलद होऊ शकतात
   2. ऑडिट क्वेरी केवळ ऐतिहासिक डीबीला निर्देशित केल्या जातात

या दृष्टिकोनाचा वापर करून, थेट डेटा आणि ऐतिहासिक डेटाचे कोणतेही "एकत्रित शिवणकाम" नाही. माझा असा युक्तिवाद आहे की तुम्हाला कदाचित ते असेच ठेवायचे आहे.

कॉग्नोस प्रशासनात, आपण ऑडिट डेटा स्त्रोतासाठी दोन भिन्न कनेक्शन जोडू शकता. जेव्हा एखादा वापरकर्ता ऑडिट पॅकेजच्या विरोधात अहवाल चालवतो, तेव्हा त्यांना कोणत्या कनेक्शनसाठी ते वापरायचे आहे ते सूचित केले जाते:

ऐतिहासिक ऑडिट डेटा ऐवजी तुम्हाला थेट ऑडिट डेटा बघायचा असेल, तर तुम्ही फक्त "ऑडिट - लाइव्ह" कनेक्शन निवडा जेव्हा सूचित केले जाईल (अपवाद असावा, आदर्श नाही.)

जर तुम्हाला खरोखरच थेट आणि ऐतिहासिक दोन्हीचे एकत्रित दृश्य प्रदान करायचे असेल तर तुम्ही तसे करू शकता, परंतु त्याचा कार्यप्रदर्शनावर परिणाम होईल.

उदाहरणार्थ, तुम्ही "ऑडिट - कन्सोलीडेटेड व्ह्यू" नावाचा तिसरा डेटाबेस तयार करू शकता आणि नंतर, ऑडिट स्कीमामधील प्रत्येक टेबलसाठी: लाइव्ह डीबी मधील टेबल आणि टेबलमधील एसक्यूएल युनियन असलेले समान नाव असलेले दृश्य तयार करा. ऐतिहासिक डीबी. त्याचप्रमाणे, हे फ्रेमवर्क मॅनेजर मॉडेलमध्ये देखील साध्य केले जाऊ शकते, परंतु, पुन्हा, कामगिरी हा एक महत्त्वाचा विचार असेल.

आमच्या काही क्लायंटनी एक एकत्रित दृश्य तयार केले आहे. हे आमचे मत आहे की हे बहुधा ओव्हरकिल आहे. या एकत्रित दृश्यामध्ये कामगिरी नेहमीच वाईट असेल आणि आम्हाला लाइव्ह डेटा सेट आणि ऐतिहासिक दोन्ही वापरणारी अनेक वापर प्रकरणे आढळली नाहीत. समस्या निवारणासाठी लाइव्हचा वापर केला जातो आणि ट्रेंड रिपोर्टिंगसाठी ऐतिहासिक.

कॉग्नोस अॅनालिटिक्स 11.1.7 नुसार, ऑडिट डेटाबेस 21 टेबलवर वाढला आहे. ऑडिट डेटाबेस, नमुना ऑडिट रिपोर्ट आणि फ्रेमवर्क मॅनेजर मॉडेलवर तुम्हाला इतरत्र अधिक माहिती मिळू शकते. डीफॉल्ट लॉगिंग स्तर किमान आहे, परंतु आपण वापर विनंत्या, वापरकर्ता खाते व्यवस्थापन आणि रनटाइम वापर कॅप्चर करण्यासाठी पुढील स्तर, मूलभूत वापरू शकता. आपण प्रणालीची कार्यक्षमता टिकवून ठेवण्याचा एक मार्ग म्हणजे लॉगिंगची पातळी आवश्यक पातळीवर ठेवणे. अर्थात, सर्व्हरद्वारे जितके अधिक लॉगिंग केले जाईल तितकेच सर्व्हरच्या कामगिरीवर परिणाम होऊ शकतो.

बहुतेक प्रशासकांना ज्या मुख्य सारण्यांमध्ये स्वारस्य असेल ते 6 टेबल आहेत जे वापरकर्त्याच्या क्रियाकलाप आणि सिस्टममधील क्रियाकलाप नोंदवतात.

• COGIPF_USERLOGON: वापरकर्ता लॉगऑन (लॉग ऑफसह) माहिती संग्रहित करतो
• COGIPF_RUNREPORT: अहवालाच्या अंमलबजावणीबद्दल माहिती संग्रहित करते
• COGIPF_VIEWREPORT: अहवाल पाहण्याच्या विनंत्यांविषयी माहिती संग्रहित करते
• COGIPF_EDITQUERY: क्वेरी रन बद्दल माहिती संग्रहित करते
• COGIPF_RUNJOB: नोकरीच्या विनंत्यांविषयी माहिती संग्रहित करते
• COGIPF_ACTION: कॉग्नोसमध्ये वापरकर्त्याच्या कृती रेकॉर्ड करतात (ही सारणी इतरांपेक्षा खूप वेगाने वाढू शकते)

आउट-ऑफ-द-बॉक्स कॉन्फिगरेशन असे दिसते:

शिफारस केलेले कॉन्फिगरेशन:

कॉग्नोस ऑडिट डेटाबेस - लाईव्हमध्ये 1 आठवड्याचा ऑडिट डेटा असतो. 1 आठवड्यापेक्षा जुना डेटा कॉग्नोस ऑडिट डेटाबेसमध्ये हलवला जातो - ऐतिहासिक.

कॉग्नोस ऑडिट डेटाबेसमधील लाईन - लाईव्ह टू कॉग्नोस ऑडिट डेटाबेस - डायग्राममधील ऐतिहासिक जबाबदार आहे:

• थेट ऑडिट पासून ऐतिहासिक ऑडिट मध्ये डेटा कॉपी करणे
• लाइव्ह ऑडिटमधील सर्व पंक्ती काढा ज्या 1 आठवड्यापेक्षा जुन्या आहेत
• X वर्षापेक्षा जुने असलेल्या ऐतिहासिक लेखापरीक्षणातील सर्व पंक्ती काढा
• COGIPF_ACTION मधील सर्व पंक्ती 6 महिन्यांपेक्षा जुन्या आहेत

अनुक्रमणिका

वेगवेगळ्या डेटाबेस प्रकारांमध्ये वेगवेगळे अनुक्रमणिका प्रकार आहेत. डेटाबेस इंडेक्स ही एक डेटा स्ट्रक्चर आहे, जो टेबल (किंवा व्ह्यू) शी संबंधित आहे, त्या टेबल (किंवा व्ह्यू) मधून डेटा पुनर्प्राप्त करताना क्वेरी एक्झिक्यूशन वेळ सुधारण्यासाठी वापरली जाते. इष्टतम धोरण तयार करण्यासाठी आपल्या DBA सह कार्य करा. कोणत्या स्तंभांना अनुक्रमित करायचे यावर सर्वोत्तम निर्णय घेण्यासाठी त्यांना यासारख्या प्रश्नांची उत्तरे जाणून घ्यायची इच्छा असेल. साहजिकच, डेटाबेस प्रशासक तुमच्या मदतीशिवाय काही किंवा सर्व प्रश्नांची उत्तरे शोधू शकतील, परंतु त्यासाठी काही संशोधन आणि काही वेळ लागेल:

• टेबलमध्ये किती रेकॉर्ड आहेत आणि ते कोणत्या आकारात वाढतील अशी तुमची अपेक्षा आहे? (टेबलमध्ये मोठ्या संख्येने नोंदी असल्याशिवाय टेबल अनुक्रमित करणे उपयुक्त ठरणार नाही.)
• तुम्हाला माहित आहे की कोणते स्तंभ अद्वितीय आहेत? ते शून्य मूल्यांना परवानगी देतात का? कोणत्या स्तंभांमध्ये डेटा प्रकार पूर्णांक किंवा मोठा पूर्णांक आहे? (संख्यात्मक डेटा प्रकार असलेले स्तंभ आणि ते अद्वितीय आहेत आणि शून्य नाहीत हे इंडेक्स की मध्ये भाग घेण्यासाठी मजबूत उमेदवार आहेत.)
• आज तुमच्या मुख्य कामगिरीच्या समस्या कुठे आहेत? ते डेटा पुनर्प्राप्त करत आहेत का? काही विशिष्ट प्रश्न किंवा अहवाल आहेत जे अधिक समस्या आहेत? (हे डेटाबेस प्रशासकाला काही विशिष्ट स्तंभांकडे नेऊ शकते जे ऑप्टिमाइझ केले जाऊ शकतात.)
• अहवाल देण्यासाठी सामील होण्यासाठी कोणती फील्ड वापरली जातात?
• फिल्टरिंग, सॉर्टिंग, ग्रुपिंग आणि एकत्रीकरणासाठी कोणती फील्ड वापरली जातात?

आश्चर्याची गोष्ट नाही, हे तेच प्रश्न आहेत ज्यांची उत्तरे कोणत्याही डेटाबेस सारण्यांचे कार्यप्रदर्शन सुधारण्यासाठी आवश्यक असतील.

आयबीएम समर्थन शिफारस करतो कामगिरी सुधारण्यासाठी खालील सारण्यांसाठी “COGIPF_REQUESTID”, “COGIPF_SUBREQUESTID” आणि “COGIPF_STEPID” स्तंभांवर अनुक्रमणिका तयार करणे:

• COGIPF_NATIVEQUERY
• COGIPF_RUNJOB
• COGIPF_RUNJOBSTEP
• COGIPF_RUNREPORT
• COGIPF_EDITQUERY

प्लस इतर कमी वापरलेल्या टेबलवर:

• COGIPF_POWERPLAY
• COGIPF_HUMANTASKSERVICE
• COGIPF_HUMANTASKSERVICE_DETAIL

आपण हे एक प्रारंभिक बिंदू म्हणून वापरू शकता, परंतु मी आपल्या संस्थेसाठी सर्वोत्तम उत्तर मिळविण्यासाठी वरील प्रश्नांची उत्तरे देण्याच्या व्यायामातून जाईन.

इतर अटी

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

निष्कर्ष

मुख्य गोष्ट अशी आहे की येथे प्रदान केलेल्या माहितीसह आपण आपल्या डीबीएबरोबर उत्पादक संभाषण करण्यासाठी चांगले तयार असावे. शक्यता चांगली आहे की तिने यापूर्वी अशाच समस्या सोडवल्या आहेत.

कॉग्नोस ऑडिट डेटाबेस आर्किटेक्चरमधील प्रस्तावित बदल थेट अहवाल तसेच तृतीय-पक्ष अनुप्रयोगांवर कामगिरी सुधारतील, जसे की Motioच्या ReportCard आणि यादी.

तसे, जर तुम्ही तुमच्या DBA शी संभाषण केले असेल तर आम्हाला त्याबद्दल ऐकायला आवडेल. तुम्ही खराब कामगिरी करणाऱ्या ऑडिट डेटाबेसचा प्रश्न सोडवला आहे आणि तुम्ही ते कसे केले हे आम्हाला ऐकायला आवडेल.