על גבולות ותחומי אחריות, או, מעבר להרי ה database tuning - ilDBA Portal

על גבולות ותחומי אחריות, או, מעבר להרי ה database tuning

27/11/2011 | פורסם על ידי

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

השאילתה "בסה"כ" ביצעה select count(*) על טבלה מפלצתית של כ-150 מיליון רשומות, עם join על טבלה קטנה יותר (כ-5 מיליון רשומות), וכללה מספר תנאים לא מפלטרים במיוחד שהופיעו ב-where clause שלה.

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

מה שגיליתי לאחר בירור ובחינה של הקוד, השאיר אותי פעורת פה, ולא מסיבות טובות.
בגדול, קוד ה-java ביצע את הדבר הבא (פסאודו):

1.  select count(*) from T1, T2 where ...

השליפה הנ"ל מחזירה, לאחר שעתיים של ריצה, איזהו מספר. נקרא לו X.

2.       X/100

כעת האפליקציה מחלקת את X ב-100, בשביל לקבל את מספר הפעמים לביצוע לולאה פנימית.

3.      for 1 in 1.. X/100 {
           select ... from T1,T2 where ... and rownum =< 100
           אלו נתונים שחוזרים לעיבוד. כל פעם חוזרות עד 100 רשומות.
        }

מהתבוננות בקוד מתגלים שני דברים עגומים:

א.        השאילתה החיצונית של ה-count (שלב 1) מיותרת! מיותרת לחלוטין מבחינת לוגית ומייצרת עומס משאבים מטורף על המכונה.

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

כל מה שהאפליקציה צריכה לעשות זה להסיר את שאילתה ה-count מהקוד, ולהריץ את השאילתה הפנימית בלולאה עד לקבלת no_data_found. זה יראה לוגית כך:

cont_processing = 1
while ( cont_processing ) {
select ... from T1,T2 where ... and rownum =< 100 ; -- just the inner loop
if no_data_found then cont_processing =0
}

יש שישאלו מה בין טיוב קוד java  ל-DBA. הרי אין זה sql tuning, ולכן, האם זו אחריות ה  DBA להתערב ולשפר את קוד ההאפליקציה?

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

כאשר מרחב הבעיה מוגבל רק ל-database, מרחב אפשרויות הפיתרון ישאר כבול רק לשם, וחבל.

לכן DBA-ים ואנשי האפליקציה צריכים לעבוד ביחד, בשיתוף פעולה מלא, שכן הקוד שנכתב על ידי האפליקציה הוא זה שבסוף מורץ ב-database שעליו אחראי ה-DBA.
המלצתי לכם היא להתוודע כמה שיותר לאנשי האפליקציה ולקוד הכתוב, לשוחח זה עם זה, להכיר את המקור ל-SQL שמורצים ב-database שלכם (בטח ובטח לכבדים מביניהם), ות
מיד לזכור שידע הוא כוח, וכל ידע נוסף פותח אפשרויות פתרון נרחבות יותר.

בהצלחה,

נתראה ברשומה הבאה !

מרב קדם,

Oracle Performance Tuning & DBA Consulting
meravkedem.blogspot.com
www.dboptimize.co.il
merav@dboptimize.co.il

The following two tabs change content below.

4 תגובות ל- “על גבולות ותחומי אחריות, או, מעבר להרי ה database tuning”

commenter

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

מרב קדם | 30/11/2011 בשעה 09:59
commenter

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

גיא כהן | 01/12/2011 בשעה 01:44
commenter

היי מרב
אני לא בא לשלול או להצדיק אלא לשפוך "אור" על מה שנעשה כאן.
(אני מהצד של המתכנתים …)
נשאלת השאלה האם נדרש להציג מד התקדמות (progress bar)
כי אז באמת צריך לדעת כמה מקסימום יש לנו מראש ואז לעשות לולאה.

מרב קדם | 01/12/2011 בשעה 11:18
commenter

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

השאר תגובה:

שם (חובה):
אימייל (לא יפורסם) (חובה):
תגובה (חובה):

*



מאמרים קשורים

איך לבצע Sizing DB ב-Datacenter בארגונך בקלות (חלק א')

כחלק מהטמעות מוצרי IT תשתיתיים (כגון FWDB, מוצרי גיבוי, חוות Storage, מוצרי שו"ב ועוד…) בארגוני, אנו נדרשים המון פעמים לענות על שאלות לספקים כגון : מה גודל הכולל של ה –  Datacenter  ? מה חלוקת גודל ה [...]
מבוא

מבוא לבעיות ביצועים באורקל

The following two tabs change content below.BioLatest Posts עודד רז עודד רז, מנכ"ל חברת בריליקס ומייסד אתר זה. עודד הוא Oracle ACE Director ואחד מה-DBA-ים הבכירים ביותר בישראל, עם מעל 15 שנות ניסיון כ-DBA תשתיתי ואפליקטיבי. לעודד [...]

ה-SQL Performance Analyzer ב-Real Application Testing

בפוסט הקודם הזכרתי בקצרה את ה-SQL Performance Analyzer, בפוסט הזה אני אציג את ה-SPA, יתרונות וחסרונות של המוצר ואיך כדאי להשתמש [...]

מבוא ל- Real Application Testing

הפעם רציתי לסקור feature שלם שנקרא RAT (או בשמו המלא Real Application Testing). ה- feature הזה הוא database option של Oracle Enterprise Edition והוא לא חדש בכלל. הוא הוצג ב- 11gR1 וגם נמצא בשימוש לא מועט בעולם. משום מה, אצלנו בארץ לא יוצא [...]
Copyright 2019 ilDBA Portal. Brought to you by Brillix - Israel Leading DBA company. Sponsored by: DBSnaps - Database Video Tutorialss
Website Security Test
%d בלוגרים אהבו את זה: