ה-SQL Performance Analyzer ב-Real Application Testing - ilDBA Portal

ה-SQL Performance Analyzer ב-Real Application Testing

18/12/2014 | פורסם על ידי

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

הייתי רוצה לספר לכם קצת על מה שהיה בסדנה וקצת על היכולות של RAT (מעבר להקדמה שפרסמתי במאמר הקודם)

בפוסט הקודם הצגתי בקצרה את ה- SPA וה- DB Replay, עכשיו אני רוצה להרחיב על כל אחד וגם להציג חלקים נוספים של המוצר: SPA Quick Check ו- DB Replay concurrent. בפוסט הזה אני רוצה להתחיל ב- SPA.

SQL Performance Analyzer (SPA)

אז כמו שהזכרתי בפוסט הקודם, ה- SPA הוא מעין unit testing לשאילתות. המטרה שלו היא לענות על השאלה "איך שינוי שאני מתכנן ישפיע על השאילתות שלי במערכת?"

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

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

אילו שינויים יכולים להיות רלוונטיים? הרבה שינויים, כמו:

  • שדרוגים והתקנת patch
  • עדכון optimizer statistics
  • שינויי סכמה (הוספת או מחיקת אינדקס, עמודות וכו')
  • שינויי פרמטרים
  • שימוש ביכולות tuning של אורקל, למשל הוספה של SQL Profile
  • שינויים ברמת מערכת הפעלה או חומרה

איך התהליך עובד?

כמו שהסברתי, הרעיון הוא לבחור סט של שאילתות ולהריץ אותן אחת אחת. כדי לעשות את זה בפועל, זה התהליך שנשתמש בו:

1.      יצירת STS

STS או SQL Tuning Set, הוא אובייקט המכיל:

  • פעולות SQL (שאילתות, פעולות DML וכו'), כולל הטקסט המלא של הפעולות.
  • פרטים על ה- session כגון סכמה, מודול ו- action.
  • ערכים של bind variables.
  • מידע על הריצה – זמן ריצה, זמן CPU, buffer gets, I/O, רשומות, כמות ריצות וכו'.
  • Execution plan וסטטיסטיקות רלוונטיות.

כדי להריץ SPA צריך ליצר STS שמכיל את כל השאילתות שאנחנו רוצים לבדוק. אפשר ליצור STS כזה בכמה דרכים:

  • מתוך ה- AWR אפשר ליצור STS שמכיל את השאילתות הכבדות ביותר. שימו לב שבצורה הזאת אנחנו כנראה נפספס SQL-ים במערכת מצד אחד, מצד שני, ה- SQL-ים הכבדים והחשובים יהיו שם.
  • מהזיכרון – בצורה זו אנחנו מפעילים דגימה כל כמה זמן (ברירת המחדל היא 5 דקות) כדי לקחת את כל ה- SQL-ים שנמצאים בזיכרון לתוך ה- STS. דרך זו מומלצת ויעילה במיוחד, הסיכוי לתפוס את כל ה- SQL-ים או כמעט את כולם הוא גבוה והעומס שנוצר מהתהליך הוא יחסית נמוך (1%-2%).
  • מתוך SQL trace – יש אפשרות ליצור STS מ- SQL-ים שנמצאים בקבצי SQL trace. היתרון פה הוא שאפשר לקחת SQL-ים מסביבות Standard Edition וסביבות של 9i ומטה ששם אין STS. החיסרון הוא כמובן העומס שהתהליך מייצר (יכול להגיע ל- 30%) והמקום שהקבצים תופסים.

דבר חשוב נוסף הוא תהליכים מיוחדים, כאלה שרצים בלילה, סוף שבוע, סוף חודש וכו'. אנחנו לא רוצים להפעיל תהליך שרץ כל 5 דקות למשך חודש שלם כדי לתפוס הכל. מה שכן אפשר לעשות זה ליצור כמה STS-ים שונים. אחד ליום רגיל, אחד ללילה, אחד לסוף שבוע וכו'. בסוף התהליך אפשר לאחד את ה- STS-ים השונים ל- STS אחד גדול ובו להשתמש ב- SPA.

2.      העתקה לסביבת טסט

בסופו של דבר, את ההרצות נעשה על סביבת טסט ולא על ה- production. לכן יש להעביר את ה- STS שייצרנו אל סביבת הטסט.

3.      ריצה ראשונה על סביבת הטסט

הריצה הראשונה של ה- SPA תהיה על סביבת טסט זהה ככל הניתן לסביבת ה- production ותתבצע לפני כל שינוי שאנחנו מתכננים לעשות. הרעיון הוא ליצור baseline שאליו נוכל להשוות את כל הריצות הבאות אחרי שינויים שנעשה.

4.      ביצוע השינוי

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

5.      ריצה נוספת על סביבת הטסט

אחרי השינוי, נריץ שוב את ה- SPA על ה- STS שלנו כדי לבדוק את השינויים בין הריצות לפני ואחרי השינוי.

6.      השוואה

בשלב הזה נשתמש ב- SPA כדי להשוות בין שתי הריצות. הדוח שיוצג לנו מכיל הרבה מידע על ההבדלים בין הריצות, כולל שינויים ברמת ה- SQL הבודד בהיבטים של זמן ריצה, זמן CPU, גישה לדיסק, גישה לזיכרון, מספר רשומות שחזרו ועוד. ירידה בביצועים מוגדרת בהבדל בביצוע באחוזים, יש לנו יכולת לשלוט על האחוז עצמו, כאשר ברירת המחדל היא 1% (כלומר, שאילתה שלקחה 100 שניות, ירידה בביצועים מבחינת ה- SPA תהיה 101 שניות ומעלה, אבל לא 100.5).

7.      איטרציה נוספת

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

מגבלות והערות

  • לצורך SPA אנחנו צריכים סביבת טסט זהה ככל האפשר לסביבת ה- production הן בחומרה והן בגרסאות, מבנה ומידע של ה- database. במידה והחומרה שונה, אפשר עדיין להשוות את ה- SQL-ים לפני ואחרי השינוי, אבל זה לאו דווקא יבטיח שככה הדברים יתנהגו במציאות.
  • אם האפליקציה משתמשת ב- bind variables, ה- SPA בסופו של דבר יריץ רק סט אחד של ערכים ולא את כל הערכים שהיו באמת.
  • פרוצדורות, פונקציות, package-ים וקוד PL/SQL לא רץ כחלק מה- SPA. ה- SPA יריץ את כל ה- SQL-ים שרצו מתוך ה- PL/SQL, אבל לא את ה- PL/SQL עצמו ולא את הקוד שהוא לא SQL סטנדרטי.
  • במידה והאפליקציה משנה פרמטרים בעת ההתחברות, השינויים האלה לא קיימים בסביבת הטסט, ולכן נצטרך לבצע אותם ידנית בסביבת הטסט לפני תחילת התהליך כולו.
  • ה- SPA מדלג על פעולות DML ו- DDL. השאילתות שנובעות מהם מורצות (כלומר אם יש delete from table1 where id=x, מורצת השליפה לפי id=x, אבל לא מבוצע ה- delete בכלל). ישנה אפשרות להשתמש בפרמטר execute_fulldml של ה- SPA שכן מבצע פעולות DML (אבל לא DDL), ובכל מקרה מבצע rollback בסוף התהליך. אין אפשרות לבצע commit כחלק מה- SPA.
  • ה- SPA זמין מגרסת 11. יצירת STS ב- 9i ומטה מבוצעת על ידי SQL trace כפי שכתבתי למעלה. הרצה של SPA ב- Oracle 10 ניתן לבצע על ידי יצירה של סביבת SPA ב- Oracle 11 או 12 והרצת כל התהליכים מרחוק על סביבת ה- 10 (הלוגיקה מתבצעת בגרסת 11 או 12 וה- SQL-ים רצים ב- 10 על ידי remote execution).

SPA Quick Check

יכולת חדשה יחסית ומגניבה ב- RAT היא ה- SPA Quick Check. הרעיון של היכולת הזאת הוא בדיקה של שינוי שאנחנו מתכננים לבצע ב- production. ההבדל המהותי בין ה- SPA הרגיל ל- Quick Check הוא שה- SPA הרגיל מבוצע על סביבת טסט וכולל כל שינוי שאנחנו מתכננים לעשות. ב- Quick Check הבדיקה מתבצעת על ה- production ואנחנו יכולים להשתמש רק לפני שינויים "מקומיים" כמו יצירה של אינדקס, שינוי פרמטר וכו', אבל לא שדרוג או שינוי משמעותי של הסכמה.

השימוש ב- Quick Check נעזר ביכולות קיימות כמו pending statistics, invisible indexes, session parameters וכו'. בעזרת היכולות האלה, אנחנו מבצעים שינוי ב- production האמיתי, כאשר ה- SPA Quick Check מבצע את השינוי מקומית ב- session שלו (למשל מייצר אינדקס כ- invisible כאשר רק ל- session שלו מוגדר להשתמש באינדקס כזה). אז הוא מריץ את ה- STS על הסביבה האמיתית תוך שימוש באינדקס הזה. לאחר השינוי וההרצה אפשר לקבל השוואה כמו ב- SPA רגיל ולאחר מכן לבצע את השינוי באופן גורף למערכת.

צריך להבין שברור שיש השלכות לביצוע תהליך כזה על production. אבל מדובר בשינוי שאנחנו כבר מתכננים לעשות בכל מקרה, ה- SPA Quick Check פשוט מאפשר לנו לעשות אותו בצורה יותר אחראית ובטוחה.

יתרונות

  • מתוכנן ובנוי לרוץ בסביבת production.
  • כל התהליך רץ ב- scope של ה- session כאשר השינויים לא משפיעים על כלל המשתמשים.
  • משווה execution plan ומריץ רק שאילתות שבהן ה- execution plan שונה (כדי להקל על העומס הנוצר).
  • קיימת אפשרות להשוות רק execution plan בלי להריץ שאילתות בכלל.
  • שאילתות שרצות מוגבלות הן מבחינת זמן ריצה והן מבחינת resource manager כדי להשפיע כמה שפחות על ה- production.
  • DML-ים ו- DDL-ים לא רצים.

סיכום

בפוסט הזה סקרתי רק חצי מהמוצר הזה שנקרא RAT. אפשר להבין כמה הכלי הזה חזק ויכול להיות שימושי בכל כך הרבה מקרים.

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

The following two tabs change content below.
ירון אמיצי הוא סמנכ"ל שירותי מומחה בחברת בריליקס ו-DBA בכיר בעל נסיון של למעלה מ- 15 שנים. ללירון תואר Oracle Ace ומתמחה בנושאי ביצועים, תשתיות, פתרונות זמינות גבוהה, גיבויים ושחזורים. ללירון יש גם בלוג עצמאי בכתובת: https://amitzil.wordpress.com

השאר תגובה:

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

*



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

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

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

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

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

מבוא ל- Real Application Testing

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