কগনোস অডিটিং ব্লগ - বড় এবং উচ্চ ভলিউম পরিবেশের জন্য টিপস এবং কৌশল

জন বয়র এবং মাইক নরিসের একটি ব্লগ।

ভূমিকা

আপনার ব্যবহারকারী সম্প্রদায় কীভাবে কগনোস ব্যবহার করছে তা জানতে এবং বোঝার জন্য কগনোস অডিটিং ক্ষমতা কাজ করা গুরুত্বপূর্ণ এবং প্রশ্নের উত্তর দিতে সাহায্য করুন:

• • কে সিস্টেম ব্যবহার করছে?
  • তারা কোন রিপোর্ট চালাচ্ছে?
  • রিপোর্ট চালানোর সময় কি?
  • অন্যান্য সরঞ্জামের সাহায্যে, যেমন MotioCI, কোন সামগ্রী অব্যবহৃত?

সুস্থ কগনোস অ্যানালিটিক্স পরিবেশ বজায় রাখা কতটা সমালোচনামূলক তা বিবেচনা করে, স্ট্যান্ডার্ড প্রোডাক্ট ডকুমেন্টেশনের বাইরে এর অডিটিং ডাটাবেস সম্পর্কে আশ্চর্যজনকভাবে খুব কম লেখা হয়েছে। সম্ভবত, এটি মঞ্জুরির জন্য নেওয়া হয়েছে, কিন্তু যে সংস্থাগুলি এটি ব্যবহার করে তারা জানে যে সময়ের সাথে সাথে অডিট ডেটাবেস টেবিলগুলি জিজ্ঞাসা করা ধীরে ধীরে শুরু হবে - বিশেষ করে যদি আপনার সংস্থার প্রচুর ব্যবহারকারী প্রচুর প্রতিবেদন চালায় এবং প্রচুর ইতিহাস থাকে। আরো কি হল যে অডিট কার্যকলাপ লগিং নিজেই বিলম্বিত হতে পারে কারণ এটি সারিবদ্ধ করা হচ্ছে যখন এটি দ্রুত ডাটাবেসে যুক্ত করা যাবে না, উদাহরণস্বরূপ। যখন আপনি ডেটাবেস পারফরম্যান্স সম্পর্কে ভাবতে শুরু করেন তখন আপনি যে কোনও অপারেশনাল ডাটাবেসের সাথে রিপোর্ট করার প্রয়োজনীয়তা রয়েছে।

বড় টেবিলগুলি সাধারণত ক্যোয়ারী পারফরম্যান্সকে ধীর করে। টেবিলটি যত বড়, সন্নিবেশ করতে এবং জিজ্ঞাসা করতে তত বেশি সময় লাগে। মনে রাখবেন যে এই টেবিল এবং অডিট ডাটাবেস মূলত একটি অপারেশনাল ডাটাবেস; লেখাগুলি ঘন ঘন ঘটছে এবং আমাদের বিরুদ্ধে কাজ করছে কারণ আমরা সেগুলোকে শুধুমাত্র পড়ার ক্রিয়াকলাপের জন্য ফোকাস করতে পারি না যেমন আপনি একটি ডেটা মার্টের সাথে করবেন।

অনেকটা কন্টেন্ট স্টোরের মতো, কগনোস পরিবেশের স্বাস্থ্যও অডিট ডাটাবেসের স্বাস্থ্যের কথা বিবেচনা করতে হবে। নিরীক্ষা ডেটাবেসের সীমাহীন বৃদ্ধি সময়ের সাথে একটি সমস্যা হয়ে উঠতে পারে এবং শেষ পর্যন্ত একটি কগনোস পরিবেশের সামগ্রিক কর্মক্ষমতাকে প্রভাবিত করতে পারে। বহিরাগত বিধিবিধান সহ অনেক সংস্থায় তাদের উপর চাপ দেওয়া হয়, সম্পূর্ণ নিরীক্ষা রেকর্ড না থাকা তাদের ভারী প্রতিক্রিয়ার সাথে অ-সম্মতিপূর্ণ পরিস্থিতিতে পড়তে পারে। তাহলে আমরা কিভাবে historicalতিহাসিক নিরীক্ষার উদ্দেশ্যে এত বেশি ডেটা বজায় রাখার মোকাবিলা করব - কিছু ক্ষেত্রে 10 বছর পর্যন্ত - তবুও পরিবেশ বজায় রাখতে এবং ব্যবহারকারীদের কর্মক্ষমতা নিয়ে খুশি রাখার জন্য আমাদের প্রয়োজনীয় প্রতিবেদন পেতে হবে।

চ্যালেঞ্জ

• • অডিট ডেটাবেজের সীমাহীন বৃদ্ধি কগনোস পরিবেশের স্বাস্থ্যের উপর নেতিবাচক প্রভাব ফেলছে
  • নিরীক্ষা ডেটাবেস বন্ধ রিপোর্ট করা ধীর বা অব্যবহারযোগ্য হয়ে উঠেছে
  • অডিট ডেটাবেজে রেকর্ড লিখতে কগনোস বিলম্ব অনুভব করে
  • অডিট ডেটাবেস ডিস্কের স্থান ফুরিয়ে যাচ্ছে

এই সবের মানে হল যে এটি শুধুমাত্র রিপোর্ট নয় যা অডিট ডেটাবেসের উপর নির্ভর করে যা ক্ষতিগ্রস্ত হয়, কিন্তু প্রায়শই পুরো সিস্টেম। যদি অডিট ডেটাবেস কগনোস কন্টেন্ট স্টোরের একই সার্ভারে থাকে, তাহলে সেই পরিবেশে কগনোসের সব কিছুর কার্যকারিতা প্রভাবিত হবে।

সেটআপ

আমরা মনে করি:

1. 1. Cognos Analytics ইনস্টল এবং চলমান
   2. কগনোস একটি নিরীক্ষা ডেটাবেজে লগ ইন করার জন্য কনফিগার করা হয়েছে
   1. • জায়গায় একটি অডিট ডাটাবেস আছে
      • Cognos প্রশাসনে উপযুক্ত অডিট লগিং স্তর সেট করুন
      • কগনোস দ্বারা ডাটাবেসে রেকর্ড লেখা হচ্ছে
   3. অডিট ডেটাবেস এক বছরেরও বেশি সময় ধরে ব্যবহার করা হচ্ছে
   4. পরিবেশ ব্যবহারকারীদের এবং মৃত্যুদণ্ডের সাথে খুব সক্রিয়
   5. অডিট প্যাকেজটি কগনোস ব্যবহারের ডেটা প্রকাশের জন্য ব্যবহার করা হচ্ছে
   6. আমরা অডিট ডেটাবেস রিপোর্টিং কর্মক্ষমতা উন্নত করতে চাই
   7. পুরানো রেকর্ডগুলি শুরু করা বা মুছে ফেলা সবসময় একটি বিকল্প নয়

আপনি যদি না করেন, তবুও, Cognos Audit ইনস্টল এবং কনফিগার করা আছে, লোডেস্টার সলিউশন, a Motio সঙ্গী, একটি চমৎকার আছে পোস্ট Cognos BI /CA তে নিরীক্ষা সক্ষম করার বিষয়ে

সমাধান

কিছু সম্ভাব্য সমাধান রয়েছে যা দ্রুত নিজেকে উপস্থাপন করে:

1. 1. এর দ্বারা ডেটার ভলিউম কমানো:
   1. • কিছু পুরনো তথ্য অন্য ডাটাবেসে স্থানান্তর করা
      • কিছু পুরনো ডেটা একই ডাটাবেসের অন্য টেবিলে স্থানান্তর করা
   2. শুধু মুছুন বা চাপুনhive কিছু তথ্য এবং এটি সম্পর্কে চিন্তা করবেন না
   3. এটার সাথে বসবাস. নিচে ক্যান লাথি road এবং কর্মক্ষমতার জন্য ডাটাবেস প্রশাসককে ধাক্কা দিন
      স্কিমা পরিবর্তন করার অনুমতি না দিয়ে তাদের হাতকড়া দেওয়ার সময় উন্নতি বা
      ইনডেক্স

আমরা বিকল্প 3 এর সাথে মোকাবিলা করতে যাচ্ছি না। বিকল্প 2, ডেটা মুছে ফেলা একটি ভাল বিকল্প নয় এবং আমি অন্তত 18 মাসের মূল্য ন্যূনতম রাখার পরামর্শ দিচ্ছি। কিন্তু, যদি আপনি এতটা ঝুঁকে থাকেন, আইবিএম একটি ইউটিলিটি প্রদান করে, অডিটডিবিসিক্লিনআপ (Cognos BI) বা a লিপি (Cognos Analytics) যা ঠিক তাই করবে। কগনোস বিআই এর ইউটিলিটি টাইমস্ট্যাম্পের উপর ভিত্তি করে রেকর্ড মুছে দেয় যখন কগনোস অ্যানালিটিক্সের স্ক্রিপ্টগুলি শুধু ইনডেক্স এবং টেবিল মুছে দেয়।

আমরা এর আগে ক্লায়েন্টদের যে সুপারিশ করেছি তা হল দুটি ডাটাবেসে বিভক্ত করা:

1. 1. নিরীক্ষা - লাইভ: সাম্প্রতিক সপ্তাহের মূল্যবান তথ্য রয়েছে
   2. নিরীক্ষা - orতিহাসিক: historicalতিহাসিক তথ্য রয়েছে (N বছর পর্যন্ত)

সংক্ষেপে, অডিট লাইভ থেকে অডিট Histতিহাসিকের সাম্প্রতিক রেকর্ডগুলি সরানোর জন্য প্রক্রিয়াটি সাপ্তাহিকভাবে চলে। এই প্রক্রিয়া চলার পর একটি ফাঁকা স্লেট হিসাবে অডিট লাইভ শুরু হয়।

1. 1. লাইভ ডিবি দ্রুত এবং টাইট, যাতে সন্নিবেশগুলি যত তাড়াতাড়ি সম্ভব ঘটতে দেয়
   2. নিরীক্ষার প্রশ্নগুলি একচেটিয়াভাবে Histতিহাসিক ডিবি -তে পরিচালিত হয়

এই পদ্ধতিটি ব্যবহার করে, লাইভ ডেটা এবং orতিহাসিক ডেটাগুলির কোনও "একসাথে সেলাই" নেই। আমি যুক্তি দেব যে আপনি সম্ভবত এটিকে এভাবে রাখতে চান।

কগনোস অ্যাডমিনিস্ট্রেশনে, আপনি অডিট ডেটা সোর্সের জন্য দুটি ভিন্ন সংযোগ যুক্ত করতে পারেন। যখন একজন ব্যবহারকারী অডিট প্যাকেজের বিরুদ্ধে একটি রিপোর্ট চালায়, তখন তারা কোন সংযোগের জন্য তারা ব্যবহার করতে চায় তা অনুরোধ করা হয়:

আপনি যদি historicalতিহাসিক নিরীক্ষার ডেটার বদলে লাইভ অডিট ডেটা দেখতে চান, তাহলে অনুরোধ করার সময় আপনি কেবল "অডিট - লাইভ" সংযোগটি বেছে নিন (ব্যতিক্রম হওয়া উচিত, আদর্শ নয়।)

আপনি যদি সত্যিই লাইভ এবং orতিহাসিক উভয়ের একত্রিত দৃষ্টিভঙ্গি প্রদান করতে চান, তাহলে আপনি এটি করতে পারেন, কিন্তু এটি কর্মক্ষমতাকে প্রভাবিত করবে।

উদাহরণস্বরূপ, আপনি "অডিট - কনসোলিডেটেড ভিউ" নামে একটি তৃতীয় ডাটাবেস তৈরি করতে পারেন এবং তারপরে অডিট স্কিমার প্রতিটি টেবিলের জন্য: একটি সমানভাবে নামযুক্ত ভিউ তৈরি করুন যা লাইভ ডিবি এবং টেবিলের মধ্যে টেবিলের মধ্যে একটি এসকিউএল ইউনিয়ন। historicalতিহাসিক ডিবি। একইভাবে, এটি ফ্রেমওয়ার্ক ম্যানেজার মডেলেও অর্জন করা যেতে পারে, কিন্তু, আবার, কর্মক্ষমতা একটি মূল বিবেচ্য বিষয় হবে।

আমাদের কিছু ক্লায়েন্ট একত্রিত দৃষ্টিভঙ্গি তৈরি করেছে। এটি আমাদের মতামত যে এটি সম্ভবত ওভারকিল। এই একত্রীকৃত দৃশ্যে পারফরম্যান্স সবসময়ই খারাপ হবে এবং আমরা লাইভ ডেটা সেট এবং bothতিহাসিক উভয় ব্যবহার করে এমন অনেক ব্যবহারের ক্ষেত্রে আসিনি। সমস্যাটি সমাধানের জন্য লাইভ ব্যবহার করা হচ্ছে এবং ট্রেন্ড রিপোর্টিংয়ের জন্য orতিহাসিক।

কগনোস অ্যানালিটিক্স 11.1.7 অনুযায়ী, অডিট ডেটাবেস 21 টেবিলে উন্নীত হয়েছে। আপনি অডিট ডেটাবেস, নমুনা নিরীক্ষা প্রতিবেদন এবং ফ্রেমওয়ার্ক ম্যানেজার মডেলের অন্য কোথাও আরও তথ্য পেতে পারেন। ডিফল্ট লগিং স্তরটি ন্যূনতম, কিন্তু আপনি ব্যবহারের অনুরোধ, ব্যবহারকারীর অ্যাকাউন্ট ব্যবস্থাপনা এবং রানটাইম ব্যবহার ক্যাপচার করতে পরবর্তী স্তর, বেসিক ব্যবহার করতে চাইতে পারেন। সিস্টেমের পারফরম্যান্স বজায় রাখার একটি উপায় হল লগিং লেভেলকে সর্বনিম্ন স্তরে রাখা। স্পষ্টতই, সার্ভার দ্বারা যত বেশি লগিং করা হয়, সামগ্রিক সার্ভারের কার্যকারিতা প্রভাবিত হতে পারে।

সর্বাধিক অ্যাডমিনিস্ট্রেটররা যে প্রধান টেবিলে আগ্রহী হবে সেগুলি হল tables টেবিল যা ব্যবহারকারীর কার্যকলাপ এবং সিস্টেমে রিপোর্টিং কার্যকলাপ লগ করে।

• COGIPF_USERLOGON: ব্যবহারকারীর লগঅন (লগ অফ সহ) তথ্য সংরক্ষণ করে
• COGIPF_RUNREPORT: রিপোর্ট কার্যকর করার বিষয়ে তথ্য সংরক্ষণ করে
• COGIPF_VIEWREPORT: রিপোর্ট দেখার অনুরোধের তথ্য সংরক্ষণ করে
• COGIPF_EDITQUERY: ক্যোয়ারী রান সম্পর্কে তথ্য সঞ্চয় করে
• COGIPF_RUNJOB: চাকরির অনুরোধ সম্পর্কে তথ্য সংরক্ষণ করে
• COGIPF_ACTION: Cognos- এ ব্যবহারকারীর কর্ম রেকর্ড করে (এই টেবিলটি অন্যদের তুলনায় অনেক দ্রুত বৃদ্ধি পেতে পারে)

আউট-অফ-দ্য-বক্স কনফিগারেশন এইরকম দেখাচ্ছে:

প্রস্তাবিত কনফিগারেশন:

কগনোস অডিট ডেটাবেস - লাইভে 1 সপ্তাহের অডিট ডেটা রয়েছে। 1 সপ্তাহের পুরনো ডেটা কগনোস অডিট ডেটাবেসে স্থানান্তরিত করা হয়েছে - তিহাসিক।

কগনোস অডিট ডেটাবেস থেকে লাইন - লাইভ টু কগনোস অডিট ডাটাবেস - ডায়াগ্রামে orতিহাসিক এর জন্য দায়ী:

• লাইভ অডিট থেকে Histতিহাসিক নিরীক্ষায় ডেটা অনুলিপি করা
• লাইভ অডিটের সমস্ত সারিগুলি সরান যা 1 সপ্তাহের চেয়ে পুরানো
• Yearsতিহাসিক নিরীক্ষায় সমস্ত সারি সরান যা x বছরের চেয়ে পুরানো
• COGIPF_ACTION এর r মাসের চেয়ে পুরোনো সব সারি সরান

ইনডেক্সে

বিভিন্ন ডাটাবেস প্রকারের বিভিন্ন সূচকের ধরন রয়েছে। একটি ডাটাবেস ইনডেক্স হল একটি ডেটা স্ট্রাকচার, যা একটি টেবিল (বা ভিউ) এর সাথে যুক্ত, সেই টেবিল (বা ভিউ) থেকে ডেটা পুনরুদ্ধারের সময় প্রশ্নের বাস্তবায়নের সময় উন্নত করতে ব্যবহৃত হয়। সর্বোত্তম কৌশল তৈরি করতে আপনার DBA এর সাথে কাজ করুন। কোন কলামের সূচী করা উচিত সে বিষয়ে সেরা সিদ্ধান্ত নিতে তারা এই ধরনের প্রশ্নের উত্তর জানতে চাইবে। স্পষ্টতই, ডাটাবেস অ্যাডমিনিস্ট্রেটর আপনার সাহায্য ছাড়া কিছু বা সব প্রশ্নের উত্তর খুঁজে পেতে পারে, কিন্তু এটি কিছু গবেষণা এবং কিছু সময় লাগবে:

• টেবিলগুলিতে কতগুলি রেকর্ড রয়েছে এবং আপনি সেগুলি কী আকারে বাড়বে বলে আশা করেন? (একটি টেবিল সূচী করা দরকারী হবে না যদি না টেবিলে প্রচুর সংখ্যক রেকর্ড থাকে।)
• আপনি কি জানেন যে কলামগুলি অনন্য? তারা কি শূন্য মান অনুমোদন করে? কোন কলামের ডাটা টাইপ ইন্টিজার বা বড় ইন্টিজার আছে? (সংখ্যাসূচক ডেটা প্রকারের কলামগুলি এবং যেগুলি অনন্য এবং শূন্য নয় তা সূচক কীতে অংশগ্রহণের জন্য শক্তিশালী প্রার্থী।)
• আজ আপনার প্রধান কর্মক্ষমতা সমস্যা কোথায়? তারা কি তথ্য পুনরুদ্ধার করছে? কোন নির্দিষ্ট প্রশ্ন বা রিপোর্ট আছে যা একটি সমস্যা বেশি? (এটি ডাটাবেস প্রশাসককে কিছু নির্দিষ্ট কলামে নিয়ে যেতে পারে যা অপ্টিমাইজ করা যায়।)
• রিপোর্টিংয়ের জন্য টেবিলে যোগদান করতে কোন ক্ষেত্রগুলি ব্যবহার করা হয়?
• ফিল্টারিং, বাছাই, গ্রুপিং এবং একত্রীকরণের জন্য কোন ক্ষেত্রগুলি ব্যবহার করা হয়?

আশ্চর্যজনক নয়, এগুলি একই প্রশ্ন যা কোনও ডাটাবেস সারণির কর্মক্ষমতা উন্নত করার জন্য উত্তর দিতে হবে।

IBM সাপোর্ট বিশেষ পরামর্শ দেওয়া হচ্ছে কর্মক্ষমতা উন্নত করতে নিম্নলিখিত টেবিলের জন্য "COGIPF_REQUESTID", "COGIPF_SUBREQUESTID", এবং "COGIPF_STEPID" কলামগুলিতে একটি সূচক তৈরি করা হচ্ছে:

• COGIPF_NATIVEQUERY
• COGIPF_RUNJOB
• COGIPF_RUNJOBSTEP
• COGIPF_RUNREPORT
• COGIPF_EDITQUERY

প্লাস অন্যান্য কম ব্যবহৃত টেবিলে:

• COGIPF_POWERPLAY
• COGIPF_HUMANTASKSERVICE
• COGIPF_HUMANTASKSERVICE_DETAIL

আপনি এটি একটি প্রারম্ভিক বিন্দু হিসাবে ব্যবহার করতে পারেন, তবে আমি আপনার সংস্থার জন্য সর্বোত্তম উত্তরে পৌঁছানোর জন্য উপরের প্রশ্নের উত্তর দেওয়ার অনুশীলনের মধ্য দিয়ে যাব।

অন্যান্য বিবেচ্য বিষয়

1. অডিট এফএম মডেল। মনে রাখবেন যে ফ্রেমওয়ার্ক ম্যানেজার মডেল যা আইবিএম প্রদান করে তা ডিফল্ট টেবিল এবং ক্ষেত্রগুলিতে মডেল করা হয়। আপনি রিপোর্টিং টেবিলে যে কোন পরিবর্তন মডেলটিতে প্রতিফলিত হতে হবে। এই পরিবর্তনগুলির সহজতা বা জটিলতা - অথবা এই পরিবর্তনগুলি করার জন্য আপনার সাংগঠনিক দক্ষতা - আপনার চয়ন করা সমাধানকে প্রভাবিত করতে পারে।
2. অতিরিক্ত ক্ষেত্র। আপনি যদি এটি করতে যাচ্ছেন, নিরীক্ষা রিপোর্টিং উন্নত করার জন্য এখন প্রসঙ্গ বা রেফারেন্স ডেটার জন্য অতিরিক্ত ক্ষেত্র যুক্ত করার সময়।
3. সারাংশ টেবিল। শুধু আপনার historicalতিহাসিক টেবিলে ডেটা অনুলিপি করার পরিবর্তে, এটি সংকুচিত করুন। রিপোর্টিংয়ের জন্য ডেটাকে আরও দক্ষ করার জন্য আপনি ডেটা ডে ডেভেলপ করতে পারেন।
4. টেবিলের বদলে ভিউ। অন্যরা বলে, "সুতরাং, 'বর্তমান' ডাটাবেস এবং 'historicalতিহাসিক' ডাটাবেস থাকার পরিবর্তে, আপনার কেবল একটি ডাটাবেস থাকা উচিত এবং এর সমস্ত টেবিলের ''তিহাসিক' উপসর্গ থাকা উচিত। তারপরে, আপনার প্রত্যেকটি টেবিলের জন্য একটি ভিউ তৈরি করা উচিত, যা আপনি 'বর্তমান' হিসাবে দেখতে চান এবং প্রতিটি ভিউ theতিহাসিক সারিগুলি যা আপনি দেখতে চান না তা ফিল্টার করুন এবং শুধুমাত্র বর্তমানের মধ্য দিয়ে যেতে দিন। "
   https://softwareengineering.stackexchange.com/questions/276395/two-database-architecture-operational-and-historical/276419#276419

উপসংহার

নিচের লাইনটি হল যে এখানে প্রদত্ত তথ্যের সাথে আপনার ডিবিএর সাথে একটি উত্পাদনশীল কথোপকথন করার জন্য আপনাকে ভালভাবে প্রস্তুত থাকতে হবে। সম্ভাবনা ভাল যে সে আগেও অনুরূপ সমস্যার সমাধান করেছে।

কগনোস অডিট ডেটাবেস আর্কিটেকচারে প্রস্তাবিত পরিবর্তনগুলি সরাসরি রিপোর্টিংয়ের পাশাপাশি তৃতীয় পক্ষের অ্যাপ্লিকেশনগুলির উপর কর্মক্ষমতা উন্নত করবে, যেমন এটি নির্ভর করে Motio'গুলি ReportCard এবং ইনভেন্টরি।

যাইহোক, যদি আপনি আপনার DBA এর সাথে সেই কথোপকথনটি করেন তবে আমরা এটি সম্পর্কে শুনতে চাই। আপনি একটি খারাপ পারফর্মিং অডিট ডাটাবেসের সমস্যাটি সমাধান করেছেন এবং আপনি কীভাবে এটি করেছেন তা আমরা শুনতে চাই।