SQL Azure for DBAs and Data Engineers

בפרק זה נבחן כיצד בודקים ביצועים ב SQL Azure. מה ניתן ומה לא ניתן לבצע עליו. אם ב SQL Server בצורה רגילה אנו יכולים להשפיע על ביצועים ב - 2 אופנים: 1. שיפור שאילתות ושיפור אינדקסים 2. שיפור חומרה - למשל כתיבת לוגים ל Raid 10  או הגדלת CPU וכדומה הרי ב SQLAzure מכיוון שאין לנו יכולת שליטה על החומרה אנו חייבים להתמקד אך ורק בשיפור ברמת התוכנה, כשניצפה בעיות של IO עלינו להתמקד בניתוח השאילתא הבעייתית.

הידעתם? ( ככה מספרים לנו) הידעתם כי מאחורי בסיס הנתונים שלנו עומדים 3 בסיסי נתונים מרופלקים מבסיס הנתונים שלנו? המטרה לבטח את ההבטחה של מיקרוסופט ל 99.9% של נגישות וזמינות ( availability – נשמע יותר יפה באנגלית הא?) לבסיס הנתונים שלנו (גם פה יש המון המון חומר ברשת והרחבות טכניות וכלליות – אני מביא רק תקציר של התקציר כדי לתת ידע בסיסי – מי שרוצה יותר פרטים יכול לפנות אליי או לקרוא לבד...) רפליקציה אחת נקראת primary והאחרות נקראות secondary , איך זה עובד? ה קריאות והכתיבות מרופלקים לבסיס הראשי ובצורה א-סינכרונית אז זה עובר ל 2 האחרים המשניים, במידה ורפליקציה אחת נופלת – מייד מתרוממת אחת חליפית הנקראית - 'reconfiguration' . היכן שוכנות רפליקציות אלו? הן שוכנות בסרברים פיזיים (לא וירטואליים) אחרים, למה זה ככה? נאמר ייפול השרת שבו יושב בסיס הנתונים המרופלק הקרוי primary , מיד יש 2 אחרים בשרתים חיים אחרים (לדעתם הסבירות שייפלו 3 זו סבירות נמוכה מאד). בארכיטקטורה כזו מתי נחשב מידע כ committed ב SQL Azure שלנו בבסיס הנתונים שלנו? הארכיטקטורה שלהם קבעה כי מידע נחשב כ committed ...

בפוסט זה נדון מהו תפקידו של ה  DBA ב  SQL Azure, מה הוא יכול לבצע ומה לא בניגוד ל SQL Server רגיל: כידוע אחד הדברים המרכזיים בניהול SQL Server הינו מתן הרשאות ליוזרים LOGIN's. על פי כל הכללים הנהוגים - יוזרים שמבצעים עידכונים, יוזרים שמבצעים שאילתות וכדומה. ב SQL Azure ישנה רמה אחת של משתמשים - יוזר - מקימים אותו והוא רשאי לבצע הכל. ישנן 2 דרכים ליצור משתמשים: 1. דרך הפורטל 2. דרך פקודת SQL