מדריך

מסד נתונים SQL קריטי למשימה דורש SLA של 99.995%, זמינות גבוהה בעלת יתירות אזורית, ויכולות הרחבת קריאה.

→פרוס Azure SQL Database באמצעות רמת השירות Business Critical עם זמינות אזורית מופעלת.

למה: Business Critical מספק את ה-SLA הגבוה ביותר, משתמש בכונני SSD מקומיים עבור זמן אחזור נמוך, וכולל עותקים משניים קריאים מובנים ללא עלות נוספת. General Purpose בעל SLA נמוך יותר וללא עותקי קריאה מובנים.

מקור↗

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

→פרוס Azure SQL Database באמצעות רמת General Purpose עם מודל המחשוב Serverless.

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

מקור↗

העברת SQL Server מקומי המסתמך במידה רבה על תכונות כמו SQL Server Agent, שאילתות בין מסדי נתונים, ו-Service Broker.

→העבר ל-Azure SQL Managed Instance.

למה: Managed Instance מציע תאימות כמעט 100% ל-SQL Server מקומי, ושומר על תכונות ברמת המופע שאינן זמינות ב-Azure SQL Database.

מקור↗

יישום דורש גישה ברמת מערכת ההפעלה, גישה למערכת קבצים (לדוגמה, עבור Filestream), או תכונות שאינן נתמכות על ידי הצעות PaaS כמו CLR עם EXTERNAL_ACCESS.

→פרוס SQL Server במכונה וירטואלית של Azure (IaaS).

למה: IaaS מספק שליטה מלאה על מערכת ההפעלה ומופע SQL Server, ומציע תאימות מרבית לתצורות מקומיות במחיר של תקורה ניהולית מוגברת.

מסד נתונים צפוי לגדול מעבר ל-4 TB, עד 100 TB, ודורש הרחבת אחסון מהירה ושחזורים מהירים.

→פרוס Azure SQL Database באמצעות רמת השירות Hyperscale.

למה: Hyperscale מיועד למסדי נתונים גדולים מאוד (VLDBs), ומציע עד 100 TB של אחסון המתרחב אוטומטית. הוא משתמש בארכיטקטורה ייחודית עם שרתי עמודים לשחזורי מסד נתונים מהירים, בזמן קבוע, ללא קשר לגודל.

מקור↗

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

→קבץ את מסדי הנתונים ל-Azure SQL Database elastic pool.

למה: Elastic pools מאפשרים למסדי נתונים מרובים לחלוק קבוצת משאבים (eDTUs או vCores) במחיר קבוע, דבר שחסכוני יותר מאשר הקצאת מסדי נתונים בודדים כאשר השימוש אינו קבוע על פני כל הדיירים.

פריסת Azure SQL Managed Instance לרשת וירטואלית.

→צור תת-רשת ייעודית בגודל מינימלי של /27 (32 כתובות) והאצל אותה ל-Microsoft.Sql/managedInstances.

למה: Managed Instance דורש תת-רשת ייעודית וריקה עם מספיק כתובות IP עבור רכיביו הפנימיים והרחבה עתידית. /27 הוא הגודל המינימלי הנתמך.

העברת מסד נתונים גדול וקריטי למשימה של SQL Server מקומי ל-Azure עם זמן השבתה מינימלי.

→השתמש ב-Azure Database Migration Service (DMS) במצב העברה מקוון.

למה: העברת DMS מקוונת מבצעת טעינה ראשונית ולאחר מכן משתמשת בסנכרון נתונים רציף (log shipping) כדי לשמור על היעד מסונכרן, מה שמאפשר חלון מעבר קצר מאוד.

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

→השתמש ב-Premium SSDs. הגדר Read-only host caching עבור קבצי נתונים ו-None עבור קבצי יומן.

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

מדיניות אבטחה דורשת שכל חיבורי מסד הנתונים יהיו מוצפנים ויאמתו את אישור השרת.

→הגדר את גרסת ה-TLS המינימלית ל-1.2 בשרת. במחרוזות חיבור לקוח, השתמש ב-'Encrypt=Strict'.

למה: הגדרת TLS מינימלי בשרת מונעת משא ומתן פרוטוקולי לא מאובטח. 'Encrypt=Strict' (TDS 8.0+) אוכף הצפנה ואימות אישור מלא, ומונע התקפות man-in-the-middle.

נתונים רגישים בעמודות ספציפיות (לדוגמה, SSN) חייבים להיות מוצפנים, אך היישום צריך לבצע חיפושי שוויון וצירופים על הנתונים המוצפנים.

→השתמש ב-Always Encrypted עם הצפנה דטרמיניסטית עבור העמודות הניתנות לחיפוש.

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

הצפנת נתונים במנוחה נדרשת, אך הארגון חייב לשמור על שליטה מלאה במפתחות ההצפנה.

→אפשר Transparent Data Encryption (TDE) עם מפתחות בניהול לקוח (BYOK) המאוחסנים ב-Azure Key Vault.

למה: תצורה זו מאפשרת לארגון לנהל את מחזור חיי המפתח (סיבוב, ביטול) ב-Key Vault שלו, ומספקת שליטה ועמידה בדרישות תאימות לבעלות על מפתחות.

Azure SQL Database חייב להיות נגיש רק מרשת וירטואלית ספציפית של Azure, כאשר גישת האינטרנט הציבורית חסומה לחלוטין.

→הגדר Private Endpoint עבור SQL Server וקבע "Deny public network access" ל-"Yes".

למה: Private Endpoint נותן למסד הנתונים של SQL כתובת IP פרטית בתוך ה-VNet שלך. השבתת גישה ציבורית מבטיחה שזו הדרך היחידה להתחבר, ומספקת בידוד רשת מוחלט.

יישום מרובה דיירים חייב להבטיח שמשתמשים יוכלו לראות רק את הנתונים שלהם בתוך טבלה משותפת.

→יישם Row-Level Security (RLS) על ידי יצירת פרדיקט אבטחה (פונקציה מובנית בעלת ערך טבלאי) ומדיניות אבטחה המיישמת אותו על הטבלה.

למה: RLS מסנן שורות באופן שקוף בהתבסס על הקשר המשתמש (לדוגמה, USER_NAME() או SESSION_CONTEXT), אוכף בידוד נתונים ברמת מנוע מסד הנתונים ללא שינויים ביישום.

מנהלי מסדי נתונים צריכים לנהל את מסד הנתונים אך אסור להם לצפות בנתונים רגישים בעמודות מסוימות.

→יישם Dynamic Data Masking (DDM) על העמודות הרגישות. אל תעניק הרשאת UNMASK ל-DBAs.

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

מדיניות אבטחה מחייבת השבתת אימות SQL כדי לאכוף ניהול זהויות מרכזי ו-MFA עבור Azure SQL DB או Managed Instance.

→הגדר מנהל Azure AD עבור השרת ואפשר את המאפיין "Azure AD-only authentication".

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

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

→אפשר את Microsoft Defender for SQL (לשעבר Advanced Threat Protection).

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

יומני ביקורת עבור Azure SQL Database חייבים להישמר למשך מספר שנים ולהיות ניתנים לחיפוש לצורך תאימות וחקירות אבטחה.

→הגדר Azure SQL Auditing לשלוח יומנים לסביבת עבודה של Log Analytics עם שמירת הנתונים הנדרשת מוגדרת.

למה: Log Analytics מספק שמירה לטווח ארוך ויכולות שאילתה עוצמתיות מבוססות KQL, מה שהופך אותו לעדיף על Blob Storage עבור נתוני ביקורת ניתנים לחיפוש ולטווח ארוך.

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

→השתמש ב-Azure AD Privileged Identity Management (PIM) כדי לנהל זכאות עבור קבוצת Azure AD שיש לה גישה למסד הנתונים.

למה: PIM מספק גישה בזמן אמת (JIT) הניתנת לביקורת, דורשת הצדקה, ופגה אוטומטית, תוך שמירה על עקרון הפריבילגיה המינימלית.

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

→השתמש בתכונת ה-ledger של Azure SQL Database.

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

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

→אפשר והשתמש ב-Query Store.

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

מקור↗

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

→השתמש ב-Query Store כדי לזהות את התוכניות השונות ולאכוף את תוכנית הביצוע הטובה באופן עקבי.

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

לשפר את ביצועי השאילתות ללא שינויי קוד על ידי ניצול תכונות כמו batch mode on rowstore, memory grant feedback, ו-table variable deferred compilation.

→הגדר את רמת התאימות של מסד הנתונים ל-150 (עבור תכונות SQL 2019) או גבוה יותר.

למה: סט התכונות של Intelligent Query Processing (IQP) מופעל על ידי רמת התאימות של מסד הנתונים. רמה 150+ מפעילה מגוון רחב של שיפורי ביצועים "ללא שינוי קוד" במעבד השאילתות.

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

→השתמש ב-Azure Monitor ליצירת התראות מדדים (עבור CPU) והתראות יומן (עבור deadlocks) המפעילות Action Group.

למה: Azure Monitor היא הפלטפורמה המרכזית לניטור והתראות על משאבי Azure. Action Groups מספקים ערוצי התראות גמישים (דוא"ל, SMS, webhook וכו').

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

→בצע שאילתה ל-sys.dm_db_index_usage_stats DMV.

למה: DMV זה עוקב אחר שימוש באינדקס (seeks, scans, lookups) לעומת עדכונים. אינדקסים עם עדכונים רבים אך שימוש אפס או נמוך מאוד הם מועמדים עיקריים להסרה, מה שמפחית את תקורת התחזוקה.

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

→הגדר סשן Extended Events הלוכד את האירוע blocked_process_report.

למה: אירוע זה מספק דוח XML מפורט של שרשראות חסימה כאשר סף התהליך החסום נחצה, ומציע מידע אבחוני עמוק שאינו זמין ב-DMVs.

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

→אפשר את האפשרות CREATE_INDEX ב-Azure SQL Database Automatic tuning.

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

העבר עומסי עבודה של דוחות עתירי קריאה ממסד הנתונים הראשי של OLTP ברמת Business Critical או Premium.

→שנה את מחרוזות החיבור לקריאה בלבד של היישום לכלול 'ApplicationIntent=ReadOnly'.

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

טבלת עובדות גדולה במחסן נתונים משמשת לעיתים קרובות לשאילתות אגרגציה (SUM, COUNT, AVG) המבצעות לאט.

→צור אינדקס columnstore מקובץ על טבלת העובדות.

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

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

→אפשר Read Committed Snapshot Isolation (RCSI) במסד הנתונים.

למה: RCSI משתמש בגרסאות שורות, ומאפשר לקוראים לראות את הגרסה האחרונה המאושרת של הנתונים מבלי לקחת נעילות משותפות, ובכך מבטל חסימות מכותבים. כותבים אינם חוסמים קוראים.

יישום המשתמש במסד נתונים Serverless חווה זמני חיבור איטיים ראשוניים לאחר תקופה של חוסר פעילות.

→הפחת את השהיית העצירה האוטומטית או הגדר ערך vCore מינימלי גדול מאפס.

למה: העיכוב נגרם כתוצאה מהתחדשות מסד הנתונים ממצב מושהה (cold start). הגדרת ערך vCore מינימלי מונעת ממסד הנתונים לעצור לחלוטין, ומבטלת זמן אחזור של חידוש במחיר של חיוב מחשוב רציף מסוים.

יישם צינור CI/CD לפריסות סכימת מסד נתונים אוטומטיות, מבוקרות גרסאות וניתנות לשחזור.

→השתמש בפרויקט SQL Database (לדוגמה, ב-Visual Studio) ליצירת קובץ DACPAC. השתמש בצינורות Azure DevOps לפריסת ה-DACPAC.

למה: זהו דפוס Infrastructure as Code (IaC) הסטנדרטי עבור סכימת SQL. ה-DACPAC הוא מודל דקלרטיבי של הסכימה, וכלי הפריסה מטפלים ביצירת הסקריפט הדיפרנציאלי, ומבטיחים עקביות.

Azure SQL Database צריך להתרחב או להצטמצם אוטומטית בהתבסס על לוח זמנים או ספי מדדים (לדוגמה, CPU גבוה).

→השתמש ב-Azure Automation runbook (PowerShell) המופעל על ידי לוח זמנים או התראת Azure Monitor.

למה: ל-Azure SQL Database (Provisioned tier) אין autoscaling מובנה. Azure Automation הוא הכלי הסטנדרטי לתזמור סוג זה של משימה תפעולית באמצעות סקריפטים ולוחות זמנים.

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

→השתמש ב-Elastic Jobs.

למה: Elastic Jobs הוא שירות PaaS שתוכנן במיוחד להפעלת משימות T-SQL על פני קבוצת יעד של מסדי נתונים, וניהול אישורים, תזמון ורישום באופן מרכזי.

ודא שלכל שרתי Azure SQL שנוצרו חדש במנוי תהיה תכונה ספציפית, כמו TDE או Auditing, מופעלת כברירת מחדל.

→צור Azure Policy עם אפקט 'DeployIfNotExists' או 'Modify'.

למה: Azure Policy מספקת ממשל בקנה מידה רחב. אפקט 'DeployIfNotExists' יגדיר אוטומטית את ההגדרה החסרה במהלך יצירת המשאב, ויאכוף תאימות ללא התערבות ידנית.

תזמן סקריפט T-SQL חוזר או משימת תחזוקה ב-Azure SQL Managed Instance.

→השתמש ב-SQL Server Agent המובנה.

למה: Managed Instance כולל את SQL Server Agent המלא, ומספק את אותן יכולות תזמון משימות מוכרות כמו ב-SQL Server מקומי ללא צורך בשירות אוטומציה חיצוני.

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

→הגדר Maintenance Window עבור המשאב.

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

יישום דורש מעבר אוטומטי (failover) לאזור משני לצורך התאוששות מאסון, ללא צורך בשינויים במחרוזת החיבור.

→הגדר Auto-Failover Group בין מסדי הנתונים/מופעים הראשיים והמשניים.

למה: קבוצות Failover מספקות נקודות קצה של מאזין לקריאה-כתיבה ולקריאה בלבד. נקודות קצה אלו מנתבות אוטומטית תעבורה לשרת הראשי/משני הנוכחי לאחר failover, מה שהופך את התהליך לשקוף ליישום.

גיבויי מסד נתונים חייבים להישמר למשך שנים רבות (לדוגמה, 7-10 שנים) כדי לעמוד בדרישות תאימות משפטיות או רגולטוריות.

→הגדר מדיניות Long-Term Backup Retention (LTR).

למה: גיבויי Point-in-Time Restore (PITR) סטנדרטיים נשמרים למשך 35 יום לכל היותר. LTR מאחסן גיבויים מלאים ב-Azure Blob Storage נפרד למשך עד 10 שנים, במיוחד עבור צרכי תאימות.

מסד נתונים חייב להישאר זמין במהלך כשל במרכז נתונים (Availability Zone) בתוך אזור Azure יחיד.

→אפשר את התצורה העמידה בפני אזורים (zone-redundant) עבור מסד נתונים ברמת Business Critical או Premium.

למה: יתירות אזורית פורסת עותקים משניים סינכרוניים במרכזי נתונים פיזיים שונים באותו אזור, ומספקת failover אוטומטי עם RPO קרוב לאפס עבור הפסקות ברמת אזור.

Azure SQL Managed Instance דורש פתרון התאוששות מאסון באזור Azure מזווג עם יכולת failover אוטומטי.

→הגדר Auto-Failover Group עבור Managed Instance.

למה: זהו דפוס ה-DR הקאנוני עבור Managed Instance, המספק שכפול אסינכרוני, נקודות קצה של מאזינים עבור failover יישומים שקוף, ואפשרות failover אוטומטית.

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

→הגדר את תקופת שמירת הגיבוי לטווח קצר (PITR) ל-30-35 ימים.

למה: Azure SQL מבצע אוטומטית גיבויים מלאים, דיפרנציאליים ויומני טרנזקציות תכופים. הגדרת שמירת ה-PITR (1-35 ימים) קובעת כמה זמן גיבויים אלה נשמרים, ומגדירה את חלון הזמן לשחזורים לנקודת זמן.

הגדרת Windows Server Failover Cluster עבור SQL Server Always On Availability Group במכונות וירטואליות של Azure.

→השתמש ב-Cloud Witness כעד הקוורום.

למה: Cloud Witness משתמש ב-Azure Blob Storage והוא האפשרות המומלצת והעמידה ביותר עבור אשכולות ב-Azure. הוא מונע את הצורך במכונה וירטואלית שלישית עבור עד שיתוף קבצים או תצורות דיסק משותפות מורכבות.

יישום SQL Server Failover Cluster Instance (FCI) במכונות וירטואליות של Azure הדורש אחסון משותף.

→השתמש ב-Azure Shared Disks (חיבור דיסק מנוהל למספר מכונות וירטואליות).

למה: Azure Shared Disks הוא פתרון ה-Azure המקורי למתן אחסון בלוקים הנגיש על ידי מספר מכונות וירטואליות, וזהו תנאי מוקדם עבור FCI מסורתי.

תהליך התאוששות מאסון עבור קבוצת failover צריך להיבדק מבלי להשפיע על מסד הנתונים הראשי בייצור.

→יזום failover מתוכנן (ידני) במהלך חלון תחזוקה בעל השפעה נמוכה, אמת קישוריות יישומים, ולאחר מכן בצע failback.

למה: failover מתוכנן מבטיח איבוד נתונים והוא הדרך המקיפה ביותר לאמת את כל תהליך ה-DR, כולל הפצת DNS וחיבור מחדש של היישום. זהו אירוע ייצור קצר ומבוקר.