שימוש ב-Append ו-redo logs

הייתי היום בכנס ilOUG שיוחד לנושאי Data Warehouse ומכוון שהנושא קרוב לליבי (עדיין, כמעט שלוש וחצי שנים ב-DWH של פרטנר) הלכתי לשמוע מה יש בנושא ונהנתי מאוד.

במהלך ההרצאה האחרונה הסבירו החבר'ה מאורקל על שיטות טעינה למחסני נתונים. במהלך ההרצאה התפתחה שיחה קצרה ביני ובין עמיאל דיוויס בנושא מתי יש להינט Append משמעות והאם זה עוזר רק בסביבה של Archive log mode או לא. הוא הפנה אותי לבלוג שלו אז אני מפרגן ולהלן לינק למה שהוא כתב בנושא כבר לפני שנתיים. אם הגעתם עד כאן ולא הבנתם כלום, אולי הגיע הזמן להסביר קצת במה מדובר.
המשך קריאה…

על מעבדים: socket-ים, core-ים ו-thread-ים

אופיר מנור מאורקל כתב פוסט יפה ומעניין בבלוג המומחים של אורקל על מעבדים וההבדלים בין sockets (מעבדים פיזים), cores (ליבות בתוך מעבד פיזי) ו-threads (מספר תהליכים שיכולים לרוץ בו זמנית בכל ליבה). מבחינתי זו הזדמנות טובה לרכז כמה פקודות שימושיות בנושא.

אני אשמח לקבל תיקונים הערות ותוספות בנושא.

בשליפה מ-Oracle:

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

המשך קריאה…

ביצועים גרועים באיסוף סטטיסטיקות על פרטישנים

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

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

הפוסט השני שעסק פחות או יותר באותו עניין אך בגרסה אחרת היה בבלוג של Martin Widlake. במקרה הזה הוא מתאר מצב שאיסוף הסטטיסטיקות על הפרטישנים בטבלה היה איטי מכוון שלא היו סטטיסטיקות על אינדקס גלובלי שהוגדר על הטבלה. במקרה הזה הפתרון שלו היה איסוף סטטיסטיקות מינימליות (0.01%) על האינדקס ואז האיסוף השתחרר.

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

סטטיסטיקות למחסני נתונים

מתוך iSeminar בנוגע ל-best practices של סטטיסטיקות למחסני נתונים:

בטבלאות בעלות Partition ישנם שלושה סוגים של סטטיסטיקות שניתן לאסוף על הטבלה:

  1. סטטיסטיקות גלובליות (Global/table statistics).
  2. סטטיסטקות ברמת פרטישן (Partition statistics).
  3. סטטיסטיקות ברמת סאב-פרטישן (Sub-partition statistics).

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

רשימת ה-session-ים שה-QC הוא ב-INACTIVE אבל יש לו ילדים שעדיין תופסים Parallel

תופעה מעניינת עם כלים שמחזירים row set בגודל מסויים ושמאפשרים לעשות fetching היא שאם השליפה המקורית הייתה מקבילית (parallel) הכלים נוטים שלא לשחרר את הפרוססים שהם השתמשו בהם בשביל השליפה ולתפוס אותם כל עוד לא נעשתה שליפה אחרת באותו חלון.

אז מה בעצם הבעיה? הבעיה היא שכאשר יש load גבוה על המערכת ויש צורך ב-Parallel servers, התוכנות האלה מחזיקות את המשאבים ושליפות אחרות מקבלות downgrade.

שני כלים שעושים את זה הם TOAD ו-PL/SQL Developer וניתן להשתמש בשליפה הבאה כדי לאתר מי הם הסשנים שנראים Inactive אבל בפועל הם תופסים משאבים (השליפה הזו נעטפה על ידי סקריפט CSH שגם מעיף את המשתמשים האלה כאשר הם מחזיקים את המשאבים יותר מדי זמן):

with curr_sessions as (
SELECT ROUND(BITAND(s.ownerid, 65535)) parent_session_sid,
       s.sid,
       s.status,
       s.sql_id,
       UPPER(s.program) program
  FROM v$session s, v$process p
 WHERE ((s.username IS NOT NULL) AND (NVL(s.osuser, 'x') <> 'SYSTEM') AND (s.TYPE <> 'BACKGROUND'))
   AND (p.addr(+) = s.paddr))
select distinct a.sid parent, b.sid child, a.status status_p, b.status status_c, a.program, a.sql_id
  from curr_sessions a
  join curr_sessions b on a.sid = b.parent_Session_sid
                      and a.status = 'INACTIVE'
                      and a.program in ('TOAD.EXE')
order by 1

שליפות שעושות Downgrade

לפעמים יש צורך למצוא מהן השליפות שעשו downgrade במערכת ולא קיבלו מספיק parallel processes. צריך להבחין בין שני מקרים: מקרה שהשליפות קיבלו חלק מהמשאבים ומקרה שבהם הן לא קיבלו בכלל משאבים ועכשיו הן עובדות ב-serial.

כדי למצוא מהן השליפות שקיבלו downgrade (אבל עדיין עובדות ב-Parallel) ניתן להשתמש בשליפה הבאה. השליפה מחזירה רק את ה-PX coordinator (כלומר ה-SID של ההורה) ולא את כל הפרוססים עצמם:

SELECT a.sid parent_sid,
       a.logon_time,
       a.program,
       a.osuser,
       a.username,
       a.sql_id,
       ps.req_degree,
       ps.got_degree
  FROM (SELECT s.sid,
               s.osuser,
               s.USERNAME,
               s.status,
               s.sql_id,
               s.logon_time,
               s.last_call_et,
               UPPER(s.program) program
          FROM v$session s
         WHERE ((s.username IS NOT NULL) AND (NVL(s.osuser, 'x') <> 'SYSTEM') AND
               (s.TYPE <> 'BACKGROUND'))) a
  JOIN (SELECT DISTINCT qcsid,
                        CASE
                            WHEN req_degree > degree THEN
                             1
                            ELSE
                             0
                        END is_downgrade,
                        MAX(req_degree) req_degree,
                        MAX(degree) got_degree
          FROM v$px_session
         GROUP BY qcsid,
                  CASE
                      WHEN req_degree > degree THEN
                       1
                      ELSE
                       0
                  END) ps ON a.sid = ps.qcsid
 WHERE ps.is_downgrade = 1

כדי לאתר את השליפות שלא קיבלו פרוססים בכלל (ובעצם עשו downgrade to serial) ניתן להשתמש בשליפה הבאה:

SELECT sess.sid parent_sid,
		 logon_time,
		 sess.program,
		 sess.osuser,
		 sess.username,
		 sql_id,
		 TRUNC (last_call_et / 60) dur_minutes
  FROM v$sesstat sesstat, v$sysstat sysstat, v$session sess
 WHERE	  sesstat.statistic# = sysstat.statistic#
		 AND sesstat.sid = sess.sid
		 AND name = 'Parallel operations downgraded to serial'
		 AND sesstat.VALUE > 0
		 AND sess.status = 'ACTIVE'