רשמים מעבודה עם ה- Auditor

בזמן האחרון הזדמן לי לבצע מספר פרויקטים עם רכיב ה- Auditor והנה כמה מסקנות  :

1. הביצועים בעת הרצת דוחות על בסיס הנתונים של ה- Auditor עשויים להיות מחרידים ואף לייצר Deadlock בעת גישה לטבלאות שעסוקות בלקבל נתונים מה- Repository,ההמלצה שלי היא כמו בכל בסיס נתונים תפעולי ועל זה יושב ה- Auditor בסופו של דבר לייצר Data Mart קטן שיעביר את טבלאות ה- Auditor לסביבה יומית ולשם מומלץ

לטעון את טבלאות ה- View לטבלאות רגילות,לאנדקס ולפרטש את טבלאות ה- AUDIT_EVENT וה- AUDIT_DETAIL כדי לקבל ביצועים טובים , הנתונים הרי לא חייבים להיות Online.

2. מלבד סט הדוחות הבסיסי שה- Auditor מספק ניתן ליצור דוחות מעניינים כמו:

איזה משתמש לא פעיל מעל X זמן,איזה דוחות לא הורצו מעל –X זמן,כמה דוחות כפולים יש ב- Repository,איזה תקלות מכאניות (גישה ל-DB,הרשאה לא מתאימה,Login שגוי) נגרמות למשתמשים,מתי פעם אחרונה נכנס כל משתמש למערכת,מה אחוז השימוש במערכת.

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

4. נתון מעניין שגיליתי:ניתן לאתר דוחות כבדים למערכת שבד"כ מעידים גם על בנייה לא נכונה.

המשוואה אומרת שבערך 100MG =  חמש מליון רשומות,דוחות מעין אלו הם דוחות מהגיהינום שמעידים על צבירה אדירה של נתונים ושימוש לא נכון במחולל הדוחות,דוח "דוחות כבדים" סייע לי לאתר כמה "פושעי דוחות" שלא בנו דוחות כיאות והתייחסו למערכת ככלי לצבירת נתונים למקרה שיום הדין יגיע,הכי חשוב שה-DB יהיה אצלם....

מיותר לציין אך מצאתי דוחות ששוקלים מעל 700MG....את החשבון תעשו לבד...
מעבר לכך אם נתווכח האם הדוח אכן צריך להגיע למימדים אלו (המשתמש רוצה "להקפיא" את דוח הכנסות 2008)
ניקוי/איפוס הדוחות הנ"ל תיטיב עם ה- Repository מאחר והיא תצמצם את גודלו ואת העובדה שבעת שמושכים דוח גדול כזה נוצר כאמור עומס על המערכת.

5. נתון מעניין נוסף שמצאתי היה האפשרות לקבל חיווי על ה-SQL של הדוח מה שטורם רבות כמובן לניטור הדוח,הבעיה הגדולה שמצאתי בנתון זה שרק דוחות שבוצע להם Edit  ,ה-SQL שלהם מתועד.
ניתן בהחלט להשתמש בכלי אוטומטי או לכתוב סקריפט שיפתח את הדוחות וישלים את המשימה
אבל זה עשוי להיות מורכב ולא יציב (פתיחה של אלפי דוחות שחלקם כבדים,על חלקם יש הרשאות,Table Mapping ועוד)
ופה כבר עשוי להיכנס עוד כלי למשימה ה-MDM : Meta Data Manager שיכול להציג גם את ה-SQL של כל דוח לפי עולם.

6. אם הדוחות אמורים לשמש את התמיכה כדאי ליצור טבלת משתמשים משודרגת שתכיל מידע כמו שם המשתמש,טלפון,מייל ושם חטיבה/מחלקה ולטעון אותה לסכימת ה- Auditor.

7. מינוס נוסף הוא שתאריך הראשי המתעד הוא AUDIT_EVENT.Start_Timestamp והוא קיים ברמת שעה ודקה,אם יש לכם Prompts עם תאריכים (בלי LOV כמובן!) המשתמשים יצטרכו להכניס תאריך בפורמט של שעה ודקה – מומלץ לבצע Trunc על התאריך או להשתמש בשדה ה. Audit_Event.Start_date

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

9.אם אתם מעוניינים לתחקר את כל הדוחות,לצפות ב-SQL שלהם ולראות דוחות שגדולים מ-X מגה תצטרכו לייצר Aliases או לשטח את טבלת ה-Audit_Detail מאחר והיא מחזיקה את הערכים הנ"ל באותה עמודה בטבלה.

10.מומלץ לטעון את ה-LOV של שדות ה-DETAIL_TYPE.Detail_Type_Description
וה-DETAIL_TYPE.Detail_Type_Description לטבלאות Dummy שטוחות ואז לבצע Nested LOV בינהם כך שתוכלו לבחור בסוג פעולה Universe Name ותחתיו לבחור את שם העולם הספציפי.