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 - נקודה מאד חשובה, למשל האם מותר לשמור נתונים באיזור מחוץ לאירופה ללקוחות אירופאים וכדומה, חייבים לקחת זאת מראש.

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









2018-02-06

RETENTION on Temporal Tables

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


/*State of entire table AS OF specific date in the past*/ SELECT [DeptID], [DeptName], [SysStartTime],[SysEndTime] FROM [dbo].[Department] FOR SYSTEM_TIME AS OF '2015-09-01 T10:00:00.7230011' ;

אחת הבעיות זה ניהול הטבלה ההיסטורית אי אפשר למחוק ממנה בצורה רגילה - ואצלי ב SQL Azure הדבר נהיה משמעותי עקב מגבלת הגודל.

לכן עלינו על נושא ה RETENTION שזה פיצ'ר מדהים שניתן בכל SQL Server ולהפתעתי גם ב SQL Azure.
יש אפשרות להגדיר כמה זמן יישמר המידע בטבלת היסטוריה.

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

הגדרה זו היא בשתי רמות, ברמת בסיס הנתונים שב Azure אתה מריץ את זה ב master.

--on master DB
ALTER DATABASE MyDB SET temporal_history_retention ON  

ואז ברמת הטבלה כולל הגדרה מה הזמן שאתה רוצה שיישמר

--on db
ALTER TABLE [MyDB ].[MyTable] 
SET (SYSTEM_VERSIONING = ON (HISTORY_RETENTION_PERIOD = 1 WEEK));

או שזה מוגדר לשמור לתמיד ככה:
--on db
ALTER TABLE [MyDB ].[MyTable] 
SET (SYSTEM_VERSIONING = ON (HISTORY_RETENTION_PERIOD = INFINITE));

ואז זה עובד כמו שאומרים - פצצות.

כדי לראות מה מוגדר לך לכל טבלה זו השאילתא:

SELECT DB.is_temporal_history_retention_enabled,
SCHEMA_NAME(T1.schema_id) AS TemporalTableSchema,
T1.name as TemporalTableName,  SCHEMA_NAME(T2.schema_id) AS HistoryTableSchema,
T2.name as HistoryTableName,T1.history_retention_period,
T1.history_retention_period_unit_desc
FROM sys.tables T1  
OUTER APPLY (select is_temporal_history_retention_enabled from sys.databases
where name = DB_NAME()) AS DB
LEFT JOIN sys.tables T2   
ON T1.history_table_id = T2.object_id WHERE T1.temporal_type = 2


2017-10-19

DBCC CHECKDB on SQL Azure to do or not to do?

שלום רב
עד לפני זמן DBCC CHECKDB  לא היה יכול לרוץ על SQL Azure .
לפני מעל שנה איפשרו את זה, ואז עלתה השאלה - להריץ או לא להריץ?
הרי ממילא גם אם נגלה דברים חצי מסוגי הפתרונות לא נוכל לעשות- אין restore . רגיל.
כשבדקתי את זה על SQL Azure - עלה שבכל הרצה ובכל tier - זה העלה את ניצול המשאבים של בסיס הנתונים ל 100%.לכן בזמנו החלטתי לא להריץ וחשבתי וקיוותי שמיקרוסופט עושים עבורנו את העבודה - הלא זהו שירות PAAS?

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

הלינק של הבלוגר החביב ששמו הוא Arun Sirpal, בו הוא מתאר את מה שתיארתי עכשיו :-):

https://blobeater.blog/2017/09/04/dbcc-checkdb-azure-sql-database/

זהו הלינק למאמר מבית היוצר של מיקרוסופט שמתארים מה הם עושים ומה הם מריצים - מאמר מאד חשוב וקריטי למי שיש לו Prodaction on SQL Azure.

How we manage data integrity for Azure SQL Database



 

2017-08-31

New performance levels and Pricing in SQL Azure SQL DB

שלום רב
לכבוד סיום החופש מיקרוסופט מפנקים אותנו ברמות ביצועים חדשות ב SQL Azure ב Standard tier.
נוספו S4,S6,S7,S9,S12.
כאשר מעבר לרמות הללו הוסיפו נידבח על עולם התימחור.
כאשר עד היום הינו משלמים על הכול כלומר כוח חישובי וכן על Storage, עכשיו הוסיפו אפשרות להוסיף עד 1 TB, כאשר כל GB מעל 250 ב Standard ומעל 500 ב Premium וב PremiumRS נשלם עליו.
21 $ לחודש ב Standard, וב Premium & PremiumRS נשלם על כל 250 GB 43 $.
הדבר כבר ניתמך בפורטל.

לא ארחיב כאן מתי עדיף להשתמש ב Standard or Premium על זה אנסה בקרוב לתת הסבר מפורט.

להלן לינק ההכרזה:
להלן מספר תמונות מהפורטל ומהמחשבון:
 
ככה החלוקה ניראית מהמחשבון

 
ככה זה נראה בפורטל ב שתי קומבנציות


 

2017-06-12

FailOver Groups in SQL Azure DB

שלום רב
והיום על תחום DR.
יש כבר זמן רב את היכולת ליצור Geo-Repliation.
בקצרה זוהי יכולת ליצור בזריזות עותק של בסיס הנתונים באיזור אחר, הוא יושב בשרת אחר ואפשר לעשות אליו Fail over אולם כל הקשור לשמות, המערכת הזו סטטית. כלומר שמות לא עוברים ואתה צריך לקנפג בקוננקשין סטרינג שאת הכתיבות אתה מבצע לבסיס נתונים אחד וכשמתבצע fail over אתה עובר לכתיבה לקוננקשין סטרינג אחר.
כל זה נכון אם אתה ביצעת את ה fail over. אולם אם מיקרוסופט ביצעה את ה fail over השמות כן מתחלפים לטענתה.

לאחרונה היתווספה היכולת לבצע fail over ואתה כלקוח לא תצטרך לשנות קוננקשין סטרינג.
הרעיון הוא פשוט
  • יוצרים Fail over Group.
  • קובעים לה שם
  • מחברים לקבוצה הזו כמה בסיסי נתונים שרוצים.
  • מקנפגים איך יתבצע ה Fail Over וכמה זמן אחרי נפילה יתבצע אם זה אוטמטי.
מיקום מסך יצירת Fail Over Groups:



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



זהו עכשיו יש קבוצה עם 2  URL להתחברות לדוגמא:

fonrtest1.database.windows.net - to the Primary

עכשיו ביצעתי Fail over ומה שקרה ששתי הכתובות מפנות למה שהיה קודם secondary.
כלומר שינוי הכתובת עובד רק על הראשון, זה לא מושלם אבל זו התחלה!!


ככה נראה מסך של Fail over groups מול מסך של geo replication  רגיל:





הנה 2 לינקים בנושא:


המפתחים שלי התחילו לאהוב את זה.
 

2017-05-21

SQL Azure DB and include live query statistics

אני אוהב לאחד חידושים.
כאשר יצא SQLServer 2014
יצא גם DMV חדש
dm_exec_query_profiles
זה נתן לנו יכולת לעקוב אחרי התקדמות פעילויות כמו יצירת אינדקס או
Rebuild.
להלן לינק נחמד מאד שמסביר את זה
 
 
יש מספר סקריפטים שמראים כיצד להשתמש ולראות את התקדמות הבניה של האינדקס למשל:
 
 
SELECT
node_id,
physical_operator_name,
SUM(row_count) row_count,
SUM(estimate_row_count) AS estimate_row_count,
CAST(SUM(row_count)*100 AS float)/SUM(estimate_row_count) as estimate_percent_complete
FROM sys.dm_exec_query_profiles
WHERE session_id=@SPID 
GROUP BY node_id,physical_operator_name
ORDER BY node_id desc;
 
ב SQL Azure אני משתמש בו לעיתים תכופות - אולם פה אני מנצל את היכולת של ה PAAS, אני מעלה ל
Tielr גבוה מאד מריץ את מה שצריך להריץ - יודע בדיוק מתי זה ייגמר באמצעות שאילתא זו
ואז מוריד את ה Tier חזרה.
 
כמו שאמרתי אני משלב 2 חידושים - ה DMV והיכולת להעלות Tier ולהריץ דברים מאד מהר.
 
יש לציין שכרגע הסקריפט ירוץ או כאשר מדליקים ברמת הסשין דגל כלשהוא או שאני לוחץ על
"include live query statistics"
 
 

 
 
 
זהו לבנתיים
תנצלו את החידוש הזה
יום נעים

2017-03-09

New Service tier in SQL Azure called "Premium RS"

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

הלינק להכרזה:
https://azure.microsoft.com/en-us/blog/sql-database-4tb-premium-and-premium-rs-preview/
  1. מוסיפים שכבת ביצועים חדשה Premium RS - יש פה חידוש משמעותי בכך שהם אומרים ניתן לכם מכונה עם ביצועים טובים מאד - נוריד מחיר וה SLA יהיה יותר נמוך כלומר הם ירפלקו בפחות מכונות והעליה לאחר בעיה יכולה לקחת כמה דקות... כמובן גם יש Column store  וגם יש InMemory.....אתם הבנתם את זה? סוף סוף מכונות חזקות - זולות ושהן לא פרודקשין ויש לי כאלו למכביר.....
  2. אפשרות של הרחבה עד ל 4TB של בסיס נתונים - כאן יש עקיצה - כי מדובר רק ברמות היקרות מאד - אולם זה מראה על הכיוון שחיובי של מתן אפשרות של בסיסי נתונים מעל 250-500 GB.

מצורפים לינקים להגדרות של Tiers החדשים:

https://docs.microsoft.com/en-us/azure/sql-database/sql-database-service-tiers

המחירים הם טובים מאד:



שימו לב שזה יותר טוב מהרבה הגבוהה של Standard וזה על דיסקים מהירים...
הידד

עוד דוגמא להבדלים: