SQL Azure for DBAs and Data Engineers

Hi All Last week we had an issue with a secondary DB in geo replication and fail over group. To make the long story short we had to delete the secondary and recreate a secondary from scratch . And now let me tell you the story, we build a DB in P6 tier - very high, expensive and highly available. Then we add a geo replication copy via the platform, like it shows here. This is take from MSFT documentation: https://docs.microsoft.com/en-us/azure/azure-sql/database/active-geo-replication-overview It is written:  " Both primary and secondary databases are required to have the same service tier. It is also strongly recommended that the secondary database is created with the same backup storage redundancy and compute size (DTUs or vCores) as the primary. If the primary database is experiencing a heavy write workload, a secondary with lower compute size may not be able to keep up with it. That will cause redo lag on the secondary, and potential unavailability of the secondary. To mit...

שלום לכולם כאשר מקנפגים Azure SQL DB מנוהל והוא תחת Premium or Business Critical Toers מיקרוסופט שואלים אותך: Would you like to make this database zone redundant? מה זו השאלה הזו? מה ההשפעה שלה ומה העלות שלה? אז עשינו ובדקנו מה ההשפעה. הלינק הבסיסי להסבר הקונפיגורציה הזו הוא זה: https://azure.microsoft.com/is-is/blog/azure-sql-database-now-offers-zone-redundant-premium-databases-and-elastic-pools/ מה זה אומר? זה מסביר על המושג הקריטי Availability Zones ועל השימוש שלו ב SLA של הדיבי שלנו. ובכן בכל דאטה סנטר בענן יש בעצם 3 דאטה סנטרים, הכל מנותק אחד מהשני. https://docs.microsoft.com/en-us/azure/availability-zones/az-overview לכל Azure SQL DB יש 3 עותקים ניסתרים, מיקרוסופט נותנת אופציה לשמור את אחד העותקים הניסתרים ב Availability Zone אחר. הדבר מעלה את ה SLA כך שאם יש תקלה ב Availability Zone אחד זה לא משפיע על ה DB. לכן אני ממליץ בחום לכולם לאפשר את הקונפיגורציה הזו.

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

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

שלום רב והיום לשם שינוי פוסט בעיברית. בתאריך 2015-02-19 כתבתי פוסט בנושא Geo-Replications Types in SQL Azure. http://www.sqlazure.co.il/2015/02/geo-replications-types-in-sql-azure.html שם הצגתי את 2  האפשרויות שקיימות ב Azure SQL בנושא זה: Standard Geo-Replication. Active Geo-Replication.  כאשר ההבדלים המרכזיים היו בתחום של Readable / NON Readable, מיקום הרפליקות ועוד. בתאריך 2015-11-23 הצגתי בפוסט נוסף את החידוש של Fail Over - כלומר שאפשר לשחק בין Primary and Secondary. http://www.sqlazure.co.il/2015/11/failover-in-sql-azure-db-with-geo.html והיום אציג את הצעד השלישי בהתפתחות עולם ה - DR ב SQL Azure. וזה מה שמעניין בענן - צריך חזון - ואז האפשרויות בלתי מוגבלות - ולנו המשתמשים הכל תלוי בעומק הכיס.... השינוי הכי מהותי לדעתי הוא זה: The performance objectives can be different between primary and secondary.   כלומר ניתן יהיה לעבוד עם קונפיגורציה כזו שה Primary יהיה בעלות למשל של S3, ואילו ה Secondary יהיה S0. וכך יורדו עלויות בצורה דרמטית. חייב...

Hi All   New feature was released lately - Fail Over in the Geo Replication in SQL Azure. The Announcement is here:   https://azure.microsoft.com/en-us/blog/spotlight-on-new-capabilities-of-azure-sql-database-geo-replication/   As You can see they added Failover feature. That means that until today you have Primary and Secondary DB's, DATA moved on one direction and you could disconnect the connection when ever you wish. but then you have to build everything from the beginning, (you can look in my old post about geo-replications types in sql azure). Now DATA moved backward, when you click Fail over - you still have 2 DB's but the Secondary become Primary and vise versa. I this this is a great feature. you can also read in Hebrew about it in Geri's Reshef Blog   http://blogs.microsoft.co.il/gerireshef/2015/11/23/%D7%90%D7%95%D7%A4%D7%A6%D7%99%D7%99%D7%AA-geo-replication-%D7%91-azure/   This is the new link   enjoy   ...

שלום לכולם וחורף נעים והיום דווקא לא על V12... היום על DR. ישנן 2 אפשרויות לרפלק את בסיסי הנתונים שלנו עבור DR: Standard Geo-replication Active Geo-replication לפני שאסביר בקצרה על ההבדלים - יש לשים לב שבכל רגע נתון אפשר לעצור רפליקציה ולשחרר את בסיס הנתונים המשני ובכך לאפשר  Fail Over. ההבדלים בין אפשרויות אלו מתחלקים לכמה נושאים והנה תקציר קצר שלהם: Standard Geo-replication Active Geo-replication Not Readable  Readable Azure choose the target location Any location you can choose Only 1 replication Up to 4 replications Fail Over rules by MSFT Manually failing over a database 75% of DB cost Full DB Cost מספר נקודות להבהרה: אי אפשר לבדוק בצורה אמיתית fail over כי בזמן הבדיקה בסיס הנתונים של הייצור - חשוף ללא dr. כי בזמן הניתוק יש בעיה. הרפליקציה היא א-סינכורנית. הפסקת רפליקציה יכולה להתבצע מהמאסטר או מהרפליקות - אם היא מתבצעת מהרפליקות היא מתבצעת מיי...