אחד הפיצ’רים שהושקו ב- SQL Server 2016 היה ה- Query Store. אם עוד לא יצא לכם להכיר אותו, ממליץ לקרוא עליו קצת פה. בגדול, מדובר בכלי שמאפשר להוציא insights טובים יותר בסוגיות שמעסיקות DBA-ים. בין היתר, זיהוי של שאילתות מעמיסות, זיהוי רגרסיות בריצת שאילתות וטיפול נוח בזה ועוד.
החל מ- SQL Server 2017, המנגנון של ה- Query Store גם משמש את פיצ’ר ה- Automatic Tuning של שאילתות, שמאפשר להגדיר את ה- flag של “FORCE_LAST_GOOD_PLAN” שעוזר (פוטנציאלית) למנוע רגרסיות שנובעות מבחירת execution plan פחות טוב מ-execution plan שנעשה בו שימוש בעבר.

אבל, לפעמים אנחנו מגלים את העלויות הנסתרות של דברים טובים. הרבה פעמים זה גם קורה בזמן לא מאד נוח….
תופעה שנתקלתי בה – בזמן ביצוע Failover ל- AlwaysOn Availability Group שכולל מס’ דטאבייסים, לאחר שמרבית ה- DB-ים סיימו לעבור recovery בשרת שאליו בוצע ה- failover, לא ניתן היה לעבוד כלל עם אחד מה- DB-ים שהיו ב-AG. כשאני אומר שלא ניתן לעבוד, הכוונה שלא היה ניתן להריץ אף שאילתה – כולן היו blocked, וה- Wait Type היה משותף לכולם – QDS_LOADDB.
גם לאחר המתנה לא קצרה לא היה נראה שהתהליך מתקרב לסיום. השרת, אגב, כל הזמן הזה לא התאמץ ולא הזיע בכלל. פחות או יותר אפס ניצול של ה- CPU, אפס IOPS, אפס throughput מול הדיסק.  שזה, דרך אגב, אחד הדברים שיותר מטרידים אותי כשאני רואה תהליך “תקוע”.

מפה לשם, כדאי לדעת שהליך ה- initialization של ה- Query Data Store מתבצע סינכרונית עם עליית ה-DB (זאת ההתנהגות הדיפולטית).  כלומר, אם מאיזושהי סיבה משהו בתהליך הזה “נתקע” (ואין לי לצערי משהו חכם להגיד על הסיבה האמיתית שגרמה לתקיעה הזאת מאחורה) – כוווולם ימתינו. אז מה אפשר לעשות?

• אם אתם נמצאים כבר בסיטואציה הזאת, ורוצים “לשחרר” את התקיעה – כיבוי ה- Query Store (עם ALTER DATABASE [Sample] SET QUERY_STORE = OFF) משחרר את התקיעה הזאת. אחרי זה אתם יכולים להפעיל אותו מחדש ולראות מה קורה – האם זה יעבוד as is (אולי) ואז גם יהיה לכם את כל ה- data שנאגר עד עכשיו. אם לא, אתם יכולים לעשות purge ואז להפעיל מחדש את ה- Query Store.
• אם אתם נתקלתם בה בעבר, ורוצים למנוע ממנה מלהתרחש בעתיד (או כיביתם ועכשיו אתם רוצים להפעיל מחדש בלי להיתקע שוב, גם אם התהליך ייקח זמן רב) אז הפעילו את trace flag 7752 (גלובלי). הוא גורם להפעלה א-סינכרונית של ה- Query Data Store, בצורה כזאת שלא הכל ייתקע עד שהוד רוממותו יואיל להיטען.
  על אף שנשמע שזאת ההתנהגות ההגיונית, מאיזושהי סיבה היא איננה ה- default, ואף כשהשאלה הזאת עלתה בסשן AMA ב- reddit, ההמלצה שניתנה שם היא לא להפעיל את ה-TF הזה באופן גורף.

בכל אופן, אחת המסקנות שאני לקחתי מהנושא הזה היא שה- Query Data Store מגמגם כשנאגרים בו נפחי מידע גדולים מאד. אז קחו את זה לתשומת לבכם, גם מבחינת הגדרות ה- query data store (ה- retention וכו’) וגם מבחינת ההחלטה של מה לעשות במידה שהוא גדול ונתקלים בבעיית ה- QDS_LOADDB (הבחירה בין לבצע purge לבין להעביר לטעינה אסינכרונית עם ה- TF הנ”ל).

בהצלחה.