SQL Azure for DBAs and Data Engineers

שלום רב מיקרוסופט התקדמו מאד במתן האפשרויות ב SQL Azure לנטר ולדעת מה קורה בבסיס הנתונים. המדדים נשמרים במחסן נתונים ומתחלקים ל 2 אגפים : AzureMetrics אלו המדדים הראשים של AZURE שם הם אוספים הכל גם למכונות לסטורג וכמובן לבסיסי נתונים. למשל בעולם של SQL Azure מדובר על DTU וכל מה שאפשר לצפות בגרפים בפורטל. AzureDiagnostics פה מדובר על מטריקות יותר מתקדמות תחת אגף זה נכנסים קטגוריות כמו Audit שהחלטה לשלוח לשמירה, Query store, המלצות, Wait type של DBA וגם Insights. בקיצור אגף מרתק ומעניין - וארחיב עליו בקרוב בפוסט מורחב. כאשר מחליטים לקשר Azure SQL לאגף - הולכים לבסיס הנתונים מקשרים אותו והמערכת מלבד מתחילה לשמור נתונים...(היא שומרת אותם בבסיס הנתונים הידוע בשם Kusto או בשמו החדש Azure Data Explorer, וגם על כך אני מבטיח פוסט בקרוב ממש) השמירה היא ל 30 יום. ואז אפשר לתחקר בשפת ה  Kusto ( עוד פוסט בקרוב אמרנו?...) או בדשבורדים שמיקרוסופט נתנו, או אפילו ב Power bi (וואו גם על זה עוד פוסט?... בכיף.) העיקר שיהיה אפשר לתחקר. בקיצור ים של DATA נשמר - רק קחו ונצלו אותו. להלן ...

שלום רב מעקב אחרי שינויים בבסיס נתונים זה דבר בסיסי. מי שינה קונפיגורציה של בסיס הנתונים ומתי. מי עשה שינויים בסכמה או ב DATA ומתי. מי שינה קונפיגורציה של השרת ומתי. בקיצור הרבה מידע לדעת. בשירות המנוהל SQL Azure DB , הקונפיגורציות הן ברמות שונות, יש ברמת של T-sql, יש ברמה של PowerShell ויש פעולות שעושים בפורטל. אחד הדברים שקשים זה מה הסטאטוס של בקשה שביצעתי בפורטל למשל לעשות Scale לבסיס נתונים, או ליצור לו רפליקציה. ל Activities Logs נכתב לוג של הפעולות. אבל אין אתה יודע מה הסטאטוס. לאחרונה עליתי על עוד מקום שנרשם שם הכל, למשל שיכפול בסיס נתונים, קינפוג של רפליקציה ועוד ועוד. אז ככה: יש ללכת ל RG של בסיס הנתונים ולגשת לספריה הקרויה Deployment.    פה רואים כל מה שקרה ב RG. לדוגמא פה רואים שיש Deployment שבוא בביצוע כעת (יצירת רפליקה): אפשר לראות שיש היסטוריה של שגיאות : וכמובן מה השגיאה שארעה למשל פה הגענו לגבול ה TDU שבשרת הזה: לעיתים אין הסבר לכישלון ואז רק רואים קוד שגיאה: כשלוחצים על מה שכן הצליח רואים פרטים רבים: זהו עוד מידע לצ...

שלום רב למי שיש הרבה בסיסי נתונים מפוזרים בענן רוצה לצבור עליהם מידע לצרכים שונים יכול ליצור סקריפט PowerShell שיעבור על כל ה Subscriptions ויאסוף מידע שקיים ב PowerShell. וכן המקום לפינת הקיטור היומית - ידידינו ממיקרוסופט מה עם Backward Compatability? היו לי פרמטרים שיכלנו לשאוב למשל כמה גודל בסיס הנתונים וכרגע אי אפשר לדעתי. נכון נותנים את המידע במקומות אחרים אבל נוח שזה יעבוד שנים - וסקריפט שעבד לי שנים - לאחרונה הפסיק לעבוד. יש לזה המון שימושים למשל רוצים לראות באילו בסיסי נתונים יש המלצות למשל להוסיף אינדקס ואתה לא רוצה לעבור בפורטל לכל בסיס נתונים. או מתי הגיבוי הראשון או הגיבוי האחרון שיש. אז הנה סקריפט בסיסי ממש - מוזמנים לשפר ולשתף עם הקהילה. ראשית עליכם לוודא שהמודולים של Azure מותקנים אצלכם (הרצה חד פעמית במחשב) install-module -Name AzureRM -Force עושים לוגאין ליוזר שלכם ב Azure (חד פעמית בסשין) Add-AzureRmAccount מריצים את הסקריפט להנאתכם Write-Host "Login to Azure..." -ForegroundColor Cyan $subscription = ( Get-AzureRmSu...

שלום רב והיום קצת על ארכיטקטורה ועל Load Balancing. איך עובד SQL Azure DataBase? בכל Data Center לכל בסיס נתונים יש 3 עותקים נסתרים, הם לא נגישים (רגע תכף תמתינו עד הסוף... :-) ), כאשר יש בעותק אחד בעיה ישנה פעולה שנקראת  Re configuration שהם מרימים עותק נוסף כדי שכל הזמן יהיו 3 עותקים בתוך אותו Data Center. אחלה, מעולה, אכן SLA  גבוה. כאשר עלה צורך לגופים בארגון לבצע קריאות רבות, או כשרציתי לאזן עומסים מהעותק הראשי בנינו עותק ב data center אחר, וכיוונתי לשם עומסים. הא מה? העותק הזה עולה כסף. העותק הנוסף חייב להיות ב Data Center אחר. לכן הוצג הפתרון הזה - מיקרוסופט ייתנו לנו אפשרות לקרוא מאחד העותקים בתוך אותו ה Data Center, וזה גם יהיה ללא עלות כי הוא כבר קיים. וגם זה לא ישפיע על העותק הראשי. כיצד זה מתבצע? הנה ההסבר המפורט: בודקים איזה tier בסיס הנתונים שלך במידה והוא Premium  שזה בשיטת ה DTU, או ב  Business Critical   שזה בשיטת ה V-Core, אם כן אז סבבה  יש לנו אישור להמשיך. מריצים סקריפט PowerShell שמאפשר לקרוא את העותק הרצו...

שלום לכולם בסוף 2016 הוצגה יכולת גיבוי של בסיסי הנתונים לטווחים ארוכים. אם המערכת נותנת בצורה אוטומטית גיבוי עד ל 35 יום, אם אתה צריך גיבוי לטווח זמן ארוך יותר צריך להגדיר את זה. בגרסתו החדשה הסרוויס יותר אינטואיטיבי - ונותן אפשרות גם למחוק גיבויים יותר ישנים וגם לשחזר בקלות מתוך גיבויים ישנים. כדי להגיע למקום בו מגדירים גיבויים ארוכי טווח יש לפנות למאמר זה המסביר די בפשטות כיצד מגבים ומשחזרים: https://azure.microsoft.com/en-us/blog/sql-database-long-term-backup-retention-preview-includes-major-updates/   מקום ניהול הגיבויים הינו ברמת השרת:        משם גולשים לחלונית שמציגה אפשרות להגדיר מערכת גיבויים  וחלונית המציגה אילו גיבויים יש שמתוכם אפשר לשחזר או למחוק את הגיבוי עצמו:   כאן יש רשימת בסיסי נתונים ומה מוגדר להם, האם גיבוי חודשי או שנתי או שבועי ולמשך כמה חודשים שנים ושבועות יהיה גיבוי   וכאן יש רשימה של גיבויים קיימים שמהם ניתן לשחזר גם ייתכן שיש לך בסיס נתונים שנמחק - והוא יופיע פה כי גיבית אותו.   ...

שלום לכולם אז כהשהכל התחיל אי שם ב 2010 הייתה אפשרות לבחור בין Web Edition Business Edition כאשר גריסה אחת הייתה מוגבלת במקום ויותר איטית והשניייה מהירה,(מי שזוכר את גרסאות אלו שיצביע :-)) זהו. ואז נכנס עולם של  Basic service tier Standard service tier Premium service tier לאחר זמן נכנס  PRS  service tier   (sorry to say but will be closed on 1.1.19) כאשר בעצם מדברים על  Tiers ארכיטקטורת החומרה היא שונה בין סוג לסוג. הדבר משיפע על זמני גיבויים, על עלויות, על רמות ביצועים שונות, SLA שונה, מיקום סטורג שונה ועוד. ועוד. (אחרי כן הוסיפו pools - אבל לא אדבר על זה כלל פה וגם לא על הייצור החדש הקרוי managed instance) במשך הזמן הוסיפו לכל סוג שכבה של גרסה שונה שמצביעות על כך שמאחרי הקלעים יש זיכרון שונה, ועוד. כאשר הכל נמדד במדד משוקלל שנקרא DTU. לכל סוג ולכל שכבה יש הגדרה של מקסימום DTU. וכך כאשר ה DTU הגיע ל 100 אחוז היית צריך לבדוק ולעשות אחת מכמה אפשרויות: * להעלות שכבה. * לתקן קוד. * לעשות תחזוקה ועוד. את...