בלוג ביקורת קוגנוס - טיפים וטריקים לסביבות גדולות וגבוהות

בלוג של ג'ון בויר ומייק נוריס.

מבוא

חשוב שתהליך הביקורת של Cognos יפעל כדי לדעת ולהבין כיצד Cognos משמש את קהילת המשתמשים שלך ולעזור לענות על שאלות כמו:

• • מי משתמש במערכת?
  • אילו דוחות הם מריצים?
  • מהם זמני הפעלת הדוח?
  • בעזרת כלים אחרים, כמו MotioCI, איזה תוכן אינו בשימוש?

בהתחשב עד כמה קריטי לשמור על סביבות בריאות של Cognos Analytics, מעט באופן מפתיע נכתב על מאגר הביקורת שלו מעבר לתיעוד המוצר הסטנדרטי. אולי זה מובן מאליו, אבל ארגונים שמשתמשים בו יודעים שעם הזמן השאילתות בטבלאות מסדי הביקורת יתחילו להאט - במיוחד אם לארגון שלך יש הרבה משתמשים שמריצים הרבה דוחות ויש לו הרבה היסטוריה. יתרה מכך, רישום פעילות הביקורת עצמו עשוי להתעכב מכיוון שהוא עומד בתור כאשר לא ניתן להוסיף אותו למסד הנתונים במהירות מספקת, למשל. אז אתה מתחיל לחשוב על ביצועי מסד הנתונים כפי שהיית עושה עם כל מסד נתונים תפעולי שיש לו דרישות דיווח.

שולחנות גדולים בדרך כלל מביאים לביצוע שאילתות איטיות. ככל שהטבלה גדולה יותר, כך לוקח יותר זמן להכניס ולשאול. זכור כי טבלאות אלה ומאגר הביקורת הם בעצם מסד נתונים תפעולי; הכתיבה מתרחשת לעתים קרובות ועובדת נגדנו מכיוון שאיננו יכולים למקד אותן לפעולות קריאה בלבד כפי שהיית עושה עם מאגר נתונים.

בדומה לחנות התוכן, בריאות הסביבה של קוגנוס חייבת להתחשב גם בתקינות מסד הנתונים של הביקורת. צמיחה בלתי מוגבלת של מסד הנתונים של הביקורת עלולה להפוך לבעיה לאורך זמן ואף עלולה בסופו של דבר להשפיע על הביצועים הכוללים של סביבת קוגנוס. בארגונים רבים עם תקנות חיצוניות הדוחים אותם, חוסר רישום ביקורת מלא יכול להוביל אותם למצב של אי ציות עם השלכות כבדות. אז איך נתמודד עם הצורך לשמור כל כך הרבה נתונים לצורכי ביקורת היסטוריים - במקרים מסוימים עד 10 שנים - ובכל זאת לקבל את הדיווח הדרוש לנו כדי לשמור על הסביבה ולשמור על המשתמשים מרוצים מהביצועים?

האתגר

• • צמיחה בלתי מוגבלת של מסד הביקורת משפיעה לרעה על בריאות סביבת קוגנוס
  • הדיווח ממאגר הביקורת הפך לאיטי או בלתי שמיש
  • קוגנוס חווה עיכובים ברישומים שנכתבים למאגר הביקורת
  • מסד הנתונים של הביקורת אוזל

כל זה אומר שלא רק הדוחות המסתמכים על מסד הביקורת סובלים, אלא לעתים קרובות המערכת כולה. אם מסד הנתונים של הביקורת נמצא באותו שרת של חנות התוכן של קוגנוס, הביצועים של כל הדברים שקוגנוס יושפעו בסביבה זו.

ההתקנה

אנחנו מניחים:

1. 1. Cognos Analytics מותקן ופועל
   2. Cognos מוגדר להיכנס למאגר ביקורת
   1. • החזק מסד נתונים לביקורת
      • הגדר רמות רישום ביקורת מתאימות בניהול קוגנוס
      • הרשומה נכתבת למאגר הנתונים על ידי קוגנוס
   3. מאגר הביקורת נמצא בשימוש יותר משנה
   4. הסביבה פעילה מאוד עם משתמשים והוצאות להורג
   5. חבילת הביקורת משמשת להצגת נתוני שימוש בקוגנוס
   6. אנו מחפשים לשפר את ביצועי הדיווח של מסד הביקורת
   7. לא תמיד להתחיל מחדש או למחוק רשומות ישנות

אם עדיין לא התקנת והגדיר את Cognos Audit, Lodestar Solutions, א Motio שותף, יש מצוין פוסט על הפעלת ביקורת ב- Cognos BI /CA.

הפתרון

ישנם כמה פתרונות אפשריים המציגים את עצמם במהירות:

1. 1. הפחת את נפח הנתונים על ידי:
   1. • העברת חלק מהנתונים הישנים יותר למסד נתונים אחר
      • העברת חלק מהנתונים הישנים יותר לטבלה אחרת באותו מסד נתונים
   2. פשוט מחק או קשתhive חלק מהנתונים ואל תדאג לגבי זה
   3. תחייה עם זה. לבעוט את הפחית למטה road ולדחוף את מנהל מסד הנתונים לביצועים
      שיפורים תוך אזיקתם על ידי אי מתן שינויים בסכימה או
      אינדקסים

לא נעסוק באפשרות 3. אפשרות 2, מחיקת הנתונים, אינה אופציה טובה והייתי ממליץ לשמור על שווי של לפחות 18 חודשים לכל הפחות. אבל, אם אתה כל כך נוטה, IBM מספקת כלי שירות, AuditDBCcleanup (Cognos BI) או א תסריט (Cognos Analytics) שיעשה בדיוק את זה. כלי השירות של Cognos BI מוחק רשומות המבוססות על חותמת זמן בעוד שהתסריטים של Cognos Analytics פשוט מוחקים את האינדקסים והטבלאות.

ההמלצות שהצענו ללקוחות בעבר בנושא היו להפריד לשני מאגרי מידע:

1. 1. ביקורת - Live: מכיל את הנתונים השווים ביותר בשבוע האחרון
   2. ביקורת - היסטורית: מכילה נתונים היסטוריים (עד N שנים)

בקיצור, התהליך פועל מדי שבוע כדי להעביר את הרשומות האחרונות מ- Audit Live ל- Audit Historical. Audit Live מתחיל מחדש כפלט ריק לאחר תהליך זה.

1. 1. ה- Live DB מהיר ומהודק, ומאפשר לתוספות לקרות מהר ככל האפשר
   2. שאילתות הביקורת מופנות אך ורק ל- DB ההיסטורי

שימוש בגישה זו, אין כל "חיבור יחד" של הנתונים החיים והנתונים ההיסטוריים. אני טוען שכנראה אתה רוצה להמשיך כך.

ב- Cognos Administration, תוכל להוסיף שני חיבורים שונים למקור נתוני הביקורת. כאשר משתמש מפעיל דוח נגד חבילת הביקורת, הוא מתבקש לאיזה חיבור הוא רוצה להשתמש:

במקרה שאתה רוצה להסתכל על נתוני ביקורת חיים ולא על נתוני ביקורת היסטוריים, אתה פשוט בוחר בחיבור "ביקורת - חי" כאשר תתבקש (צריך להיות היוצא מן הכלל, לא הנורמה.)

אם אתה באמת רוצה גם להציג תצוגה מאוחדת של Live ו- Historical הן תוכל לעשות זאת, אך זה ישפיע על הביצועים.

לדוגמה, תוכל ליצור מסד נתונים שלישי בשם "ביקורת - תצוגה מאוחדת" ולאחר מכן, עבור כל טבלה בסכימת הביקורת: צור תצוגה בעלת שם זהה המהווה איחוד SQL בין הטבלה ב- DB החי לבין הטבלה ב- DB היסטורי. באופן דומה, ניתן להשיג זאת גם במודל Framework Manager, אך שוב, ביצועים יהוו שיקול מרכזי.

חלק מהלקוחות שלנו יצרו תצוגה מאוחדת. לדעתנו, סביר להניח כי מדובר בהגזמה יתרה. הביצועים תמיד יהיו גרועים יותר בתצוגה מאוחדת זו ולא נתקלנו במקרי שימוש רבים המשתמשים במערכות הנתונים החיות וגם בהיסטוריה. Live בשימוש לפתרון בעיות וההיסטוריה לדיווח מגמות.

נכון ל- Cognos Analytics 11.1.7, מסד הנתונים של הביקורת צמח ל -21 טבלאות. תוכל למצוא מידע נוסף במקומות אחרים במאגר הביקורת, בדוחות דוגמת ביקורת ובמודל מנהל המסגרת. רמת ברירת המחדל של רישום היא מינימלית, אך ייתכן שתרצה להשתמש ברמה הבאה, בסיסית, כדי ללכוד בקשות שימוש, ניהול חשבון משתמש ושימוש בזמן ריצה. אחת הדרכים שבהן תוכל לשמור על ביצועי המערכת היא על ידי שמירה על רמת הרישום לרמה הנמוכה ביותר הנדרשת. ברור שככל שהשרת מבצע יותר רישום, כך ניתן להשפיע על ביצועי השרת הכוללים יותר.

טבלאות המפתח שרוב המנהלים יתעניינו בהן הן 6 הטבלאות הרשומות את פעילות המשתמשים ופעילות הדיווח במערכת.

• COGIPF_USERLOGON: מאחסן פרטי כניסה למשתמש (כולל התנתקות)
• COGIPF_RUNREPORT: מאחסן מידע על הוצאות להורג בדוח
• COGIPF_VIEWREPORT: מאחסן מידע על בקשות לתצוגת דוחות
• COGIPF_EDITQUERY: מאחסן מידע על ריצות שאילתה
• COGIPF_RUNJOB: מאחסן מידע על בקשות לעבודה
• COGIPF_ACTION: מתעד פעולות משתמש בקוגנוס (טבלה זו עשויה לצמוח הרבה יותר מהר מהאחרות)

התצורה מחוץ לקופסה נראית כך:

תצורה מומלצת:

מסד הנתונים לביקורת Cognos - Live מכיל נתוני ביקורת של שבוע אחד. נתונים מעל גיל שבוע מועברים למאגר הביקורת של קוגנוס - היסטורי.

השורה ממאגר הביקורת של קוגנוס - Live ל- Cognos Audit Database - ההיסטורית בתרשים אחראית על:

• העתקת נתונים מהביקורת החיה לביקורת היסטורית
• הסר את כל השורות בביקורת חיה הישנות משבוע אחד
• הסר את כל השורות בביקורת היסטורית שהן מבוגרות מ- x שנים
• הסר את כל השורות ב- COGIPF_ACTION שהן מעל גיל 6 חודשים

אינדקסים

לסוגי מסדי נתונים שונים יש סוגי אינדקס שונים. אינדקס מסד נתונים הוא מבנה נתונים, המשויך לטבלה (או תצוגה), המשמש לשיפור זמן ביצוע השאילתות בעת אחזור הנתונים מאותה טבלה (או תצוגה). עבודה עם DBA שלך כדי ליצור את האסטרטגיה האופטימלית. הם ירצו לדעת את התשובות לשאלות כמו אלה כדי לקבל את ההחלטות הטובות ביותר לגבי עמודות לאינדקס. ברור שמנהל מסד הנתונים יכול היה לברר את התשובות לחלק או כל השאלות הללו ללא עזרתך, אך יידרש קצת מחקר וקצת זמן:

• כמה רשומות יש לטבלאות ובאיזה גודל אתה מצפה שהן יגדלו? (אינדקס טבלה לא יהיה שימושי אלא אם יש בטבלה מספר רב של רשומות).
• האם אתה יודע אילו עמודות ייחודיות? האם הם מאפשרים ערכי NULL? באילו עמודות יש סוג נתונים של מספר שלם או שלם גדול? (העמודות עם סוגי הנתונים המספריים ושהן ייחודיות ולא NULL הן מועמדות חזקות להשתתף במפתח האינדקס.)
• היכן בעיות הביצועים העיקריות שלך כיום? האם הם באחזור הנתונים? האם יש שאילתות או דוחות ספציפיים שהם יותר בעיה? (זה עשוי להוביל את מנהל מסד הנתונים לכמה עמודות ספציפיות שניתן לייעל אותן.)
• אילו שדות משמשים לחיבור טבלאות לדיווח?
• אילו שדות משמשים לסינון, מיון, קיבוץ וצבירה?

באופן לא מפתיע, אלו אותן שאלות שצריך לענות עליהן לשיפור הביצועים של טבלאות מסדי נתונים.

תמיכת 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. בדוק דגם FM. זכור כי מודל Framework Manager ש- IBM מספקת מעוצב על טבלאות ושדות ברירת המחדל. כל שינוי שאתה מבצע בטבלאות הדיווח יצטרך לבוא לידי ביטוי במודל. הקלות או המורכבות של שינויים אלה - או היכולת הארגונית שלך לבצע שינויים אלה - עשויים להשפיע על הפתרון שתבחר.
2. שדות נוספים. אם אתה מתכוון לעשות זאת, זה הזמן להוסיף שדות נוספים לנתוני הקשר או הפניה לשיפור דיווח הביקורת.
3. טבלאות סיכום. במקום להעתיק את הנתונים לטבלה ההיסטורית שלך, דחוס אותם. תוכל לצבור את הנתונים לרמת היום כדי להפוך אותם ליעילים יותר לדיווח.
4. צפיות במקום טבלאות. אחרים אומרים, "אם כן, במקום שיהיה לך מסד נתונים 'עדכני' ומסד נתונים 'היסטורי', יהיה עליך רק מסד נתונים אחד, וכל הטבלאות בו צריכות להיות מוקדמות ב'היסטורי '. לאחר מכן, עליך ליצור קבוצת תצוגות, אחת לכל טבלה שברצונך לראות כ'נוכחית ', ולגרום לכל תצוגה לסנן את השורות ההיסטוריות שאינך רוצה לראות ולתת רק לשוטפות לעבור. "
   https://softwareengineering.stackexchange.com/questions/276395/two-database-architecture-operational-and-historical/276419#276419

סיכום

השורה התחתונה היא שעם המידע המוצג כאן אתה צריך להיות מוכן היטב לנהל שיחה פורייה עם ה- DBA שלך. רוב הסיכויים שהיא פתרה בעיות דומות בעבר.

השינויים המוצעים בארכיטקטורת מסד הנתונים של Cognos Audit ישפרו את הביצועים הן בדיווח ישיר והן ביישומי צד שלישי המסתמכים עליו, כמו Motio"S ReportCard ומלאי.

אגב, אם הייתה לך שיחה כזו עם ה- DBA שלך, נשמח לשמוע על כך. נשמח לשמוע אם פתרת את הבעיה של מסד ביקורת בעל ביצועים גרועים וכיצד עשית זאת.