2018-11-08

AzureDiagnostics and AzureMetrics in SQL Azure DB

שלום רב
מיקרוסופט התקדמו מאד במתן האפשרויות ב 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 נשמר - רק קחו ונצלו אותו.

להלן מספר תמונות שממחישות

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

 
 
 
תמונה מספר 2 מציגה לנו את הגרף שעלה אחרי בחירת המדד -  אצלינו CPU.
 
 
 
תמונה מספר 3 מספרת לנו איך אנו מגדירים לשמור למחסנית הנתונים את ה AzureDiagnostics and AzureMetrics.
בוחרים פה ואז ניתן לבחור מה רוצים לשמור.



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


בתמונה מספר 5 ספרתי כמה דגימות לכל מדד.




תמונה מספר 6 מספרת את סיפורו של הקליק - בקליק אפשר להפוך את התוצאה לגרף ואפשר לראות יותר טוב מה קרה..



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


תמונה מספר 8 מספרת את סיפורו של הקליק 2 - גם פה בקליק אפשר לראות ברף מה יש ומא אין בתוצאות

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

ממליץ מאד לנשות ואם משהו לא ברור אנא שאלו.

2018-10-23

Azure SQL DB Changes Monitoring

שלום רב
מעקב אחרי שינויים בבסיס נתונים זה דבר בסיסי.
  • מי שינה קונפיגורציה של בסיס הנתונים ומתי.
  • מי עשה שינויים בסכמה או ב DATA ומתי.
  • מי שינה קונפיגורציה של השרת ומתי.
בקיצור הרבה מידע לדעת.
בשירות המנוהל SQL Azure DB , הקונפיגורציות הן ברמות שונות, יש ברמת של T-sql, יש ברמה של PowerShell
ויש פעולות שעושים בפורטל.

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

אז ככה:
יש ללכת ל RG של בסיס הנתונים ולגשת לספריה הקרויה Deployment.


 


פה רואים כל מה שקרה ב RG.
לדוגמא פה רואים שיש Deployment שבוא בביצוע כעת (יצירת רפליקה):
אפשר לראות שיש היסטוריה של שגיאות :

וכמובן מה השגיאה שארעה למשל פה הגענו לגבול ה TDU שבשרת הזה:

לעיתים אין הסבר לכישלון ואז רק רואים קוד שגיאה:



כשלוחצים על מה שכן הצליח רואים פרטים רבים:


זהו
עוד מידע לצבור - אולי נעשה עליו AI? :-)
יום נעים

2018-08-22

PowerShell to get Some DATA on ALL your Azure SQL DB's

שלום רב

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

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

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

אז הנה סקריפט בסיסי ממש - מוזמנים לשפר ולשתף עם הקהילה.

  1. ראשית עליכם לוודא שהמודולים של Azure מותקנים אצלכם (הרצה חד פעמית במחשב)
install-module -Name AzureRM -Force
  1. עושים לוגאין ליוזר שלכם ב Azure (חד פעמית בסשין)
Add-AzureRmAccount
  1. מריצים את הסקריפט להנאתכם
Write-Host "Login to Azure..." -ForegroundColor Cyan
$subscription = ( Get-AzureRmSubscription)
$subscriptionId = ( $subscription).SubscriptionId
$subscriptionName = ( $subscription).Name
foreach ($s in $subscription)
 
{



$c = Set-AzureRmContext -Subscriptionid $s.SubscriptionId
$a = Select-AzureRmSubscription -SubscriptionId $s.SubscriptionId
$ResourceGroup = @(Get-AzureRmResourceGroup)
foreach ($RG in $ResourceGroup)

{


$Sds = @(Get-AzureRmSqlServer -ResourceGroupName $RG.ResourceGroupName)
foreach ($SqlDatabaseServer in $Sds)

{


$databases = @(Get-AzureRmSqlDatabase -ResourceGroupName $RG.ResourceGroupName -ServerName $SqlDatabaseServer.ServerName | Where-Object {$_.DatabaseName -ne "master" })
foreach ($SqlDatabase in $databases)

{


Write-Host -Separator " " $s.Name $SqlDatabase.ServerName $SqlDatabase.DatabaseName $SqlDatabase.Location $SqlDatabase.CurrentServiceObjectiveName MAX:($SqlDatabase.MaxSizeBytes/1024/1024/1024)GB }



}

}

}
 

כמו שרואים מביא רשימה של כל מיני נתונים כמו מיקום בסיס הנתונים ועוד.


 
 
 

2018-07-03

Load Balance Read Operations in SQL Azure

שלום רב

והיום קצת על ארכיטקטורה ועל Load Balancing.

איך עובד SQL Azure DataBase?

בכל Data Center לכל בסיס נתונים יש 3 עותקים נסתרים, הם לא נגישים (רגע תכף תמתינו עד הסוף... :-) ), כאשר יש בעותק אחד בעיה ישנה פעולה שנקראת  Re configuration שהם מרימים עותק נוסף כדי שכל הזמן יהיו 3 עותקים בתוך אותו Data Center.
אחלה, מעולה, אכן SLA  גבוה.

כאשר עלה צורך לגופים בארגון לבצע קריאות רבות, או כשרציתי לאזן עומסים מהעותק הראשי בנינו עותק ב data center אחר, וכיוונתי לשם עומסים.
הא מה?
  1. העותק הזה עולה כסף.
  2. העותק הנוסף חייב להיות ב Data Center אחר.
לכן הוצג הפתרון הזה - מיקרוסופט ייתנו לנו אפשרות לקרוא מאחד העותקים בתוך אותו ה Data Center, וזה גם יהיה ללא עלות כי הוא כבר קיים. וגם זה לא ישפיע על העותק הראשי.

כיצד זה מתבצע? הנה ההסבר המפורט:
  1. בודקים איזה tier בסיס הנתונים שלך במידה והוא Premium שזה בשיטת ה DTU, או ב Business Critical  שזה בשיטת ה V-Core, אם כן אז סבבה  יש לנו אישור להמשיך.
  2. מריצים סקריפט PowerShell שמאפשר לקרוא את העותק הרצוי.
  3. מתחברים לבסיס הנתונים עם התוסף: ApplicationIntent=ReadOnly
  4. מוודאים שאתה בעותק של read only .
וזהו סעו ברכה, אחלה פיצר.
 
להלן סקריפט PS:

Login-AzureRmAccount;
 
Select-AzureRmSubscription -SubscriptionName "MySubscriptionName" 

Set-AzureRmSqlDatabase -ResourceGroupName 'MyRGName' -ServerName 'MyServeName' -DatabaseName 'MyDBName' -ReadScale Enabled

 

 



 
מי שרוצה להתחבר מ SSMS מוזמן לעשות את זה ככה:



עכשיו צריך לוודא שאתה בעותק הנכון:


SELECT DATABASEPROPERTYEX(DB_NAME(), 'Updateability'),DB_NAME(),@@SERVERNAME


 
הנה ב SSMS רואים שחיבור אחד הוא לעותק ה Read only.

ועכשיו לבדיקה עצמה:
מריץ שאילתא כבדה על העותק של הקריאה כתיבה והנה קופץ בפורטל הDTU.


ואם אני מריץ את אותה שאילתא על העותק ה Read Only, אין קפיצה ב DTU.



שימו לב אין שום GUI שמחובר לעותק ה Read Only.
והנה לינק לתעוד:

שאפו לרן עובדיה שסייע לי במציאת הפתרון.

נסו ותהנו.
יום נעים

 

 

2018-05-29

Long-term backup retention in SQL Azure DataBase

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

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

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

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

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


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


 
הפשטות פה היא ממש יפה.
 
השלב הבא אולי לראות את זה ב SSMS.
GDPR - כבר אמרנו?
 
 

2018-04-25

SQL Azure: DTU vs vCore

שלום לכולם

אז כהשהכל התחיל אי שם ב 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 אחוז היית צריך לבדוק ולעשות אחת מכמה אפשרויות:
* להעלות שכבה.
* לתקן קוד.
* לעשות תחזוקה ועוד.

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

ואז נולד הדור הבא המבוסס על vCore
שיטת בניה של מכונות המורכבות מ 2 tiers:

General Purpose service tier

Business Critical service tier

כאשר בכל Tier כרגע יש 5 סוגי מכונות 
GP_Gen4_1
GP_Gen4_2
GP_Gen4_4
GP_Gen4_8
GP_Gen4_16
ומיקרוסופט מתחילים ממה שנקרא דור 4 של המכונות כלומר קומבינציה של 
IOPS, RAM, Storage
שמנוהל לפי המכונה. בטח בהמשך יהיה דור חמש וכדומה.
פה בניגוד לשיטה הקודמת יש פירוט כמה זיכרון יש בכל מכונה והיכן ממוקם הסטורג' ולכמה iops היא אמורה לענות.
את ההבדלים ברמות ניתן לקרוא פה:

אם עד היום היינו עיוורים וניחשנו לפי ביצועים שמדדנו.
היום נעבור למדידה מדוייקת ולצורך מדוייק יותר
סתם כדוגמא - GP_Gen4_16  -  112 GB Ram
ועכשיו בקשר לתימחור:
מכונות חזקות אמורות להיות יותר זולות בשיטה החדשה, מכונות חלשות אמורות להיות יותר יקרות בשיטה החדשה.
שכל אחד יעשה את השיקול שלו.

עוד על התיעוד ועל ההבדלים ניתן לקרוא פה:

וזו התמונה המייצגת את ההבדלים:



להלן כמה הנחיות כיצד להגיע לזה:
ניגשים למסך בחירת ה tier - המסך הרגיל:


בוחרים את ה vCore.

וזה המסך המודבר:
1. סוג השימוש - משפיע על סוג סטורג' ו SLA וכמובן מחיר.
2. כרגע ניתן לבחור רק gen4. בהמשך יהיהו עוד.
3. מסך קטן של חיזוב עלויות לפי סטורג ולפי סוג המכונה.
4. פה אפשר להביר רשיון מה on prem - למשל עשית מיגרציה על מכונה שאתה משלם עליה - אתה יכול להעביר רשיון וזה יחסוך עלויות.
5. העלאת והורדת סוג המכונה  בתוך דור 4.
6. הגדלת סטורג' למשל חצי טרה בסוג הזה שווה 70 דולר.
7. הגדרה של כמה ימי גיובי יש לפי הבחירה שלך.


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

ימים יגידו אם וכאשר ישתמשו בזה.
זמין לשאלות.
פיני











2018-02-27

How to choose your AZURE Data Center

שלום רב והיום מעט על Data Centers בענן של מיקרוסופט.
לפני שאסביר איך מומלץ לבחור את הדאטה סנטר שלך שבתוכו תשים את כל האפליקציות  והנתונים בענן, אסביר מספר מושגים שקשורים לקבלת ההחלטה.
Regoin - למיקרוסופט מספר רב של דאטה סנטרים, הם מאחדים אותם תחת אזורים. בתוך אזורים יש תקשורת טובה יותר ומומלץ לעבוד בכמה דאטה סנטרים תחת אותו אזור. למשל באירופה יש כמה אזורים - UK - יש לה 2 אישורים לונדון וקרדיף. אירופה יש לה צפון ומערב והם זוגות.
Government - אלו דאטה סנטרים בארה"ב שעומדים תחת רגולצית ממשל אמריקאית, יש שם מנגנוני אבטחה מוגברים לפי הצרכים של הממשל האמריקאי.
German - גם פה ישנם צרכים לממשל גרמני, ולכן פתחו מיקרוסוםט דאטה סנטרים בגרמניה.
חשוב להבין שלא כל הדאטה סנטרים של מיקרוסופט הם בניהולם - לעיתים, כמו בגרמניה הם רוכשים שירותים מקומיים. כך גם בסין.
מפת הפריסה של הדאטה סנטרים היא זו נכון להיום:


כשניגשים לבחירת data center צריך לקחת כמה דברים בחשבון:
Latency, Service Availability, Compliance, 

Latency - רכיב מאד משמעותי. היכן המשתמשים של האפליקציה או הנתונים נמצאים? האם אתם עובדים היברידי? ואז יש חשיבות למעבר נתונים. יש 2 אתרים שנותנים בדיקה של Latency מהדאטה סנטרים השונים:
פה אפשר לראות מה רואים לכל דאטה סנטר באירופה מה העיכוב שיש ממכונה בישראל:



פה גם רואים לפי דאטה סנטר :

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

למשל בטבלה המצולמת אין MySQL PAAS בחלק האיזורים בארה"ב.

Compliance - נקודה מאד חשובה, למשל האם מותר לשמור נתונים באיזור מחוץ לאירופה ללקוחות אירופאים וכדומה, חייבים לקחת זאת מראש.

זהו אילו עיקרי הדברים יקרא כל אחד ויחליט כטוב בעיניו.