האם כבר קרה לכם שמדד ה -Page Life Expectancy צנח פלאות והגיע למצב שתוחלת החיים של כל Page היא שוות ערך לתוחלת החיים הממוצעת של אזרח באחת המדינות ביבשת אפריקה?? הפעם לשם שינוי הפעם לא אכתוב על נושא תיאורטי אלא אציג בעיה שנתקלתי בה בזמן עבודתי אצל אחד הלקוחות שלנו הקשורה למדד זה.

שבוע שעבר התקבלה התראה במערכת שמדד בשם Page Life Expectancy צנח אל מתחת ל- 250 שניות בממוצע. הערך התקין של מדד זה לפי המלצות מיקרוסופט הוא כ- 300 שניות.  למי שלא מכיר מדד זה מציין למעשה את הזמן הממוצע שדף (Page) חי ב- Buffer Pool של SQL Server  לפני שהוא נמחק משם. נעצור לרגע ונסביר, פעולות I/O יכולות להיות כבדות, ארוכות זמן וגם לגזול משאבים רבים מהשרת. לכן, SQL Server משתמש ב- Buffer Pool כפתרון המרכזי על מנת להקל על השרת, לצמצם את זמן אחזור המידע והבאתו את הלקוח (בין אם זה משתמש כגון DBA או אפליקציה).ה- Buffer Management מורכב משני מנגנונים מרכזיים: הראשון הוא: Buffer Manager שתפקידו לעדכן בפועל את הדפים (הסבר עוד מעט…). ואילו המנגנון השני הוא ה- Buffer Pool אשר שומר בתוכו דפים בגודל 8 KB, אלו יכולים להיות Data Pages או Index Pages.למעשה ה- Buffer Manager קורא דפים ומכניס אותם אל תוך ה- Buffer Pool ובסיום התהליך הוא גם אחראי על כתיבת השינויים אל הדיסק עצמו. למעשה, דף יישאר בתוך ה- Buffer Pool עד לנקודה בזמן שה- Buffer Manager יצטרך מקום על מנת להעלות דפים אחרים שלא נמצאים בתוך ה- Buffer Pool. כאשר כמובן דף שנקרא וכבר נמצא ב- Buffer Pool ייכתב בחזרה אל הדיסק רק אם הוא עבר שינוי כלשהו. נקודה חשובה נוספת, דף יחיד יכול לעבור מספר שינויים לפני שהוא נכתב לדיסק! לדוגמא: דף מטבלה מסוימת נקרא ונמצא ב- Buffer Pool למשך עשר דקות, כאשר בעשר הדקות הללו הוא עבר חמישה שינויים, ואז לאחר 5 דקות, ה- Buffer Manager נאלץ להוציא אותו מתוך ה- Buffer Pool משום שעליו להכניס דפים חדשים אל ה- Buffer Pool וזאת משום שאין מספיק מקום ב- Buffer Pool להכיל את הדפים שהוא צריך להשתמש בהם.  מה שמוביל לי לנקודה הבאה, איך נוכל לדעת מה גודלו של – Buffer Pool  וע"פ מה הוא נקבע.  כאשר SQL Server עולה, הוא מחשב את גודלו של ה Buffer Pool. כאשר הוא מתבסס על מספר פרמטרים שונים, כמו כמות ה- Physical Memory  על השרת, הגדרת המספר המקסימלי של Server Threads וכו'. על מנת לדעת מה גודלו של ה-Buffer Pool  שלכם, פשוט הריצו את השאילתה הבאה:

SELECT * FROM sys.dm_os_sys_info

כאשר אנו מחפשים את הערכים תחת העמודות:

• bpool_commited – מייצג את הגודל בפועל של ה- Buffer Pool. הערכים בתוך העמודה הם למעשה מספר ה- Pages שקיימים בתוך ה- Buffer Pool.
• bpool_commit_target – מציין את גודל היעד הרצוי של ה- Buffer Pool, (גם כאן המספר מייצג את מספר הדפים). במקרים בהם ה- bpool_commit_target גדול מ- bpool_committed אזי, SQL Server ינסה תמיד להשיג עוד זיכרון ל-bpool_committed, ולהגיע למצב של שיוון ביניהם.

לאחר הסבר זה, אני מקווה שנוכל להבין בצורה טובה יותר, מהי המשמעות המעשית כאשר אנו מקבלים התראה שמדד ה- Page Life Expectancy צונח אל הקרקעית, ומגיע לערך של שניות בודדות. המשמעות המעשית היא, שה- Buffer Manager מעלה אל הזיכרון כמות גדולה מאד של דפים, שכל הנראה אין בכך צורך. וכאשר מדד זה צונח בצורה חדה כל כך ופתאומית, עולה השאלה, מה נשתנה יום מיומיים??? מה קרה היום שלא היה אתמול?? במקרה שלא מקבלים תשובה ברורה ומדויקת, שעשויה לסייע לנו, נאלץ לצלול עמוק אל תוך ה- Buffer Pool  על מנת לראות אילו דפים הוא מחזיק בתוכו, או  בלשון מדויקת יותר,  מאיזו טבלה או אינדקס מגיעים הדפים אל ה- Buffer Pool  והאם הם שייכים אל טבלה מרכזית אחת? או ממספר מצומצם של טבלאות??

לשם כך נעזרתי בשאילתה הבאה שחיבר גיא גלנצר  (לחצו על הקישור להורדה), שאילתה זו מציגה אינפורמציה יעילה מאד לפתרון בעיות אשר קשורות ל- Buffer Pool. בשאילתה למעשה יש חיבור בין כמה DMV's שונים כאשר המרכזי שבהם הוא sys.dm_os_buffer_descriptors, והתוצאה הסופית היא הצגה של שם הסכמה, שם הטבלה, כמה KB מהטבלה נמצאים בתוך ה- Buffer Pool כרגע, מה גודל הטבלה על הדיסק, וכמה אחוזים מן הטבלה נמצאים בתוך ה- Buffer Pool.

לאחר הרצה של השאילתה הזו, הבחנתי ש- 75% מה- Buffer Pool נתפסים ע"י שתי טבלאות מרכזיות. עובדה נוספת שצדה את עיניי שמספר ה-KB של שתי הטבלאות החשודות עולה ויורד ובאופן מתמיד. כלומר בכל רגע נתון הן תופסות בין 65% ל- 75% אחוז מגודלו של ה- Buffer Pool.

מה יכולות להיות הסיבות לכך??

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

לכן מצאתי לנכון ציין את הגורמים האפשריים לצניחת מדד ה- Page Life Expectancy הם:

1. שאילתות גרועות והיעדר אינדקסים- לשאילתות גרועות יכולות להיות השפעה הרת גורל על מדד זה. כאשר אני מדבר על שאילתות גרועות אני מדבר על אלו שצורכות הרבה מאד משאבים, בדגש על Physical I/O. כמובן במקרים רבים שאילתות בעייתיות נקשרות להיעדר אינדקסים ( או אינדקסים יעילים), עובדה אשר גורמת לפעולות Table Scan שממנה אנו צריכים להיזהר כמו מאש במיוחד כאשר עוסקים בטבלאות גדולות. מקרים אחרים בהם שאילתות יבצעו כמות מוגזמת של Physical I/O, קשורים בדרך כלל לחיבור בין טבלאות בעזרת JOIN. גורם נוסף הוא שימוש באופרטור ORDER BY, בדגש על מקרים בהם המידע לא נשמר בטבלאות בצורה ממוינת.
2. השתנות ה- Data- לרוב ניתן לאפיין את ה- Data שלנו בצורה מסוימת, יש לו תבנית אשר לא משתנה בצורה קיצונית. אבל עיתים ישנם מקרים בהם טבלה מסוימת שהייתה רגילה להיות קטנה, הולכת ותופחת ומגיעה לגדלים עצומים ביחס למה שהיא רגילה להיות, עובדה זו, גם יכולה לגרור פגיעה ישירה במדד ה- Page Life Expectancy. במיוחד אם מדובר על טבלה שפונים אליה באופן תדיר.
3. בעיות חומרה- לפני שהולכים ובודקים את השאילתות יש לבדוק האם משהו השתנה בכל הקשור לחומרה, משום שישנם מצבים בהם אחד מה- Slots שבהם יושב הזיכרון נהרס' וcמקרים הללו גם אם נשפר מאד את השאילתות שלנו, לא נרגיש שינוי בביצועים משום שבעיה היא בכלל חומרתית.

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

לכן נקטתי את הפעולות הבאות:

1.שלב א'- מחיקה- מחיקת הנתונים שהצטברו בעקבות התקלה. טבלה שאמורה להכיל בשיא הכושר שלה כ- 500 אלף שורות, הגיעה למצב קיצוני שהיא מכילה כמעט 11 מליון שורות. יש לציין שפונים אל טבלה זו באופן תדיר, ולכן למחיקה הייתה השפעה על מדד ה- Page Life Expectancy אך לא דרסטית.

2.שלב ב' תיקון השאילתות- על מנת לאתר את אותן השאילתות הבעייתיות נעזרתי בשני כלים שונים- הראשון הוא SQL Profiler, אשר באמצעותו יכולתי להקליט ולייצר קובץ Trace. ואז לנתח אותו ולהגיע למסקנות ברורות ונקודתיות, היכן בדיוק נמצאת הבעיה. כלי נוסף ויעיל לא פחות הוא  sys.sysprocesses זהו  VIEW מגרסאות ישנות של SQL Server. כיום, בגרסאות חדשות יותר ניתן לעבוד עם ה- DVM's הבאים: sys.dm_exec_sessions או sys.dm_exec_requests שמיכלים מידע על אילו תהליכים רצים כרגע על השרת ומי מריץ אותם (הערה חשובה: ניתן להשתמש ב- CROSS APPLY ל- sys.dm_exec_sql_text ולהוציא משם את הטקסט שאותו Process  מריץ). לאחר שמצאתי את אותן השאילתות החשודות, נחשו לאילו טבלאות הן פונות??? יפה!!!! הן פונות בדיוק אל אותן שתי טבלאות שמחזיקות 75% מה- Buffer Pool.  לאחר מספר בדיקות מצאתי כי שאילתה אחת ניתן לשפר בעזרת Sub Query. מסתבר שאם מורידים JOIN אחד ובמקומו מוסיפים בתוך ה-  WHERE  Sub Query שמחזיר רשימה של ערך שיש עליו אינקסים טובים.אז זמן הריצה של השאילתה יורד מדקה (ואף יותר) למספר שניות בודדות וכמובן שכמות ה- Physical I/O ירדה פלאים, ממאות אלפים למספר בודד של אלפים. את השאילתה השנייה, היה קצת יותר קשה לשפר, משום שלא יכולתי להשתמש ב- Sub Query. ולכן מכיוון שהשאילתה ביצעה JOIN בין 3 טבלאות שונות (שתיים מהן גדולות מאד), ורוב המידע נלקח מטבלה אחת ואז מוצלב עם יתר הטבלאות, החלטתי להשתמש בתחנת ביניים בצורת טבלה זמנית, אשר מכילה את המידע הרלוונטי בלבד, ועכשיו במקום לבצע JOIN  בין שתי טבלאות גדולות מאד, יש לנו JOIN בין טבלה זמנית קטנה מאד לבין טבלה גדולה, ואת זה הרבה יותר קל ל- SQL Server  לבצע. כמו כן, על מנת לייעל את השאילה עוד יותר, הוספתי אינדקס מתאים לאחת הטבלאות הגדולות וגם כאן השיפור היה עצום, השאילתה המקורית רצה בין דקה לשתי דקות, ואילו לאחר השיפור זמן הריצה שלה היה בין 0 ל- 3 שניות בלבד! Physical I/O צנח אל כ- 10,000.

לאחר כל זאת, כל שנותר לי לעשות הוא שני דברים, הראשון להתקשר לגיא גלנצר וצחי חקיקת ולהודות להם על העזרה הרבה שהעניקו לי, במיוחד על הכלים לפתרון בעיה מסוג זה! הדבר השני, היה להרים רגליים על השולחן, ולצפות בגרף של מדד ה- Page Life Expectancy דרך ה- Perfmon, נוסק אל על ומתייצב על רמה של  כ- 2000 שניות.

מקווה שנהניתם לקרוא,

חקיקת יוסי

זה קרה ביום שלישי בבוקר (שעון ארה"ב), בשעה 08:46 פגע המטוס הראשון במגדל הצפוני, כ-17 דקות מאוחר יותר, בשעה 09:03 פגע המטוס השני במגדל הדרומי מהשעה 10:28 באותו בוקר, לא נשאר זכר ממגדלי התאומים עליהם השלום. אירוע מכונן זה גרם למהפכה בתחומים רבים, אחד מהם, הוא הנושא שעליו אכתוב בפוסט זה- High Availability. ארגונים רבים איבדו את כל המידע שלהם בפיגועי ה- 11 בספטמבר, אמנם מדובר על אירוע שניתן לקטלג אותו תחת DRP, ראשי תיבות ל: Disaster Recovery Plan , שקשור יותר לביצוע גיבויים, שמירתם ושחזורם על שרת אחר במידת הצורך, אך בהחלט ניתן לומר שלאירוע הייתה השפעה רחבה יותר, הוא העלה על נס גם את נושא הזמינות הגבוהה של הנתונים, גם במקרים של כשלים קצת פחות קריטיים ממטוס או שניים שנכנסים אל הבניין שבו את/ה עובד/ת.

היום אתחיל בסדרה של שני פוסטים שכל פוסט אקדיש לשיטות אחרות של High Availability. כאשר מדברים על זמינות גבוהה צריך לקחת בחשבון את כל הגורמים אשר עלולים להינזק במידה כזו או אחרת, ושכתוצאה מכשל זה תיפגע זמינות הנתונים. דוגמאות לרכיבים מועדים לפורענות: דיסקים, שרתים, SQL Server, כבלים, חשמל, מערכת ההפעלה, שאילתות גרועות, נעילות ועוד ועוד. לכן, כאשר באים ליישם פתרון של זמינות גבוהה, יש לשים לב לאילו מהכשלים שצוינו הוא נותן מענה ולאילו לא! לא חסרים מזיקים, ושאר מרעין בשין, וחלילה שלא נטעה לחשוב שפתרון מסוים שבחרנו עונה בצורה מושלמת על כל הכשלים הבאים עלינו לכלותינו.

שיטה מספר 1 : Failover Clustering

זהו פתרון ברמת השרת, מבחינת SQL Server הוא פועל ברמת ה- Instance. יש להגדיש כי פתרון זה איננו פתרון SQL טהור, למעשה מדובר על פתרון ברמת מערכת ההפעלה (ארגונים רבים משתמשים בו בחוכמה ורותמים אותו לשרתי ה- SQL Server). ל- Windows Server  יש רכיב שמאפשר לו ליצור Cluster.כמו כן, יש להגדיר את Cluster  גם ברמת ה- SQL או בעת ההתקנה או לאחר מכן. כלומר, לוקחים שני שרתים או יותר (המונח המקובל הוא Node), ומקצים להם משאבים משותפים (לדוגמא Disk Space), שכל אחד מן השרתים יכול להשתמש בהם, אבל לא בבת אחת, אלא כל פעם המשאבים יהיו זמינים אך ורק ולשרת אחד. מכאן גם נובעים השמות של השרתים, השרת שצורך ברגע נתון את המשאבים נקרא Active ואילו השרת/ים האחרים נקרא/ים Passive. לשם המחשה, נניח שיש לנו שני שרתים שמחוברים יחדיו ב- Cluster. בן לאדן החליט לשלוח מטוס צעצוע עמוס חומרי נפץ אל שרת ה- Active, ברגע הפיצוץ מתבצע Failover אוטומטי, והשרת שהיה בתפקיד Passive הופך להיות Active. נקודה חשובה, יש לדאוג שכל השרתים יהיו זהים לחלוטין מבחינת המפרט הטכני שלהם. הסיבה הראשונה נעוצה בביצועים, אם שרת אחד יהיה חזק מאד ואחר יהיה חלש, אז ברגע שיתבצע Failover אל השרת החלש הוא פשוט לא יוכל לעמוד בעומס ונרגיש פגיעה בביצועים במקרה הטוב ומקרה הרע אף נגרום לקריסתו של השרת החלש. הסיבה השנייה קשורה לדרישות של חברת מיקרוסופט, שדורשת שהשרתים יהיו זהים, אחרת הם לא יעניקו שום תמיכה במקרה של תקלה.

יתרונות:

מקל על maintenance- ניתן לבצע ביתר קלות פעולות תחזוקה שוטפות ברמת השרת או SQL Server כגון התקנה של Service pack או עדכון גרסא, כמעט ללא פגיעה בפעילות השוטפת. וזאת משום שאני יכול לפעול בצורה הבאה: להתקין Service pack על השרת ה- Passive, לאחר סיום ההתקנה, לבצע Failover בצורה יזומה וידנית בין השרתים, ואז להתקין את אותו ה- Service pack על השרת השני ומיד לאחר מכן שוב לבצע Failover ידני על מנת להחזיר את השרתים לתפקוד המקורי שלהם. למותר לציין, כי בכל זמן התחזוקה, המערכת נמצאת באוויר וזמינה לכל דורש.
Failover אוטומטי ומהיר- במקרה של תקלה המעבר בין השרתים הוא מהיר מאד, למעשה פרק הזמן שלוקח ל- SQL Server לעלות, הוא פרק הזמן שהשרת לא יהיה זמין כלל, לרוב מדובר על כשישים שניות בלבד ואף פחות מכך. יתר על כן, המשתמשים כמעט ולא ירגישו שבוצעה מעבר בין השרתים, מבחינתם הם ממשכים לפנות לאותה כתובת IP, לאותו שרת והם ממשיכים לקבל את אותו השירות.

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

חסרונות:

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

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

המידע יושב במקום אחד בלבד– החיסרון אולי הגדול ביותר של שיטה זו הוא שעדיין יש לנו Single Point Of Failure, כלומר, אם לדוגמא יש כשל מסוים בדיסקים, אז לא תעזור לנו העובדה שיש לנו שני שרתים, משום הדיסקים הם משאב משותף לשני השרתים. המידע לא עובר לשום מקום אחר, הוא יושב במקום אחד בלבד, וזה סיכון דיי גדול.

שיטה מספר 2 : Log Shipping

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

• 1.גיבוי Full של מסד הנתונים
• 2. שיחזור של אותו גיבוי על שרת מרוחק, יש לשים לב שאנו משחזרים את מסד הנתונים במצב של No Recovery.
• 3. מעתה ואילך יתבצעו באופן תדיר שתי הפעולות הבאות: הראשונה גיבוי של קובץ הלוג במסד הנתונים בסביבת ה- Production. גיבוי תדיר של קובץ הלוג יתרום משמעותית  להקטנת זמן המעבר משרת ה- Production לשרת הגיבוי במצב של תקלה. הפעולה השנייה, היא כאמור שיחזור של קובץ הלוג בשרת המרוחק גם כן במצב של No Recovery.

מאחורי הקלעים, נוצרים למעשה שלושה Jobs אשר מבצעים את העבודה עבורנו. Job אחד דואג לבצע גיבוי של קבץ הלוג, Job שני דואג להעתיק את הקבצים אל שרת הגיבוי המרוחק, ואילו ה- Job השלישי לוקח את קבצי הגיבוי ועושה להם שיחזור במצב של No Recovery.

יתרונות:

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

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

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

חסרונות:

זמן- בשיטה זו לוקח זמן רב מדיי עד שנוכל להגיע למצב שבו המערכת באוויר. הסיבה לכך נעוצה בעובדה שישנן יותר מדיי פעולות לבצע על שנוכל להביא את שרת הגיבוי למצב זמין. הפעולות הן: גיבוי של קובץ הלוג האחרון לפני הקריסה, שליחה ברשת של אותו קובץ אל שרת הגיבוי המרוחק, שיחזור של קובץ הלוג האחרון במצב With Recovery. כמו העובדה שאין Failover אוטומטי, מאיטה את התהליך אף היא.

מסד הנתונים לא זמין בשרת הגיבוי-  מכיוון שאנו תמיד נמצאים במצב של Restoring, מסד הנתונים שלנו לא זמין כלל.

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

עומס על המערכת- שיטה זו שמצריכה גיבוי תדיר של קבצי הלוג ושליחה שלהם, גורמת להכבדה מסוימת על שרת ה- Production.

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

מקווה שנהניתם לקרוא,

חקיקת יוסי

SELECT *

מכירים את זה שאתם מגיעים לחתום על חוזה התקשרות עם חברה מסוימת, התנאים נראים מבטיחים, הצעה מעולה, ממש עסקת חייכם, אבל אז מגיעים לסוף הדף, ושם באותיות טל ומטר יש כוכבית, או כמה אשר מבהירות לכם שלא מדובר בעסקת חייכם ולא נעליים. היום כל בר דעת יודע- יש להיזהר מהכוכבית!! אז מעתה והלאה, אני מציע לכם בחום, ליישם את הלקח הזה גם בכל הקשור לסביבת ה- Production של SQLServer!! בסביבה זו יש להימנע ככל האפשר מהשימוש ב- *.

אחרי שבפעם האחרונה עסקתי בהרגל מגונה שעיקרו הוספת NOLOCK לכל שאילתה בלי חשבון, היום אעסוק בהרגל מגונה אחר, נפוץ הרבה יותר, והוא כאמור * SELECT . בפוסט זה אתייחס לנושא ממספר זוויות והן: הסיבה העיקרית לשימוש ב- *, מתי השימוש לא מזיק, ועיקר הפוסט, ההשפעות השליליות של * SELECT , כן, יש כאלו, ולא מעט!

כאשר מנסים להצדיק את השימוש ב- * SELECT הטענה הראשונה וכמעט היחידה שעולה היא ש- * SELECT חוסך עבודה. נגיד שיש טבלה עם 5 עמודות, ומחר  צריך להוסיף עמודה נוספת, אז לא צריך לשנות את הקוד יותר מדיי, משום ש – * SELECT לוקח את כל העמודות וזה חוסך זמן, אין צורך לתקן את הקוד ע"י הוספת העמודות. הטענה השנייה היא דומה, אם ישנן הרבה עמודות בטבלה מסוימת אז זה יותר קל ונוח לרשום * במקום להקליד את כל העמודות. הצד השווה בין שתי הטענות הוא ששורש השימוש ב- * טמון בעצלנות (או חסכון בזמן אם להיות עדינים יותר…) אז אם אלו הסיבות העיקריות לשימוש ב- *,מסתבר שלא צריך לעבוד קשה מדיי על מנת להציג את כל העמודות של טבלה מסוימת. למי שלא מכיר ישנה אפשרות ב- Management Studio להוסיף את כל העמודות בהינף קליק. ב- Object Explorer, לכל טבלה מופיעות אותן שש עמודות קבועות, אחת מהן היא Columns. עומדים על תיקייה בשם  Columns ופשוט גוררים אותה אל המיקום הרצוי בחלון ה- Query. וזהו! לא צריך להקליד כלום, כל העמודות כתובות לפניכם, מופרדות בפסיקים על מגש של Query.

אז לאחר שהסיבות העיקריות לשימוש ב * SELECT כבר לא קיימות, אדגיש כי במקרים לא מעטים השימוש ב * SELECT הוא בסדר גמור ולגיטימי, לדוגמא כאשר רוצים לבצע בדיקות מסוימות או שעובדים עם DMV's שונים. אין שום בעיה במקרים אלו. הבעיות מתחילות שעושים שימוש ב * SELECT בסביבת ה- Production, לדוגמא: * SELECT בפרוצדורות שונות. מה שמוביל אותי לדבר על הצד הפחות זוהר של * SELECT .

לחץ על התמונה להגדלה

ההשפעות השליליות של * SELECT :

• פגיעה בשימוש נכון באינדקסים קימיים- במקרים מסוימים כאשר נריץ שאילתה עם * SELECT , התוצאה הישירה תהיה סריקה מלאה של טבלה או של ה- Clustered Index.  לשם המחשה נריץ את שתי השאילתות הבאות, שימו לב השאילתות זהות במהותן, רק שבראשונה יש שימוש ב- *, ואילו בשנייה כתובות העמודות הרצויות בלבד:

:Using SELECT * query –

* SELECT

FROM Sales.SalesOrderDetail

;WHERE ProductID < 750

:Same query as the above but this time, using specific columns –

SELECT SalesOrderDetailID,ProductID,SalesOrderID

FROM Sales.SalesOrderDeta

;WHERE ProductID < 750

נציץ ב- Execution plan:

לחץ להגדלת התמונה

השאילתה הראשונה (עם * ), עולה כמעט פי 50 מהשאילתה שמציינת במפורש שדות ספציפיים. הסיבה לכך נעוצה בעובדה ששאילתה מספר 1 גורמת לסריקה מלאה של ה- Clustered Index ( שווה ערך פחות או יותר סריקה מלאה של הטבלה). ואילו בשאילתה מספר 2 בוצעה סריקה של ה- NonClustered Index שבמקרה זה, היא פעולה הרבה פחות כבדה. זאת ועוד, במקרים אחרים, שימוש ב- * SELECT גורר פעולות מיותרות אחרות(וכבדות!!) כמו Lookups. לדוגמא אם נריץ את אותן שאילתות מהדוגמא הקודמת אך נשנה את התנאי ב- WHERE ל-  20 אז נוכל לראות ששאילתה מספר 1 גורמת לפעולת lookups שהיא בעצם החלק הכבד של השאילתה (50% מעלות השאילתה מוקדשת לכך). ואילו באפשרות השנייה, מתבצע Index seek על NonClustered IX_SalesOrderDetail_ProductID, שהיא יעילה בהרבה.

לחץ על התמונה להגדלה

• יצירת עומס על השרת- אז כפי שהרגע ראינו במקרים רבים שימוש ב * SELECT גורם לסריקות של טבלאות או אינדקסים בצורה לא יעילה ולא נחוצה. ישנם מקרים רבים בהם השאילתה מחזירה לאפליקציה נתונים שאין בהם שום שימוש, משום שהשאילתה מחזירה 10 עמודות לדוגמא, אך האפליקציה מציגה רק 3 עמודות מתוך ה- 10. העומס מתבטא הן בפעולות I/O רבות שאיו בהן צורך, והן במעבר של נתונים ברשת שגם בהם כמובן אין שום שימוש.
• שינוי סכמה ב- View-  כאשר יוצרים View בעזרת * SELECT ישנה בעיה עיקרית אחת. נניח שלאחר זמן מה, מחליטים לשנות את שם אחת העמודות מ- Bla ל- Bla2. ה-MetaDta של ה- View לא מתעדכן באופן אוטומטי על השינוי, ואין לו מושג שעמודה מסוימת כבר לא נקראת כפי שהיא נקראה בעבר. נסבך את העניינים עוד טיפה, תארו לכם שעכשיו נוסיף עמודה חדשה שנקראת Bla והיא בכלל מסוג אחר(עמודת תאריך במקום מספר שהיה עד כה) במצב זה אנו נקבל ונציג מידע שגוי. (אציין כי ניתן למנוע מצב זה בעזרת שימוש ב- SCHEMABINDING אשר לא מאפשר שימוש ב- * SELECT).
• · ניטור שגיאות- על מנת להמחיש את הנקודה הבאה אגש ישר לדוגמא, ישנה פרוצדורה שמקבלת כפרמטר את rowguid@  ומחזירה נתונים:

* SELECT

FROM Sales.SalesOrderDetail

WHERE rowguid = @rowguid

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

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

מקווה שנהניתם לקרוא,

חקיקת יוסי

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

הסיפור הנ"ל ממחיש לטעמי בצורה טובה למדיי את כל הקשור לשימוש ב- Locking Hint הנקרא: NOLOCK. ישנה בעיה, בד"כ קשורה לנעילות, ומצד שני ישנו פתרון (NOLOCK) אבל במקרים לא מעטים זה לא הפתרון האמיתי לבעיה אלא פשוט הפתרון הקל. בארגונים רבים ישנו נוהל או מנהג להוסיף לכל שאילתה NOLOCK, בצורה אוטומטית בלי שום קשר לתוכן השליפה וללא מתן תשומת לב לשאלה החשובה כל כך, האם המידע שאני שולף הוא עדכני, תקף ולא עבר שום שינוי בזמן שליפתו! בד"כ הסיבה לשימוש מאסיבי ב- NOLOCK היא זהה במרבית הארגונים, בשלב מסוים, הייתה בעיה של נעילות במערכת שגרמו לעיכובים וכמובן פגעו ישירות בביצועי המערכת, ואז מישהו עלה על הפתרון האולטימטיבי, גם אין נעילות וגם משפרים ביצועים תענוג נכון?? מצטער לקלקל לכם, אבל ממש לא!

ישנן מספר נקודות בסיסיות שעלינו להבין בנוגע לשימוש ב- NOLOCK:

1. Allow Dirty Reads- כאשר מריצים פקודת SELECT עם NOLOCK המשמעות היא שאין שום השפעה לנעילות אחרות, כלומר יכול בהחלט להיווצר מצב שאנו קוראים שורות שבינתיים עשו עליהן ROLLBACK או מצד שני שורות שעדיין לא קיבלו COMMIT. (הערה: NOLOCK עובד בדיוק כמו Read Uncommitted, רק ש-Read Uncommitted מוגדר ברמת ה-Session).

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

3. רשומות כפולות או היעדר רשומות – את הנקודה החשובה והמעניינת הזו לימד אותי נעם ברזיס. כאשר מרצים שאילתה שגורמת לפעולת Index Scan, יכול להיווצר שבו השימוש ב- NOLOCK יגרום ל-SQL Server לא להציג רשומה מסוימת או יציג אותה פעמיים (בלי שום קשר ל- Dirty Reads). לדוגמא:

משתמש הריץ את השאילתה הבאה, (הטבלה בעלת מספר גדול של רשומות) לטבלה יש אינדקס על עמודת Price:

לאחר 5 שניות ריצה לדוגמא, פעולת  ה- Index Scan הגיעה לערך 15.00 (יש לזכור שהסקירה מתבצעת לפי סדר האינדקס), משתמש אחר ב- Session אחר כמובן, ביצע פעולת INSERT שה- Price הוא 14.00. במצב זה, הרשומה שזה עתה נכנסה, לא תוצג ב- Record Set . משום שפעולת ה- Index Scan דילגה עליו.

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

· שימוש לא יעיל ב- Transactions- Transactions צריכות להישמר קצרות ככל הניתן! לשם המחשה, נגיד שיש לנו פרוצדורה ארוכה שבהתחלה מריצים בה פקודת SELECT דיי כבדה, שמכניסה את הנתונים לטבלה זמנית, לאחר מכן, מבצעים חישוב על אותם נתונים, עושים JOIN עם טבלה אחרת ואז בסוף כל זה יש פקודת UPDATE או DELETE. במצב כזה, יש לפתוח את ה- Transaction רק בפקודת ה-UPDATE או ה- DELETE ולא לאורך כל הפרוצדורה ולסגור אותה מיד בסיום הפעולה!

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

· Foreign Keys – יכולים לגרום לנעילות במקרים מסוימים אבל נושא לפוסט שלם.

מתי נשתמש ב- NOLOCK ומתי לא:

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

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

חקיקת יוסי

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

אז ככה, מגרסת 2005 ומעלה SQL Server הציגו לעולם את הפיצ'ר שנקרא  Logon Triggers שנועד לעזור לנו לשלוט בצורה סינכרונית (הסבר מפורט בהמשך…) על מספר המשתמשים ברגע נתון ב- Instance מסוים או רק לדעת מי מחובר כרגע. וכמו כן,גם על מספר ה- Sessions  שמריץ כל משתמש. חשוב לציין כי Logon Triggers השונים נכנסים לפעולה אך ורק לאחר השלמת תהליך ההתחברות ל-Instance, אך לפני שהמשתמש פתח Session חדש מול SQL Serve.

איך Logon Triggers פועלים?

השינוי המשמעותי ש- Logon Triggers מקנים לנו המשתמשים הוא בעצם ניטור ושליטה סינכרוניים על תהליך יצירת Sessions. אם תרצו, תוכלו לנטר יצירה של Sessions  בעזרת Trace Event שנקרא: AUDIT_LOGIN. ממש כמו Logon Triggers, הוא מופעל בכל פעם שנוצר Session  חדש במערכת אך לפני תחילתו בפועל(כמובן לאחר תהליך ה- Authentication). הבעיה היא, שלא ניתן לנקוט כל פעולה בעזרת ה- Trace Event בתגובה! ופה בעצם טמון היתרון הגדול של Logon Triggers, הם, בניגוד ל- Trace מאפשרים לנו לפעול בתגובה לאירוע של יצירת Session לפני תחילתו בפועל!! קרי, יכולת לשלוט על מספר המשתמשים וה- Sessions בצורה סינכרונית.

דוגמא מספר 1: Logon Trigger for all connections

עיינו בקוד הבא:

CREATE TRIGGER MonitoringAllConnections
ON ALL SERVER
AFTER LOGON
AS
BEGIN
+ 'PRINT SUSER_SNAME() + ' Just logged to
+ 'UPPER(LTRIM(@@SERVERNAME))+ ' SQL Server at
 + ':LTRIM(GETDATE()) + ' With
()APP_NAME
END
GO

.Trigger זה מבצע פעולה פשוטה מאד, כל פעם שנוצר חיבור ל- Instance, ולא משנה ע"י מי, מייד תכתב ב- SQL Error Log שורה כזו:

פקודה זו, טובה לבקרה כללית, אם כי לדעתי ,לא חייבים להשתמש ב Trigger עבורה ניתן להיעזר בDMV שונים.

הערה חשובה ביותר: במקרה מסוים ניסיתי לשלב בין ה- Logon trigger שבדוגמא זו לבין פקודת INSERT. הכנתי טבלה שמטרתה הייתה לשמור נתונים שונים אודות ההתחברויות (לדוגמא: SYSTEM_USER, USER,APP_NAME(),@@SPID,GETDATE()),התנתקתי מה- Instance ואז להפתעתי הרבה לא הצלחתי להתחבר שוב! (למזלי הרב, צי'קו דרורי (יועץ ב- Madeira), העביר הרצאה מעולה על DAC והצלחתי להתחבר בעזרת DAC ולמחוק את ה- Trigger ,ניתן להיעזר ב-sys.server_triggers לאיתור ה-Triggers). ואז לאחר חיפוש ב- BOL, הבנתי שאין באפשרות Logon Trigger להחזיר Results Sets. ולפי דעתי זו הסיבה שפעולות ה- INSERT נכשלה וגרוע מכך, אף מנעה ממני להתחבר שוב ל- Instanc.

דוגמא מספר 2: Logon with restricted number of Sessions per Login

CREATE TRIGGER LogonTriggerWithConnectionLimit
'ON ALL SERVER WITH EXECUTE AS 'Sa
FOR LOGON
AS
BEGIN
'IF ORIGINAL_LOGIN()= 'Sa
AND
)
SELECT    
 (*)COUNT       
FROM    
SYS.DM_EXEC_SESSIONS      
WHERE    
is_user_process = 1 -- 1 = User Session || 0 = System Session     
AND       
5 < ( 'original_login_name = 'Sa    
Allow this user to open only 5 query windows --
;ROLLBACK
;END

במקרה זה באה לידי ביטוי אחת מיכולותיו הייחודיות והמשמעותיות של Logon Triggers. בדוגמא זו, בחרתי להגביל את מספר ה- Sessions של Login בשם sa לחמישה בלבד! כלומר, הוא יוכל לפתוח חמישה חלונות Query שונים, אך אם הוא ינסה לפתוח את השישי הוא יתקל בהודעה הבאה:

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

דוגמא מספר 3: מחיקת Logon Trigger-

על פניו נראה שאם נריץ את הפקודה הבאה: DROP TRIGGER <Trigger Name> אזי ה- Trigger ימחק. אז זהו שלא….. הרצה של הפקודה הבאה תביא להודעת השגיאה הבאה:

על מנת למחוק Logon Trigger חייבים להוסיף את השורה הבאה ON ALL SERVER. הפקודה המלאה היא:

DROP TRIGGER <Trigger Name> ON ALL SERVER

מכיוון שה- Logon Trigger הוגדר ברמת השרת, יש גם לציין זאת בעת המחיקה.

בקרה וניטור:

ניתן להיעזר ב- DMV הבא- sys.server_triggers, על מנת לקבל רשימה של כל ה- Triggers ברמת Instance, ביניהם ניתן למצוא כמובן את ה- Logon Triggers שהוגדרו.

חסרונות:

· מנפח את SQL Server Error Log- במידה ומפעילים את ה-LogonTrigger שבדוגמא הראשונה, אזי כל התחברות ל- SQL Server תירשם Error Log, כולל התחברויות של SQL Agent או Reporting Services וכו'. על מנת למנוע מצב זה, יש לבצע סינון חכם של אילו חיבורים אנו מעוניינים לנטר ואילו לא. בדוגמא השנייה, הבעיה עדיין קיימת משום שכל פעם שDBA או מפתח ינסו לפתוח את חלון ה- Query השישי הם יקבלו הודעת שגיאה שאף היא תרשם אל ה- Error Log.

· שימוש לבצע סינון חכם פר משתמשים ולא פר תהליכים שרצים- יש הרבה תהליכי מערכת שרצים ברקע, אין שום שסיבה לפי דעתי שה- Logon Triggers יאכפו אותם.

· במקרים של שימוש לא נכון, ה- Logon Trigger עלול למנוע גישה ל- SQL Server- כפי שהוסבר, במקרים בהם נרצה להריץ פקודת SELECT בתוך ה- Trigger, בכניסה הבאה שלנו, לא נוכל להיכנס אלא באמצעות ה- DAC.

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

חקיקת יוסי