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

בדף הזה מפורטות שיטות מומלצות להשגת הביצועים, העמידות והזמינות הכי טובים ב-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).

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

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

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

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

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

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

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

אבטחה

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

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

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

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

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

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

שיטה מומלצת מידע נוסף
להשתמש בשיטות טובות לניהול חיבורים, כמו איגום חיבורים (connection pooling) והשהיה מעריכית לפני ניסיון חוזר (exponential backoff). השימוש בטכניקות האלה משפר את השימוש במשאבים באפליקציה ועוזר לכם להישאר במסגרת מגבלות החיבור של Cloud SQL. למידע נוסף ולדוגמאות קוד, אפשר לעיין במאמר בנושא ניהול חיבורים למסדי נתונים.
בודקים את התגובה של האפליקציה לעדכוני תחזוקה, שיכולים להתבצע בכל שלב במהלך חלון הזמן לתחזוקה. אפשר לנסות תחזוקה בשירות עצמי כדי לדמות עדכון תחזוקה. במהלך התחזוקה, המופע שלכם לא יהיה זמין לפרק זמן קצר, והחיבורים הקיימים ינותקו. בדיקה של השקות תחזוקה מאפשרת לכם להבין טוב יותר איך האפליקציה מטפלת בתחזוקה מתוזמנת וכמה מהר המערכת יכולה להתאושש.
בודקים את התגובה של האפליקציה למעבר לגיבוי, שיכול לקרות בכל שלב. אפשר להפעיל מעבר לגיבוי ידני באמצעות המסוף Google Cloud ,‏ ה-CLI של gcloud או ה-API. מידע נוסף מופיע במאמר בנושא התחלת מעבר לגיבוי בשעת כשל.
מומלץ להימנע מעסקאות גדולות. העסקאות צריכות להיות קטנות וקצרות. אם צריך לעדכן מסד נתונים גדול, עדיף לבצע את העדכון בכמה עסקאות קטנות ולא בעסקה גדולה אחת.
אם אתם משתמשים בשרת 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 קבצי נתונים. אם המחלוקת נמשכת, מגדילים את מספר הקבצים בכפולות של 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. Parameter sniffing from database tables can help create execution plans for reuse. אם הנתונים בטבלאות לא מחולקים באופן שווה, יכול להיות שתוכניות הביצוע שיתקבלו יובילו לבעיות בביצועים. אם יש לכם נתונים כאלה, מומלץ להשתמש באפשרויות אחרות ממאגר השאילתות במקום לשנות את ההגדרה הזו.
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 של אחסון שקרוב לערך המקסימלי, עלול לגרום לצוואר בקבוק בביצועים.

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

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

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

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

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