המלצות כלליות

בדף הזה מפורטות שיטות מומלצות להשגת הביצועים, העמידות והזמינות הטובים ביותר ב-Cloud SQL.

אם מתרחשות בעיות במכונה של Cloud SQL, כדאי לבדוק את הדברים הבאים במהלך פתרון הבעיות:

הגדרה וניהול של מופע

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

מופעי Cloud SQL לא יקבלו בקשות חדשות לפעולות עד שהם ישלימו את הפעולה הקודמת. אם תנסו להתחיל פעולה חדשה לפני הזמן, בקשת הפעולה תיכשל. הפעולות האלה כוללות הפעלה מחדש של מופעים.

הסטטוס של המופע במסוף Google Cloud לא משקף אם פעולה כלשהי פועלת. סימן הוי הירוק מציין רק שהמופע נמצא במצב RUNNABLE. כדי לראות אם פעולה פועלת, עוברים לכרטיסייה Operations ובודקים את הסטטוס של הפעולה האחרונה.

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

אם הגדרת המכונה enable automatic storage increases מושבתת או שההגדרה automatic storage increase limit מופעלת, צריך לוודא שיש לפחות 20% מקום פנוי כדי לאפשר פעולות תחזוקה קריטיות במסד הנתונים ש-Cloud SQL עשוי לבצע.

כדי לקבל התראה כשהמקום הפנוי בדיסק יורד מתחת ל-20%, צריך ליצור מדיניות התראות שמבוססת על המדד disk utilization (ניצול הדיסק) עם מיקום של above threshold (מעל סף) וערך של 0.8. מידע נוסף זמין במאמר יצירת מדיניות התראות שמבוססת על מדדים.
למנוע ניצול יתר של המעבד (CPU).

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

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

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

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

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

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

להגדיל את הזיכרון של מכונת Cloud SQL. כדי לשנות את גודל הזיכרון של המופע, צריך להפעיל מחדש את המופע. אם הגודל של הזיכרון במופע כבר הגיע למקסימום, צריך לפצל את מסד הנתונים לכמה מופעים. מידע נוסף על מעקב אחרי שני המדדים במסוף Google Cloud זמין במאמר מדדים.
הגדרת הגדרות של SQL Server כך שיפעלו בצורה אופטימלית ב-Cloud SQL. הגדרות של SQL Server
כדאי לבצע אופטימיזציה של המופע כדי להריץ בדיקות. בטבלה הבאה מפורטים ערכי ההגדרה שמתאימים להרצות בדיקה.
  • vCPU: 40
  • זיכרון: 262144 MB
  • ‫MAXDOP: ‏ 8
  • סף העלות להפעלה של מקביליות: 120
  • קבצי tempdb: ‏ 8. הגודל מוגדר מראש כדי למנוע הגדלה אוטומטית.
  • קבצים של מסד נתונים של משתמשים: הגדרה של גידול אוטומטי בנפח של 64-128 MB. הגודל מוגדר מראש כדי למנוע הגדלה אוטומטית.
  • נפח אחסון: >= 4TB כדי לקבל את ה-IOPS הכי טוב
לפני שמבצעים פריסה של SQL Server, צריך לקבוע את הקיבולת של מערכת המשנה של קלט/פלט.

כדאי לבדוק מגוון סוגים וגדלים של קלט/פלט. הגודל של הקלט/פלט שמונפק לאחסון בדיסק מתמשך שמגיע מ-SQL Server משפיע על ה-IOPS ועל קצב העברת הנתונים. עומס העבודה של SQL Server עובר ויסות (throttling) כשהוא מגיע למגבלת ה-IOPS או למגבלת התפוקה. סוג האחסון שבו נעשה שימוש ב-Cloud SQL הוא SSD של דיסק מתמשך, שמתאים לעומסי עבודה ארגוניים עם ביצועים גבוהים.

כדי למקסם את הביצועים של המכונה הווירטואלית, מבצעים את ההתאמות האישיות הבאות:

  • גודל דיסק של 4TB או יותר מספק תפוקה גבוהה יותר ו-IOPS גבוה יותר.
  • יותר vCPU מספק יותר IOPS וקצב העברת נתונים. כשמשתמשים ב-vCPU גבוה יותר, צריך לעקוב אחרי ההמתנות של מסד הנתונים לביצוע מקביל, כי הן עשויות לעלות גם כן.
  • כדי להשיג ביצועים אופטימליים, צריך להנפיק קלט/פלט במקביל כדי להשיג עומק תור קלט/פלט גבוה יותר.
מניעת פיצול של אינדקסים ואינדקסים חסרים. כדאי לארגן מחדש את האינדקס או להגדיר לוח זמנים לבנייה מחדש של האינדקס, בהתאם לתדירות שבה הנתונים משתנים. כמו כן, צריך להגדיר גורם מילוי מתאים כדי לצמצם את הפיצול. עוקבים אחרי SQL Server כדי לזהות אינדקסים חסרים שיכולים לשפר את הביצועים.
עדכנו את הנתונים הסטטיסטיים באופן קבוע. אם הנתונים הסטטיסטיים לא עדכניים, יכול להיות שהכלי לאופטימיזציה של שאילתות SQL ייצור תוכניות שאילתה לא אופטימליות. כדאי לעדכן את הנתונים הסטטיסטיים, במיוחד אחרי שינוי של כמויות גדולות של נתונים. משתמשים במאגר השאילתות כדי לעקוב אחרי SQL Server ולפתור בעיות בו, אם יש בו תוכניות שאילתה לא אופטימליות.
למנוע מקבצי מסד נתונים לגדול שלא לצורך.

מגדירים את autogrow במגה-בייט ולא באחוזים, באמצעות ערכים שמתאימים לדרישה. בנוסף, כדאי לנהל באופן יזום את הגידול לפני שהגידול האוטומטי מתחיל.

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

כדי לזהות בעיות בשלמות מסד הנתונים, מריצים את הפקודה DBCC CHECKDB לפחות פעם בשבוע. DBCC CHECKDB בודק את התקינות של כל האובייקטים במסד נתונים. אם מריצים את DBCC CHECKDB מדי שבוע, אפשר לוודא שהמסדי נתונים לא פגומים. DBCC CHECKDB היא פעולה שדורשת הרבה משאבים ויכולה להשפיע על הביצועים של המופע.
לא מריצים את DBCC CHECKDB בשרת ייצור.
מומלץ להשתמש באחת מהאפשרויות הבאות במקום להריץ את DBCC CHECKDB בשרת ייצור:
  • משכפלים מסד נתונים ומריצים את הפקודה DBCC CHECKDB במסד הנתונים המשוכפל.
  • משחזרים גיבוי למכונה אחרת ואז מריצים את הפקודה DBCC CHECKDB במסדי הנתונים של המכונה המשוחזרת. מידע נוסף על שחזור מכונה זמין במאמר שחזור מכונה.

אפשר להשתמש בקטעי הקוד הבאים כדי להריץ את DBCC CHECKDB במסד נתונים:

  • (מומלץ) מריצים את הפקודה DBCC CHECKDB עם EXTENDED_LOGICAL_CHECKS. זו בדיקה מקיפה יותר, אבל היא דורשת יותר משאבים. 
          USE DATABASE_NAME
      DBCC CHECKDB WITH EXTENDED_LOGICAL_CHECKS,
      DATA_PURITY,NO_INFOMSGS, ALL_ERRORMSGS
  • מריצים את DBCC CHECKDB עם PHYSICAL_ONLY: 
          USE DATABASE_NAME
      DBCC CHECKDB WITH PHYSICAL_ONLY,
      NO_INFOMSGS, ALL_ERRORMSGS

אופטימיזציה של הביצועים

כדי לשמור על אבטחת הנתונים ולהבטיח שהאפליקציות יפעלו בצורה חלקה עם טבלאות In-Memory OLTP, כדאי לפעול לפי השיטות המומלצות הבאות:

שיטה מומלצת מידע נוסף
פועלים לפי השיטות המומלצות של מיקרוסופט לטבלאות מותאמות לצריכת זיכרון גבוהה (memory-optimized)
  • גיבויים קבועים: חשוב לוודא שתזמנתם גיבויים קבועים של מסדי הנתונים. במקרה של השחתת נתונים, תוכלו לשחזר את הנתונים למצב המאובטח האחרון שלהם.
  • אימות הגיבוי: מכיוון שאפשרויות התיקון של DBCC לא זמינות לטבלאות מותאמות לצריכת זיכרון גבוהה (memory-optimized), מומלץ לבדוק את הגיבוי על ידי הפעלת שחזורים תקופתיים. אם מתרחשות בעיות בתקינות נתונים בטבלה מותאמת לצריכת זיכרון גבוהה (memory-optimized), צריך לשחזר מגיבוי מאובטח אחרון ידוע.

מידע נוסף על מגבלות זמין במאמר בנושא תכונות של SQL Server שלא נתמכות ב-OLTP בזיכרון.

אבטחה

שיטה מומלצת מידע נוסף
העדפה של כתובת IP פרטית אלא אם נדרשת גישה באמצעות כתובת IP ציבורית, מומלץ להשתמש בכתובת IP פרטית. כך תוכלו לצמצם את הסיכוי לחיבורים לא מורשים לרשת למסד הנתונים.
איך להימנע מ-0.0.0.0/0 ברשתות מורשות לא כדאי לכלול את 0.0.0.0/0 ברשתות מורשות, כי זה מאפשר גישה מהאינטרנט הגלובלי ללא הגבלה.
מומלץ להימנע מרשתות מורשות גדולות מדי לא מומלץ להשתמש בקידומות CIDR קטנות ברשתות מורשות, כי זה מאפשר גישה ממספר גדול מדי של מארחים. מומלץ להשתמש בקידומת CIDR שלא קטנה מ-‎ /16, ועדיף גדולה מ-‎ /19.

ארכיטקטורת נתונים

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

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

סדר השוואה (collation) של מסד נתונים בין אם אתם מתקינים מופע חדש של SQL Server, משחזרים גיבוי של מסד נתונים או מחברים שרת למסדי נתונים של לקוחות, חשוב להבין את הדרישות לגבי הלוקאל, סדר המיון, והרגישות לאותיות רישיות ולסימני הטעמה של הנתונים שאתם עובדים איתם. כשבוחרים קביעת איסוף (collation) לשרת, למסד נתונים, לעמודה או לביטוי, מקצים לנתונים מאפיינים מסוימים. המאפיינים האלה משפיעים על התוצאות של הרבה פעולות במסד הנתונים. לדוגמה, כשמגדירים שאילתה באמצעות ORDER BY, סדר המיון של קבוצת התוצאות עשוי להיות תלוי באוסף הכללים (collation) שמוחל על מסד הנתונים או שמוגדר בפסוקית COLLATE ברמת הביטוי של השאילתה. מידע נוסף על השוואות בין מסדי נתונים ותמיכה ב-Unicode
עיצוב שאילתות כדי להשיג ביצועים אופטימליים של מסד הנתונים או השאילתה, חשוב לוודא שלא משתמשים במספר גדול של טבלאות באותה שאילתה (16 או יותר).
מעקב אחרי שאילתות יכול להיות שהאיכות של השאילתות תרד עם הזמן. חשוב לעקוב אחרי הביצועים של האפליקציה והשאילתות לאורך זמן. אחת הסיבות לירידה כזו היא hash bailouts.
הצטרפויות רקורסיביות של גיבוב או מעקפים של גיבוב גורמים לירידה בביצועים בשרת. אם רואים הרבה אירועים של אזהרת גיבוב במעקב, צריך לעדכן את הנתונים הסטטיסטיים בעמודות שמצורפות. מידע נוסף על הפסקת פעולה של פונקציית גיבוב

הטמעת האפליקציה

שיטה מומלצת מידע נוסף
להשתמש בשיטות מומלצות לניהול חיבורים, כמו איגום חיבורים (connection pooling) והשהיה מעריכית לפני ניסיון חוזר (exponential backoff). השימוש בטכניקות האלה משפר את השימוש במשאבים באפליקציה ועוזר לכם להישאר במסגרת מגבלות החיבור של Cloud SQL. למידע נוסף ולדוגמאות קוד, אפשר לעיין במאמר בנושא ניהול חיבורים למסדי נתונים.
בודקים את התגובה של האפליקציה לעדכוני תחזוקה, שיכולים לקרות בכל שלב במהלך חלון הזמן לתחזוקה. אפשר לנסות תחזוקה בשירות עצמי כדי לדמות עדכון תחזוקה. במהלך התחזוקה, המכונה שלכם לא תהיה זמינה לפרק זמן קצר, והחיבורים הקיימים ינותקו. בדיקה של השקות תחזוקה מאפשרת לכם להבין טוב יותר איך האפליקציה מטפלת בתחזוקה מתוזמנת וכמה מהר המערכת יכולה להתאושש.
בודקים את התגובה של האפליקציה למעבר לגיבוי, שיכול לקרות בכל שלב. אפשר להפעיל מעבר לגיבוי ידנית באמצעות המסוף Google Cloud ,‏ gcloud CLI או ה-API. מידע נוסף מופיע במאמר בנושא הפעלת מעבר לגיבוי (failover).
מומלץ להימנע מעסקאות גדולות. העסקאות צריכות להיות קטנות וקצרות. אם צריך לבצע עדכון גדול במסד הנתונים, עדיף לבצע אותו בכמה עסקאות קטנות ולא בעסקה גדולה אחת.
אם אתם משתמשים בשרת proxy ל-Cloud SQL Auth, חשוב לוודא שאתם משתמשים בגרסה העדכנית ביותר. איך מעדכנים את שרת ה-Proxy ל-Cloud SQL Auth

ייבוא וייצוא של נתונים

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

גיבוי ושחזור

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

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

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

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

כשמשתמשים בתכונת הגיבוי לייצוא במופע של SQL Server במהדורת Enterprise או Standard, מומלץ להימנע מיצירת קובץ ארכיון GZ כי המערכת מנסה לדחוס גיבוי שכבר דחוס באופן מקורי על ידי SQL Server.

הגנה על המופע ועל הגיבויים מפני מחיקה מקרית.

מכונת Cloud SQL שיוצרים במסוף Google Cloud או באמצעות Terraform מאפשרת כברירת מחדל מניעת מחיקה בטעות.

כדי להגן על הנתונים, אפשר להשתמש בתכונת הייצוא ב-Cloud SQL. אפשר להשתמש ב-Cloud Scheduler עם API בארכיטקטורת REST כדי לבצע אוטומציה של ניהול הייצוא. בתרחישים מתקדמים יותר, אפשר להשתמש ב-Cloud Scheduler עם פונקציות Cloud Run לאוטומציה.

הגדרות של SQL Server

יש הגדרות מומלצות של SQL Server ל-Cloud SQL. בנושאים הבאים מתוארות כמה המלצות.

הגדרות גלובליות

הגדרה המלצה
max worker threads משאירים את ערך ברירת המחדל 0. ההגדרה הזו מגדירה את מספר השרשורים שזמינים ל-SQL Server על סמך מספר המעבדים. הערך מחושב באופן אוטומטי על ידי מנוע SQL Server בזמן ההפעלה.
max server memory (mb)

הדגל הזה מגביל את כמות הזיכרון ש-Cloud SQL יכול להקצות למאגרי הזיכרון הפנימיים שלו.

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

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

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

אם אתם צריכים לנהל את הערך של הדגל באופן ידני, מומלץ להשתמש בנוסחה הבאה כדי להגדיר את דגל מסד הנתונים max server memory (mb):

  • שומרים 1.4 GB של זיכרון למערכת ההפעלה ולאמצעי הבקרה.
  • אם זיכרון ה-RAM בשרת קטן מ-16GB או שווה לו, צריך להקצות 1GB של זיכרון לכל 4GB של RAM.
  • אם זיכרון ה-RAM בשרת גדול מ-16GB, צריך להשאיר 4GB של זיכרון ולשריין 1GB של זיכרון לכל 8GB של RAM שגדול מ-16GB.

לדוגמה, אם ה-RAM של המופע הוא 104 GB‏
(106496 MB), צריך להזמין:

  • זיכרון בנפח 1.4 GB למערכת ההפעלה ולסוכנים
  • ‫4 GB של זיכרון, כי 104 GB גדול מ-16 GB
  • ‫11 GB של זיכרון, כי יש 88 GB של RAM שגדולים מ-16 GB‏ (104-16=88), ו-88 חלקי 8 זה 11

בדוגמה הזו, צריך להקצות 16.4 GB של זיכרון. לכן, הערך של הדגל הזה צריך להיות 89702 MB
[(104-16.4) * 1024 = 89702].

בטבלה הבאה מפורטים ערכים מומלצים ואחוזים מזיכרון ה-RAM הכולל לכמה רמות פופולריות של מכונות וירטואליות (VM):

רמת המכונה (MB) max server memory (mb) ‫% (סה"כ)
3840 1440 37
4096 1632 39
5792 2912 50
8192 4704 57
11584 7248 62
16384 10848 66
23168 16800 72
32768 25200 76
46336 37072 80
65568 53888 82
92704 77648 83
131136 111248 84
185440 158784 85
262272 226000 86
370880 321056 86
524544 455488 86
741792 645600 87

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

  • database/memory/usage
  • database/sqlserver/memory/buffer_cache_hit_ratio
  • database/sqlserver/memory/memory_grants_pending
  • database/sqlserver/memory/page_life_expectancy

מידע נוסף מופיע במאמר מעקב אחרי מכונות Cloud SQL.

הגדרות מסד הנתונים שצריך לשנות

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

הגדרה המלצה
cost threshold for parallelism

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

המערכת מתעלמת מהערך אם maxdop מוגדר כ-1.

max degree of parallelism (MAXDOP)

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

מידע נוסף זמין במאמר max degree of parallelism (MAXDOP).

optimize for ad hoc workloads

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

tempdb

צריך להגדיר מראש את הגודל של tempdb כדי שלא יגדל אוטומטית. כל הקבצים ב-tempdb צריכים להיות באותו גודל ולהגדיר את אותו גידול בקובץ.

סוג ההמתנה במסד הנתונים של tempdb contention מופיע כ-PAGELATCH_UP. כדי לצמצם את התחרות, מוסיפים עוד קבצים.

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

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

הגדרה המלצה
Close Cursor on Commit Enabled ערך ברירת המחדל הוא off, כלומר הסמנים לא נסגרים אוטומטית כשמבצעים פעולת אישור (commit) של טרנזקציה.
Default Cursor האפשרות הזו קובעת את ההיקף של סמן שמשמש בקוד T-SQL. אם משנים את ההגדרה הזו, צריך לבדוק את קוד האפליקציה כדי לוודא שאין לכך השפעות שליליות.
Page Verify האפשרות הזו מאפשרת ל-SQL Server לחשב סכום ביקורת לדף במסד נתונים לפני שהוא נכתב לדיסק, ולשמור את סכום הביקורת בכותרת הדף. כשקוראים דף שוב, סכום הביקורת מחושב מחדש כדי לאמת את השלמות של הדף. הערך המומלץ הוא checksum.
Parameterization ערך ברירת המחדל הוא simple. פרמטריזציה פשוטה מאפשרת ל-SQL Server להחליף ערכים מילוליים בשאילתה בפרמטרים. מיקרוסופט מספקת הנחיות לגבי שינוי הערך הזה ושימוש בו עם מדריכי תוכניות.

הגדרות מסד הנתונים שרוצים לשמור

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

הגדרה ערך ברירת המחדל שרוצים לשמור
Auto Close ‫False. כשההגדרה הזו מופעלת, החיבורים נפתחים ונסגרים, וההליך מתבצע מחדש אחרי כל חיבור. זה יכול לגרום לירידה בביצועים במסדי נתונים שיש אליהם גישה לעיתים קרובות.
Auto Shrink False. הפעלת האפשרות הזו עלולה לגרום לפיצול של מסד הנתונים והאינדקסים ולבעיות אחרות בביצועים, שחלקן מפורטות בבלוג הזה בנושא SQL Server.
Date Correlation Optimization Enabled False. הפעלת האפשרות הזו מאפשרת לכלי האופטימיזציה למצוא ולבצע אופטימיזציה של קשרים בין תאריכים בשתי טבלאות קשורות. מעקב אחרי זה ב-SQL Server כרוך בעומס מסוים על הביצועים.
Legacy Cardinality Estimation ‫False. במקרים מסוימים, אי אפשר לחשב במדויק את הקרדינליות ב-SQL Server כשההגדרה הזו מופעלת.
Parameter Sniffing ON. חילוץ פרמטרים מטבלאות של מסדי נתונים יכול לעזור ליצור תוכניות ביצוע לשימוש חוזר. אם הנתונים בטבלאות לא מחולקים באופן שווה, יכול להיות שתוכניות הביצוע שיתקבלו יובילו לבעיות בביצועים. במקרה כזה, מומלץ להשתמש באפשרויות אחרות ממאגר השאילתות במקום לשנות את ההגדרה הזו.
Query Optimizer Fixes False. כשההגדרה הזו מופעלת, היא יכולה להשפיע על הביצועים של כלי ההערכה של עוצמת הקשר ב-SQL Server. אם תבחרו להפעיל אותו, תצטרכו לבצע בדיקה כדי לוודא שאין רגרסיה בשאילתות.
Auto Create Statistics ‫True. האפשרות הזו מאפשרת ל-SQL Server ליצור נתונים סטטיסטיים של עמודה יחידה, שיכולים לשפר את ההערכות של עוצמת הקבוצה בתוכניות השאילתות.
Auto Update Statistics ‫True. האפשרות הזו מאפשרת ל-SQL Server לעדכן נתונים סטטיסטיים לא עדכניים באמצעות סף הידור מחדש שמבוסס על עוצמת הטבלה.
Auto Update Statistics Asynchronously ‫False. כשהאפשרות הזו מופעלת, האופטימיזציה של שאילתת ה-SQL מונחה להשתמש בנתונים הסטטיסטיים הישנים להרצת השאילתה הנוכחית, תוך עדכון הנתונים הסטטיסטיים באופן אסינכרוני כדי לשפר את עומסי העבודה העתידיים.

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

Target Recovery Time (Seconds) ‫60. ההגדרה הזו קובעת את הגבול העליון של זמן השחזור של מסד נתונים, על ידי ניקוי דפים לא נקיים בתדירות גבוהה או נמוכה יותר מהמאגר לדיסק. במקרים של עומסי עבודה עם נפח גבוה של טרנזקציות, ערך נמוך יותר בהגדרה הזו, בשילוב עם IOPS של אחסון שקרוב לערך המקסימלי, עלול לגרום לצוואר בקבוק בביצועים.

הגדרות של דגלי מעקב

דגלי מעקב ב-SQL Server משמשים להגדרת מאפיינים מסוימים, לשינוי ההתנהגות של מסדי נתונים של SQL Server או לניפוי באגים ב-SQL Server.

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

דגל מעקב מומלץ
1204 ‫Yes, למעט שרתים עם עומס עבודה גבוה שמייצרים הרבה מצבי קיפאון.

הפונקציה מחזירה את המשאבים ואת סוגי הנעילות שמשתתפים במבוי סתום, וגם את הפקודה שמושפעת כרגע.
1222 ‫Yes, למעט שרתים עם עומס עבודה גבוה שמייצרים הרבה מצבי קיפאון.
1224 No. התוצאה יכולה להיות שימוש רב יותר בזיכרון ולגרום לעומס על הזיכרון של מסד הנתונים.
2528 ‫No. בדיקה מקבילה של אובייקטים היא ברירת המחדל והמומלצת. מידת המקביליות מחושבת באופן אוטומטי על ידי המנוע של מסד הנתונים.
3205 No. כונני קלטות לגיבויים הם תכונה של Cloud SQL ל-SQL Server.
3226 ‫No, אלא אם אתם צריכים גיבויים בתדירות גבוהה, כמו גיבויים של TLOG.
3625 No. יכול להיות שלא תהיה לחשבון הבסיס גישה לכל הודעות השגיאה, כי אין לו הרשאת אדמין במערכת.
4199 No. הבעיה הזו משפיעה על כלי ההערכה של העוצמה (cardinality) ויכולה לגרום לרגרסיה בשאילתות.
4616 No. ההגבלה הזו מפחיתה את רמת האבטחה של תפקידי האפליקציה. צריך לאמת אותו בהתאם לדרישות של האפליקציה.