บล็อกการตรวจสอบ Cognos – เคล็ดลับและคำแนะนำสำหรับสภาพแวดล้อมที่มีปริมาณมาก & มาก

บล็อกโดย John Boyer และ Mike Norris

บทนำ

เป็นสิ่งสำคัญที่จะต้องมีความสามารถในการตรวจสอบ Cognos เพื่อทราบและทำความเข้าใจว่าชุมชนผู้ใช้ของคุณใช้ Cognos อย่างไร และช่วยตอบคำถามเช่น:

• • ใครใช้ระบบอยู่บ้าง?
  • พวกเขากำลังรายงานอะไรอยู่?
  • เวลาเรียกใช้รายงานคืออะไร?
  • ด้วยความช่วยเหลือของเครื่องมืออื่น ๆ เช่น MotioCI, เนื้อหาใดที่ไม่ได้ใช้?

เมื่อพิจารณาถึงความสำคัญของการรักษาสภาวะแวดล้อม Cognos Analytics ให้แข็งแรง มีการเขียนเพียงเล็กน้อยเกี่ยวกับฐานข้อมูลการตรวจสอบนอกเหนือจากเอกสารผลิตภัณฑ์มาตรฐาน บางทีอาจถือเป็นเรื่องปกติ แต่องค์กรที่ใช้ฐานข้อมูลนี้ทราบดีว่าการสอบถามตารางฐานข้อมูลการตรวจสอบเมื่อเวลาผ่านไปจะเริ่มช้าลง โดยเฉพาะอย่างยิ่งถ้าองค์กรของคุณมีผู้ใช้จำนวนมากที่เรียกใช้รายงานจำนวนมากและมีประวัติมากมาย ยิ่งไปกว่านั้น การบันทึกกิจกรรมการตรวจสอบเองอาจล่าช้า เนื่องจากถูกจัดคิวเมื่อไม่สามารถเพิ่มลงในฐานข้อมูลได้เร็วพอ เป็นต้น นั่นคือเมื่อคุณเริ่มคิดถึงประสิทธิภาพของฐานข้อมูล เช่นเดียวกับฐานข้อมูลปฏิบัติการใดๆ ที่มีข้อกำหนดในการรายงาน

ตารางขนาดใหญ่มักจะทำให้ประสิทธิภาพของคิวรีช้าลง ยิ่งตารางมีขนาดใหญ่เท่าใด ก็ยิ่งใช้เวลาในการแทรกและสอบถามนานขึ้นเท่านั้น โปรดจำไว้ว่าตารางเหล่านี้และฐานข้อมูลการตรวจสอบนั้นเป็นฐานข้อมูลการดำเนินงาน การเขียนเกิดขึ้นบ่อยครั้งและต่อต้านเรา เนื่องจากเราไม่สามารถเน้นพวกเขาสำหรับการดำเนินการอ่านอย่างเดียวได้เหมือนกับที่คุณทำกับดาต้ามาร์ท

เช่นเดียวกับที่เก็บเนื้อหา ความสมบูรณ์ของสภาพแวดล้อม Cognos ต้องคำนึงถึงความสมบูรณ์ของฐานข้อมูลการตรวจสอบด้วย การเติบโตที่ไม่จำกัดของฐานข้อมูลการตรวจสอบสามารถกลายเป็นปัญหาเมื่อเวลาผ่านไป และอาจส่งผลต่อประสิทธิภาพโดยรวมของสภาพแวดล้อม Cognos ในท้ายที่สุด ในหลายๆ องค์กรที่มีข้อบังคับภายนอกบังคับใช้ การไม่มีบันทึกการตรวจสอบที่สมบูรณ์อาจทำให้พวกเขาตกอยู่ในสถานการณ์ที่ไม่ปฏิบัติตามซึ่งส่งผลกระทบอย่างมาก แล้วเราจะจัดการอย่างไรกับการต้องรักษาข้อมูลจำนวนมากเพื่อวัตถุประสงค์ในการตรวจสอบในอดีต ในบางกรณีอาจนานถึง 10 ปี แต่ยังคงได้รับรายงานที่เราต้องการเพื่อรักษาสภาพแวดล้อมและให้ผู้ใช้พึงพอใจกับประสิทธิภาพการทำงาน

ความท้าทาย

• • การเติบโตอย่างไร้ขอบเขตของฐานข้อมูลการตรวจสอบส่งผลกระทบในทางลบต่อความสมบูรณ์ของสภาพแวดล้อม Cognos
  • การรายงานจากฐานข้อมูลการตรวจสอบได้ช้าหรือใช้งานไม่ได้
  • Cognos ประสบกับความล่าช้าในเร็กคอร์ดที่เขียนไปยังฐานข้อมูลการตรวจสอบ
  • ฐานข้อมูลการตรวจสอบมีพื้นที่ดิสก์ไม่เพียงพอ

ทั้งหมดนี้หมายความว่าไม่ใช่แค่รายงานที่อาศัยฐานข้อมูลการตรวจสอบที่ได้รับผลกระทบ แต่บ่อยครั้งที่ทั้งระบบ ถ้าฐานข้อมูลการตรวจสอบอยู่บนเซิร์ฟเวอร์เดียวกับที่เก็บเนื้อหา Cognos ประสิทธิภาพของทุกสิ่งที่ Cognos จะได้รับผลกระทบในสภาพแวดล้อมนั้น

การตั้งค่า

เราถือว่า:

1. 1. Cognos Analytics ได้รับการติดตั้งและรันอยู่
   2. Cognos ถูกกำหนดคอนฟิกเพื่อล็อกเข้าสู่ฐานข้อมูลการตรวจสอบ
   1. • มีฐานข้อมูลการตรวจสอบอยู่แล้ว
      • ตั้งค่าระดับการบันทึกการตรวจสอบที่เหมาะสมในการบริหารระบบ Cognos
      • กำลังเขียนบันทึกไปยังฐานข้อมูลโดย Cognos
   3. ฐานข้อมูลการตรวจสอบมีการใช้งานมานานกว่าหนึ่งปี
   4. สภาพแวดล้อมมีการใช้งานมากกับผู้ใช้และการประหารชีวิต
   5. กำลังใช้แพ็กเกจการตรวจสอบเพื่อแสดงข้อมูลการใช้งาน Cognos
   6. เรากำลังปรับปรุงประสิทธิภาพการรายงานของฐานข้อมูลการตรวจสอบ
   7. การเริ่มต้นใหม่หรือการลบระเบียนเก่าไม่ใช่ตัวเลือกเสมอไป

หากคุณยังไม่ได้ติดตั้งและกำหนดค่า Cognos Audit, Lodestar Solutions, a Motio พันธมิตรมีความยอดเยี่ยม เสา เกี่ยวกับการเปิดใช้งานการตรวจสอบใน Cognos BI /CA

โซลูชั่น

มีวิธีแก้ปัญหาที่เป็นไปได้ที่นำเสนออย่างรวดเร็ว:

1. 1. ลดปริมาณข้อมูลโดย:
   1. • การย้ายข้อมูลเก่าบางส่วนไปยังฐานข้อมูลอื่น
      • การย้ายข้อมูลเก่าบางส่วนไปยังตารางอื่นในฐานข้อมูลเดียวกัน
   2. เพียงแค่ลบหรือ archive ข้อมูลบางส่วนและไม่ต้องกังวลกับมัน
   3. อยู่กับมัน เตะกระป๋องลง road และผลักดันผู้ดูแลฐานข้อมูลเพื่อประสิทธิภาพ
      ปรับปรุงในขณะที่ใส่กุญแจมือโดยไม่อนุญาตให้เปลี่ยนแปลงสคีมาหรือ
      ดัชนี

เราจะไม่จัดการกับตัวเลือก 3 ตัวเลือกที่ 2 การลบข้อมูลไม่ใช่ตัวเลือกที่ดี และฉันขอแนะนำให้รักษาค่าอย่างน้อย 18 เดือนเป็นอย่างน้อย แต่ถ้าคุณมีความโน้มเอียงมาก IBM ได้จัดเตรียมยูทิลิตี้ AuditDB การล้างข้อมูล (Cognos BI) หรือ a ต้นฉบับ (Cognos Analytics) ซึ่งจะทำอย่างนั้นเอง ยูทิลิตีสำหรับ Cognos BI จะลบเร็กคอร์ดตามการประทับเวลา ในขณะที่สคริปต์สำหรับ Cognos Analytics จะลบดัชนีและตารางเท่านั้น

คำแนะนำที่เราได้แจ้งไว้กับลูกค้าก่อนหน้านี้คือให้แยกฐานข้อมูลออกเป็นสองฐานข้อมูล:

1. 1. Audit – Live : มีข้อมูลของสัปดาห์ล่าสุด
   2. การตรวจสอบ – ย้อนหลัง : มีข้อมูลย้อนหลัง (ไม่เกิน N ปี)

กล่าวโดยย่อ กระบวนการทำงานทุกสัปดาห์เพื่อย้ายเรกคอร์ดล่าสุดจาก Audit Live เป็น Audit Historical Audit Live เริ่มต้นใหม่เป็นกระดานสเลทเปล่าหลังจากกระบวนการนี้ทำงาน

1. 1. Live DB นั้นเร็วและแน่น ทำให้การแทรกเกิดขึ้นได้เร็วที่สุด
   2. แบบสอบถามการตรวจสอบมุ่งตรงไปยังฐานข้อมูลย้อนหลังเท่านั้น

เมื่อใช้วิธีนี้ จะไม่มีการ "ต่อกัน" โดยนัยของข้อมูลสดและข้อมูลทางประวัติศาสตร์ ฉันจะเถียงว่าคุณอาจต้องการให้มันเป็นเช่นนั้น

ใน Cognos Administration คุณสามารถเพิ่มการเชื่อมต่อที่แตกต่างกันสองรายการสำหรับแหล่งข้อมูลการตรวจสอบ เมื่อผู้ใช้เรียกใช้รายงานกับแพ็คเกจการตรวจสอบ พวกเขาจะได้รับพร้อมท์ว่าต้องการใช้การเชื่อมต่อใด:

ในโอกาสที่คุณต้องการดูข้อมูลการตรวจสอบสดมากกว่าข้อมูลการตรวจสอบในอดีต คุณเพียงแค่เลือกการเชื่อมต่อ "ตรวจสอบ - สด" เมื่อได้รับแจ้ง (ควรเป็นข้อยกเว้น ไม่ใช่บรรทัดฐาน)

หากคุณต้องการให้มุมมองรวมของทั้งการแสดงสดและประวัติศาสตร์ด้วยจริงๆ คุณสามารถทำได้ แต่จะส่งผลต่อประสิทธิภาพการทำงาน

ตัวอย่างเช่น คุณสามารถสร้างฐานข้อมูลที่ 3 ชื่อ “Audit – Consolidated View” จากนั้น สำหรับแต่ละตารางในสคีมาการตรวจสอบ ให้สร้างมุมมองที่มีชื่อเหมือนกันซึ่งเป็นการรวม SQL ระหว่างตารางใน live DB และตารางใน ฐานข้อมูลประวัติศาสตร์ ในทำนองเดียวกัน สามารถทำได้ในโมเดล Framework Manager แต่ประสิทธิภาพจะเป็นข้อพิจารณาหลักอีกครั้ง

ลูกค้าบางรายของเราได้สร้างมุมมองแบบรวม เป็นความเห็นของเราว่าสิ่งนี้น่าจะเกินกำลัง ประสิทธิภาพจะแย่ลงเสมอในมุมมองแบบรวมนี้ และเราไม่พบกรณีการใช้งานจำนวนมากที่ใช้ทั้งชุดข้อมูลแบบสดและแบบย้อนหลัง Live ใช้สำหรับการแก้ไขปัญหาและประวัติสำหรับการรายงานแนวโน้ม

จาก Cognos Analytics 11.1.7 ฐานข้อมูลการตรวจสอบได้เพิ่มขึ้นเป็น 21 ตาราง คุณสามารถค้นหาข้อมูลเพิ่มเติมได้จากที่อื่นในฐานข้อมูลการตรวจสอบ รายงานการตรวจสอบตัวอย่าง และโมเดล Framework Manager ระดับการบันทึกเริ่มต้นคือขั้นต่ำ แต่คุณอาจต้องการใช้ระดับถัดไป พื้นฐาน เพื่อบันทึกคำขอใช้งาน การจัดการบัญชีผู้ใช้ และการใช้งานรันไทม์ วิธีหนึ่งที่คุณสามารถรักษาประสิทธิภาพของระบบได้คือการรักษาระดับการบันทึกให้อยู่ในระดับต่ำสุดที่จำเป็น เห็นได้ชัดว่า ยิ่งเซิร์ฟเวอร์ทำการบันทึกมากเท่าใด ประสิทธิภาพของเซิร์ฟเวอร์โดยรวมก็จะยิ่งได้รับผลกระทบมากขึ้นเท่านั้น

ตารางสำคัญที่ผู้ดูแลระบบส่วนใหญ่จะสนใจคือตาราง 6 ตารางที่บันทึกกิจกรรมของผู้ใช้และกิจกรรมการรายงานในระบบ

• COGIPF_USERLOGON : เก็บข้อมูลการเข้าสู่ระบบของผู้ใช้ (รวมถึงการออกจากระบบ)
• COGIPF_RUNREPORT : เก็บข้อมูลเกี่ยวกับการดำเนินการรายงาน
• COGIPF_VIEWREPORT : เก็บข้อมูลเกี่ยวกับคำขอดูรายงาน
• COGIPF_EDITQUERY : เก็บข้อมูลเกี่ยวกับการเรียกใช้แบบสอบถาม
• COGIPF_RUNJOB : เก็บข้อมูลเกี่ยวกับการของาน
• COGIPF_ACTION : บันทึกการกระทำของผู้ใช้ใน Cognos (ตารางนี้อาจเติบโตได้เร็วกว่าตารางอื่นมาก)

การกำหนดค่าแบบสำเร็จรูปมีลักษณะดังนี้:

การกำหนดค่าที่แนะนำ:

ฐานข้อมูลการตรวจสอบ Cognos – Live มีข้อมูลการตรวจสอบ 1 สัปดาห์ ข้อมูลที่เก่ากว่า 1 สัปดาห์ถูกย้ายไปยังฐานข้อมูลการตรวจสอบ Cognos – เชิงประวัติ

บรรทัดจากฐานข้อมูล Cognos Audit – Live to Cognos Audit Database – Historical ในไดอะแกรมรับผิดชอบ:

• การคัดลอกข้อมูลจาก Live Audit ไปยัง Historical Audit
• ลบแถวทั้งหมดใน Live Audit ที่เก่ากว่า 1 สัปดาห์
• ลบแถวทั้งหมดใน Historical Audit ที่เก่ากว่า x ปี
• ลบแถวทั้งหมดใน COGIPF_ACTION ที่เก่ากว่า 6 เดือน

ดัชนี

ฐานข้อมูลประเภทต่างๆ มีประเภทการจัดทำดัชนีที่แตกต่างกัน ดัชนีฐานข้อมูลคือโครงสร้างข้อมูลที่เชื่อมโยงกับตาราง (หรือมุมมอง) ซึ่งใช้เพื่อปรับปรุงเวลาในการดำเนินการค้นหาเมื่อดึงข้อมูลจากตารางนั้น (หรือมุมมอง) ทำงานร่วมกับ DBA ของคุณเพื่อสร้างกลยุทธ์ที่เหมาะสมที่สุด พวกเขาจะต้องการทราบคำตอบของคำถามเช่นนี้เพื่อตัดสินใจได้ดีที่สุดว่าควรจัดทำดัชนีคอลัมน์ใด เห็นได้ชัดว่าผู้ดูแลระบบฐานข้อมูลสามารถค้นหาคำตอบสำหรับคำถามเหล่านี้บางส่วนหรือทั้งหมดโดยไม่ได้รับความช่วยเหลือจากคุณ แต่ต้องใช้เวลาค้นคว้าและใช้เวลาสักครู่:

• ตารางมีกี่ระเบียน และคุณคาดว่าตารางจะมีขนาดเท่าใด (การจัดทำดัชนีตารางจะไม่เป็นประโยชน์เว้นแต่ว่าตารางจะมีระเบียนจำนวนมาก)
• คุณรู้หรือไม่ว่าคอลัมน์ใดไม่ซ้ำกัน? พวกเขาอนุญาตให้มีค่า NULL หรือไม่ คอลัมน์ใดมีประเภทข้อมูลเป็นจำนวนเต็มหรือจำนวนเต็มขนาดใหญ่ (คอลัมน์ที่มีประเภทข้อมูลที่เป็นตัวเลขและ UNIQUE และ NOT NULL เป็นตัวเลือกที่ดีในการเข้าร่วมในคีย์ดัชนี)
• วันนี้ปัญหาด้านประสิทธิภาพหลักของคุณอยู่ที่ไหน พวกเขากำลังดึงข้อมูลหรือไม่? มีคำถามหรือรายงานเฉพาะที่เป็นปัญหามากกว่าหรือไม่ (ซึ่งอาจนำผู้ดูแลระบบฐานข้อมูลไปยังคอลัมน์เฉพาะบางคอลัมน์ที่สามารถปรับให้เหมาะสมได้)
• เขตข้อมูลใดที่ใช้ในการเข้าร่วมตารางสำหรับการรายงาน
• ฟิลด์ใดบ้างที่ใช้สำหรับการกรอง การเรียงลำดับ การจัดกลุ่ม และการรวม

ไม่น่าแปลกใจเลยที่คำถามเหล่านี้เป็นคำถามเดียวกันซึ่งจำเป็นต้องตอบเพื่อปรับปรุงประสิทธิภาพของตารางฐานข้อมูล

ฝ่ายสนับสนุนของ IBM แนะนำ การสร้างดัชนีในคอลัมน์ “COGIPF_REQUESTID”, “COGIPF_SUBREQUESTID” และ “COGIPF_STEPID” สำหรับตารางต่อไปนี้เพื่อปรับปรุงประสิทธิภาพ:

• COGIPF_NATIVEQUERY
• COGIPF_RUNJOB
• COGIPF_RUNJOBSTEP
• COGIPF_RUNรายงาน
• COGIPF_EDITQUERY

บวกกับโต๊ะอื่นๆ ที่ใช้งานน้อย:

• COGIPF_POWERPLAY
• COGIPF_HUMANTASKSERVICE
• COGIPF_HUMANTASKSERVICE_DETAIL

คุณสามารถใช้สิ่งนี้เป็นจุดเริ่มต้นได้ แต่ฉันจะฝึกตอบคำถามข้างต้นเพื่อให้ได้คำตอบที่ดีที่สุดสำหรับองค์กรของคุณ

ควรพิจารณาอื่น ๆ

1. ตรวจสอบรุ่น FM จำไว้ว่าโมเดล Framework Manager ที่ IBM จัดเตรียมไว้นั้นถูกสร้างโมเดลบนตารางและฟิลด์ดีฟอลต์ การเปลี่ยนแปลงใดๆ ที่คุณทำกับตารางการรายงานจะต้องมีผลกับแบบจำลอง ความง่ายหรือความซับซ้อนของการเปลี่ยนแปลงเหล่านี้ หรือความสามารถขององค์กรของคุณในการเปลี่ยนแปลงเหล่านี้ อาจส่งผลต่อโซลูชันที่คุณเลือก
2. ฟิลด์เพิ่มเติม หากคุณกำลังจะทำ ตอนนี้เป็นเวลาที่จะเพิ่มฟิลด์เพิ่มเติมสำหรับข้อมูลบริบทหรือข้อมูลอ้างอิงเพื่อปรับปรุงการรายงานการตรวจสอบ
3. ตารางสรุป. แทนที่จะเพียงแค่คัดลอกข้อมูลไปยังตารางประวัติของคุณ ให้บีบอัดข้อมูลนั้น คุณสามารถรวบรวมข้อมูลในระดับวันเพื่อให้การรายงานมีประสิทธิภาพมากขึ้น
4. มุมมองแทนตาราง คนอื่นพูดว่า “ดังนั้น แทนที่จะมีฐานข้อมูล 'ปัจจุบัน' และฐานข้อมูล 'เชิงประวัติศาสตร์' คุณควรมีฐานข้อมูลเพียงฐานข้อมูลเดียว และตารางทั้งหมดในนั้นควรขึ้นต้นด้วย 'historical' จากนั้น คุณควรสร้างชุดมุมมอง หนึ่งชุดสำหรับแต่ละตารางที่คุณต้องการให้เห็นว่าเป็น 'ปัจจุบัน' และให้แต่ละมุมมองกรองแถวประวัติศาสตร์ที่คุณไม่ต้องการดูออก และให้เฉพาะรายการปัจจุบันผ่านเข้าไป”
   https://softwareengineering.stackexchange.com/questions/276395/two-database-architecture-operational-and-historical/276419#276419

สรุป

สิ่งสำคัญที่สุดคือด้วยข้อมูลที่ให้ไว้ที่นี่ คุณควรเตรียมพร้อมที่จะสนทนาอย่างมีประสิทธิผลกับ DBA ของคุณ โอกาสดีที่เธอเคยแก้ปัญหาที่คล้ายกันมาก่อน

การเปลี่ยนแปลงที่เสนอในสถาปัตยกรรมฐานข้อมูล Cognos Audit จะปรับปรุงประสิทธิภาพทั้งในการรายงานโดยตรงและแอปพลิเคชันบุคคลที่สามซึ่งต้องพึ่งพามัน เช่น Motio's ReportCard และสินค้าคงคลัง

อย่างไรก็ตาม หากคุณได้พูดคุยกับ DBA ของคุณ เราก็ยินดีรับฟัง นอกจากนี้เรายังยินดีรับฟังหากคุณได้แก้ไขปัญหาของฐานข้อมูลการตรวจสอบที่มีประสิทธิภาพต่ำ และวิธีที่คุณดำเนินการดังกล่าว