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

בדף הזה מפורטות שיטות מומלצות להשגת הביצועים, העמידות והזמינות הטובים ביותר מ-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 וערך של ‎.8. למידע נוסף, קראו את המאמר יצירת מדיניות התראות שמבוססת על מדדים.
למנוע ניצול יתר של המעבד (CPU).

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

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

כשמחפשים סימנים לניצול יתר של הזיכרון, צריך להשתמש בעיקר במדד usage. כדי למנוע שגיאות של מחסור בזיכרון, מומלץ שהמדד הזה יישאר מתחת ל-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, צריך לקבוע את הקיבולת של תת-המערכת של הקלט/פלט.

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

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

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

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

בנוסף, ודאו שהתכונה Enable automatic storage increases מופעלת ב-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), צריך לשחזר מהגיבוי המאובטח האחרון שידוע.

מידע נוסף על המגבלות מופיע במאמר תכונות של SQL Server שלא נתמכות ב-In-Memory OLTP.

אבטחה

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

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

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

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

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

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

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

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

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

גיבוי ושחזור

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

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

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

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

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

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

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

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

הגדרות של שרת SQL

יש כמה הגדרות של 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.4GB למערכת ההפעלה ולסוכנים.
  • אם ה-RAM בשרת הוא 16GB או פחות, צריך להקצות 1GB של זיכרון לכל 4GB של RAM.
  • אם זיכרון ה-RAM בשרת גדול מ-16GB, צריך להשאיר 4GB של זיכרון ולהקצות 1GB של זיכרון לכל 8GB של זיכרון RAM שגדול מ-16GB.

לדוגמה, אם ה-RAM של המכונה הוא 104GB
(106,496MB), צריך להקצות:

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

בדוגמה הזו, צריך להקצות זיכרון בנפח 16.4GB. לכן, הערך של הדגל הזה צריך להיות 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 מופיע בתור PAGELATCH_UP. כדי לצמצם את התחרות, מוסיפים עוד קבצים.

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

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

הגדרה המלצה
Close Cursor on Commit Enabled ערך ברירת המחדל הוא off, כלומר הסמנים לא נסגרים באופן אוטומטי כשמבצעים טרנזקציה.
Default Cursor האפשרות הזו קובעת את ההיקף של סמן שמשמש בקוד T-SQL. אם משנים את ההגדרה הזו, צריך לבדוק את קוד האפליקציה כדי לוודא שאין השפעות שליליות.
Page Verify האפשרות הזו מאפשרת ל-SQL Server לחשב סיכום ביקורת (checksum) לדף של מסד נתונים לפני שהוא נכתב בדיסק, ולאחסן את סיכום הביקורת בכותרת הדף. כשדף נקרא שוב, סיכום הביקורת (checksum) מחושב מחדש כדי לאמת את תקינות הדף. הערך המומלץ הוא 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 Store במקום לשנות את ההגדרה הזו.
Query Optimizer Fixes ‫False. כשהיא מופעלת, היא יכולה להשפיע על הביצועים של מעריך העוצמה של שרת ה-SQL. אם בוחרים להפעיל אותה, צריך לבדוק שאין רגרסיה של שאילתות.
Auto Create Statistics ‫True. האפשרות הזו מאפשרת ל-SQL Server ליצור נתונים סטטיסטיים של עמודה אחת, שיכולים לשפר את הערכות העוצמה של תוכניות לביצוע שאילתות.
Auto Update Statistics ‫True. האפשרות הזו מאפשרת לשרת SQL לעדכן נתונים סטטיסטיים לא עדכניים באמצעות סף הידור מחדש שמבוסס על עוצמת הטבלה.
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. ההגבלה הזו מפחיתה את האבטחה סביב תפקידי האפליקציה. צריך לאמת אותו בהתאם לדרישות של האפליקציה.