ארכיון

Archive for the ‘SQL Server’ Category

הזמנה להרצאה שלי – "מבוא ל-Service Broker במערכות SQL Server 2005/2008"

ביום שני 3 במאי 2010 בשעה 17:30 יתקיים מפגש של קבוצת המשתמשים של SQL Server (המכונה ISUG) במיקרוסופט רעננה (ברח' הפנינה). במסגרת המפגש אני אעביר הרצאה על נושא שרבים מאנשי DB לא ממש מכירים – יכולות messaging של בסיס הנתונים. ההרצאה "מבוא ל-Service Broker" תציג את הכלי שמגיע כחלק ממערכת SQL Server 2005 או 2008 ומהווה middleware פשוט, מהיר, יעיל ונוח לתפעול בין רכיבי תוכנה פנימיים (stored procedures) ו/או חיצוניים (תוכנות בשפה עילית).

ההרצאה היא בחינם !!! רק להגיע וללמוד.

קהל היעד הוא לא רק אנשי DBA אלא גם מפתחים וארכיטקטים שלא מכירים את הכלי הזה.

במסגרת ההרצאה אני אדגים תוכניות ריצה (demos) של רכיבי T-SQL כמו גם רכיבי דוט נט כתובים ב-#C שימחישו כיצד ניתן להשתמש בכלי הזה.

שימו לב – זה אחד הכלים הבודדים ב-SQL Server שעל מנת להשתמש בו ולהגדיר הגדרות, לא ניתן להשתמש בממשק GUI ומצריך כתיבת קוד באצבעות.

כולם מוזמנים !!!

נ.ב. – יש גם בורקסים ושתייה, כמיטב מסורת האירוח של מיקרוסופט.

מודעות פרסומת

"עכשיו מעונן" – בסיסי נתונים במחשוב ענן

מחשוב ענן (Cloud computing) הוא buzzword שרץ חזק בשנתיים האחרונות בעולם ה-IT. חברות מובילות כמו מיקרוסופט, אורקל ו-IBM עובדות על כל מיני פתרונות בתחום וכבר נשפכו לא מעט מילים על כך (והרבה מאד דולרים).

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

דמיינו לכם שאתם מפתחים מערכת שה-DB שלה בתוך ענן, אי שם ברשת ה-WAN (או ה-LAN הארגוני). לא צריך שום התקנות, שום ברזלים, וה-DB הזה מנוהל ומתוחזק ע"י מישהו אחר, עובר גיבוי ע"י מישהו אחר, ניתן להעמיס עליו כמות משתמשים ככל שנדרש מבלי לדאוג ל"ברזלים" (מישהו אחר דואג לזה). אתה משלם על השימוש ב-DB בהתאם למשאבים שאתה באמת צורך. אה ! מה עם storage? את מי זה מעניין. מישהו אחר דואג ל-storage. פשוט משלמים על פי מה שצורכים. ועוד משהו: ה-DB הזה זמין 24X7 וכמעט שלעולם לא נופל (כי הוא מתוחזק ע"י טכנולוגיות clustering למיניהן).

נשמע מעניין, נכון?

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

מחשוב ענן יכול להיות ברשת האינטרנט העולמית או פנימי באינטראנט הארגוני.

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

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

מיקרוסופט הולכת עם פרויקט שאפתני בשם Azure כאשר חלק ממנו הוא ה-SQL Azure שהוא למעשה פתרון לבסיס נתונים במחשוב ענן אשר צפוי להיות זמין לשימוש דרך האינטרנט במהלך השנה הקרובה. לפרטים:  http://www.microsoft.com/windowsazure/sqlazure

אורקל גם היא עובדת חזק על ה"ענן" וחברה לחברת "אמזון" (כן, אלה מהספרים…) ומאפשרת לשים פתרון תוכנה שלם מבוסס אורקל בענן של אמזון. כמו כן ניתן לגבות DB מחוץ לענן אל תוך הענן. לפרטים: http://www.oracle.com/technology/tech/cloud/index.html

עדיין אין פתרון מוכרז ל"ענן" ארגוני – אבל בטח גם זה יגיע בהמשך.

בשורה התחתונה, אנחנו על סף עידן חדש בתחום בסיסי הנתונים. עידן ה"ענן" עשוי לחדור כבר ב-2010 חזק לתעשייה. האם זה אומר שבסיסי הנתונים "הרגילים" ייעלמו בעתיד? התשובה: לא כל כך מהר! אנחנו צפויים לראות מערכות "ענן" רצות לצד מערכות קונוונציונליות לפחות בשנים הקרובות. ומה בעתיד הרחוק יותר? התשובה תלויה כנראה ב-buzzwords של 2015.

לאסוף מדדים ממערכת ההפעלה Windows ולתחקר אותם בהמשך

Perfmon הוא כלי נפלא ופשוט המאפשר לראות מדדי מערכת. אבל – לעיתים אנו רוצים לדגום יום שלם או שבוע שלם של מדדים שמייצר שרת Windows ואח"כ לנתח את הנתונים. כמו למשל, מתי היו רגעי שיא של פעולות CPU, רגעי שיא או שפל של תור הפניות ל-I/O  משכי זמן של Peaks וכו'.

ישנן שתי דרכים לעשות זאת:

דרך אחת – להשתמש ב-Utility של Windows הנקראת LOGMAN.

דרך שניה – לבצע "שאילתות" למשאבי השרת באמצעות אובייקטים של WMI או Windows Management Instrumentation. במקרה זה אפשר להשתמש ב-VBScript או לכתוב תוכנית בשפה עילית (DOT NET או Unmanaged code).

במאמר הזה אתמקד בשימוש ב-LOGMAN. שימוש ב-WMI הוא נושא למאמר נפרד ואולי אפילו לכמה מאמרים. נשאיר את זה בצד לעת עתה.

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

ב-Books On Line (או BOL) של מיקרוסופט אפשר למצוא תיעוד של כל שלל האפשרויות לשימוש בתוכנה זו.

כדי ללמוד איך להשתמש ב-LOGMAN, בואו פשוט נראה דוגמה. בחלון שורת פקודה (CMD) נבצע את הפקודה הבאה:

logman create counter MyTrace -s MyServer -f  sql -si "00:00:05" –v -o DBServer!DBA -cf "c:\counters.config" -u MyUsername MyPassword

בפקודה זו הגדרנו תהליך איסוף מדדים בשם MyTrace שדוגם מדדים משרת בשם MyServer כל 5 שניות ואת התוצאות אנחנו רוצים להזין לטבלה ב-DB רלציוני התומך ODBC. הנתונים יכנסו לשרת DB בשם DBServer  לבסיס נתונים הנקרא DBA (באורקל זאת תהיה סכימה בשם DBA). ה-LOGIN לבסיס הנתונים יהיה עם המשתמש MyUsername ועם הסיסמה MyPassword. המדדים שברצוננו לדגום מפורטים בקובץ בשם counters.config.

כדי העסק יעבוד, יש להגדיר את ה-DB שאליו יש להזין את המדדים ב- ODBC Data Sources (ע"י Control Panel -> Administrative tools -> Data Sources). בלשונית SYSTEM DSN הוסיפו את שרת בסיס הנתונים (יכול להיות SQL Server, אורקל, MySQL או כל בסיס נתונים אחר שתומך ODBC).

LOGMAN יצור באופן אוטומטי טבלה (אם היא לא קיימת) שאליה הוא יזין את המדדים.

את רשימת המדדים אפשר לבנות בקלות ע"י PerfMon. אספו את המדדים שברצונכם לדגום עם LOGMAN באמצעות PerfMon. אח"כ לחצו CTRL-L ויפתח חלון. בלשונית DATA תוכלו לראות את שמות המדדים שבחרתם כפי שיש לציינם בקובץ הקונפיגורציה. אפשר כמובן לציין לא רק מדדים של Windows אלא גם מדדים של SQL Server או אורקל.

לאחר שהגדרנו את תהליך איסוף המדדים, כל שנותר הוא להפעיל אותו ע"י הפקודה:

logman start -s MyServer MyTrace

ה-LOGMAN יצא לדרך ועכשיו הוא מתחיל להזין נתונים לטבלה.

כדי לעצור את התהליך אפשר להריץ:

logman stop -s MyServer MyTrace

התהליך נעצר. ניתן לשוב ולהפעילו ע"י START.

 

מי לעזאזל מכביד קשות על שרת ה-Analysis Services?

מערכות ה- OLAP המובילות בעולם נכון להיום הן מערכות  SQL Server. לרוב הן רצות על שרתים יעודיים המשמשים כמעט בלעדית לעיבוד קוביות של SSAS. השרתים משמשים את המשתמשים שמריצים דו"חות על הקוביות הללו (לרוב דרך מערכות להפקת דו"חות). במקרים רבים ישנו משתמש המחליט "לקרוע" את השרת הזה עד זום דם ומריץ אגרגציה מטורפת על כמות אדירה של נתונים – והכל בזמן אמת.

הבעיה היא – איך עולים על המשתמש הסורר? מי תוקע את כולם? מה בדיוק גרם למערכת "להיתקע"?

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

למנוע הטבלאי של SQL Server יש אפשרות להריץ trace שמזין את אותו הפלט של profiler לקובץ או לטבלה. אבל לצערי, אין trace עדיין ל-SSAS שניתן להרצה דרך T-SQL או דרך XMLA.

אז מה עושים? יש לנו את הדוט נט לטובת העניין!!!

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

הייתי רוצה רק להזכיר את ה-namespace לטובת tracing שנקרא Microsoft.SqlServer.Management.Trace.

אפשר להפעיל אותו גם על SQL Server הטבלאי וגם על SSAS. זה פותר לנו את בעיית המחסור ב-trace על SSAS הניתן להפעלה דרך T-SQL.

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

עכשיו חסר לנו עוד דבר – מדדים של מערכת ההפעלה (כמו זכרון, מעבד ודיסקים) ושל SSAS. אם נתעד גם את המדדים וגם את הפעולות (trace) ואם נצליב ביניהם, נוכל לדעת מי המשתמש שהריץ איזה MDX שגרם למשל ל-CPU להגיע ל-100 אחוז.

אז איך אוספים מדדים? על כך אכתוב בפוסט הבא.

Performance counters לניטור שרת SQL Server

מערכת ההפעלה Windows על כל שלל גרסאותיה מספקת כלי ניטור פשוט ויעיל הנקרא Performance monitor או PerfMon בקיצור. 

שואלים אותי הרבה קולגות, באיזה counters של Perfmon להשתמש כשרוצים לנטר שרת SQL Server.

אכן ישנם המון counters או מדדים (בעברית) שאפשר להשתמש בהם. אבל רובם לא ממש עוזרים לאתר בעיות.

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

בגדול – מה שמעניין הם שלושת מרכיבי הבסיס של השרת: המעבדים (CPU), ה-I/O (דיסקים) והזכרון.

לגבי זכרון – ניתן להפעיל את SQL Server על מערכת 32 ביט גם עם יותר מ-4GB של זכרון ע"י שימוש ב-AWE הלוא הוא ה- Address Windowing

Extension. אני תמיד ממליץ ללקוחות שלי להתקין SQL Server בגרסת 64 ביט על גבי מערכת הפעלה Windows ב-64 ביט במערכות production ולא להשתמש ב-AWE והסיבה היא של-AWE יש תקורה הגורמת למערכת לעבוד לאט יותר בשל הצורך להמיר כתובות מהחלון הוירטואלי ב- 32 ביט למרחב הכתובות הפיזי.  

ישנן מערכות SQL Server שמריצות פונקציות חיצוניות ב-DLL-ים של 32 ביט – אילו עשויות לא לעבוד כיאות ב-64 ביט ובמקרה כזה יש לשקול שימוש ב-AWE. אם אפשר לקמפל את ה-DLL מחדש (בהנחה שישנו ה-source code) עבור 64 ביט – הרי זה עדיף.

 

ובכן, להלן רשימת ה-counters הבסיסיים שבהם אני מתחיל כשאני ניגש לשרת SQL Server וברצוני לקבל תמונת מצב עכשיווית לגבי ביצועיו.

CPU

Object: Processor – Counter: % Processor Time

Object: Processor – Counter: % Privileged Time 

Object: System – Counter: Processor Queue Length 

Object: Process – Counter: % Processor Time – Instance sqlservr

Object: Process – Counter: % Privileged Time – Instance: sqlservr

DISK I/O

Object: Physical Disk – Counter: Disk Writes/Sec

Object: Physical Disk – Counter: Disk Reads/Sec

Object: Physical Disk – Counter: Disk Write Bytes/Sec

Object: Physical Disk – Counter: Disk Read Bytes/Sec

(Average time it takes to perform a disk I/O – should be 5-10 ms, 10-20 on bug data warehouse)

Object: Physical Disk – Counter: Avg. Disk Sec/Write 

Object: Physical Disk – Counter: Avg. Disk Sec/Read

(I/O queue waits – should be < 3)

Object: Physical Disk – Counter: Avg. Disk Write Queue Length

Object: Physical Disk – Counter: Avg. Disk Read Queue Length

SQL Server: Buffer Manager: Page reads/sec

SQL Server: Buffer Manager: Page writes/sec

Memory

Object: Memory – Counter: AvailableMbytes

(Counters with no AWE info)

Object: Process – Instance : sqlservr – Counter: Virtual Bytes

Object: Process – Instance: sqlservr – Counter: Working Set

Object: Process – Instance: sqlservr –Counter: Private Bytes

SqlServer:Buffer Manager –  Buffer Cache Hit Ratio

SqlServer:Buffer Manager –  Free pages

SqlServer:Buffer Manager –  Page Life Expectancy (should be above 300)

 

For AWE usage:

Object: SQL Server:Buffer Manager – Counter: Database Pages — This counter shows the number of pages used by the buffer pool for database content.

Object: SQL Server:Buffer Manager – Counter; Target Pages— This counter shows how manypages SQL Server wants to allocate for the buffer pool.

Object: SQL Server:Buffer Manager – Counter: Total Pages— This counter shows how many pages SQL Server is currently using for the buffer pool.

Object: SQL Server:Memory Manager – Counter: Target Server Memory (KB)—This counter shows how much memory SQL Server would like to use for all its memory requirements.

Object: SQL Server:Memory Manager – Counter: Total Server Memory (KB)—This counter shows how much memory SQL Server is currently using.

הבלוג שלי

הבנתי שהגיע הזמן לכתוב בלוג מקצועי משלי.

כיועץ בתחומי IT שונים ומגוונים (בעיקר בסיסי נתונים), אני נתקל בכל מיני מיקרים וחשבתי: מדוע לא לשתף אנשים נוספים בבלוג שלי? ואם כבר – אז שיהיה בעברית, בשפת האם. למרות ששפת האם של המקצוע היא לחלוטין אנגלית.

הבעסה שבלכתוב בלוג מקצועי בעברית היא להפוך כיוון כל שניה מעברית ל-English וחוזר חלילה – אבל … אתגבר.

אני מקווה לקבל תגובות של גולשים על הפוסטים שלי ומקווה להועיל במשהו לקולגות שלי במקצוע.