SQL Azure for DBAs and Data Engineers

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

שלום לכולם אכן הרבה זמן לא כתבתי, אשתדל לחזור לעצבי בקרוב. והיום בקצרה על ניהול טבלאות temporal. בקצרה ב SQL Server - החלו להשתמש ברעיון של שמירה אוטמטית של שינויים בנתונים בטבלה. ואפשר לתשאל גם את הטבלה ההיסטורית וגם את הנוכחית בשליפה אחת: https://docs.microsoft.com/en-us/sql/relational-databases/tables/querying-data-in-a-system-versioned-temporal-table /*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. יש אפשרות להגדיר כמה זמן יישמר המידע בטבלת היסטוריה. כאשר יש סרביס מאחורה שרץ ומוחק מה שצריך ללא עומס מיוחד בבסיס הנתונים - לא הצלחתי להבין היכן זה רץ ומה חלונות הזמן שלהם. הגדרה זו ה...

שלום רב עד לפני זמן 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  

שלום רב לכבוד סיום החופש מיקרוסופט מפנקים אותנו ברמות ביצועים חדשות ב 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 על זה אנסה בקרוב לתת הסבר מפורט. להלן לינק ההכרזה: https://azure.microsoft.com/en-us/blog/new-performance-levels-and-storage-add-ons-in-azure-sql-database/ להלן מספר תמונות מהפורטל ומהמחשבון:   ככה החלוקה ניראית מהמחשבון    ככה זה נראה בפורטל ב שתי קומבנציות  

Hi Very good Summary and Overview about current features of SQL Azure DB:   https://docs.microsoft.com/en-us/azure/sql-database/sql-database-technical-overview    

שלום רב והיום על תחום 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...

אני אוהב לאחד חידושים. כאשר יצא SQLServer 2014 יצא גם DMV חדש dm_exec_query_profiles זה נתן לנו יכולת לעקוב אחרי התקדמות פעילויות כמו יצירת אינדקס או Rebuild. להלן לינק נחמד מאד שמסביר את זה   CREATE INDEX Monitoring Progress   יש מספר סקריפטים שמראים כיצד להשתמש ולראות את התקדמות הבניה של האינדקס למשל:     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 גבוה מאד מריץ את מה שצריך להריץ - יודע בדיוק מתי זה ייגמר באמצעות שאילתא זו ואז מו...