Partition Table using min/max functions and Top N - Index selection and performance
אחד הבאגים שקיימים בSQL Server, ובאופן אישי מאד מתסכלים אותי, הוא באג שקשור לpartitioned tables. כאשר אנו משתמשים בpartitioned table, ומבצעים שאילתה שמביאה כמות ספציפית של רשומות ע"י השימוש באופרטור top יחד עם order by או שאילתה אגרגטיבית עם min או max השרת יבצע table scan, גם אם יש לנו אינדקס מתאים. כמובן שלרוב הpartitioned table שלנו מכילה מאות מיליוני רשומות (אם לא מיליארדי רשומות ויותר), ופעולת הtable scan נמשכת זמן רב. הסיבה שהבאג הזה מאד מתסכל אותי, היא שהוא קיים כבר
Extended Event on Azure
לפני זמן מה, אחד המפתחים אצלנו התלונן על איטיות בהפעלת פקודת bulk insert בבסיס נתונים שנמצא על Azure (תצורת PaaS). כדי לבדוק את האטיות החלטתי להפעיל extended event session, שיראה את הwait statistics של כל תהליך שמריץ את הפקודה BULK INSERT. לרוב, אני מפעיל את הextended events ונותן לו לכתוב לקובץ ולא לזיכרון (בכתיבה לזיכרון יש באג, שגורם לכך שחלק מהנתונים "מועלמים" ע"י השרת ללא מתן הודעת שגיאה או אזהרה. ניתן לקרוא על הבאג הזה בעברית כאן, ובאנגלית כאן). הפעם בגלל שמדובר על
Is using CLR to parser strings will always be a good solution
אחת לזמן מה, בדרך כלל מידיי חודש, אנו שולחים בחברה אתגר טכנולוגי לכל צוות הSQL Server בנאיה. אני רוצה לשתף אתכם באתגר שעלה בחודש נובמבר 2016 ע"י עדי כהן. מדוע אני חושב שהאתגר הזה ראוי לשיתוף הקהל הרחב? מכיוון, שלהפתעתי הוא נגד את החשיבה הראשונית שאיתה הלכתי בתחילת האתגר, אני מאמין שכך גם לגבי המחשבה של אחרים. האתגר שהוצג - צריך לכתוב פרוצדורה, שמקבלת string בתור פרמטר. הstring יכול להיות מורכב מאותיות וסימנים (למשל #,$,! וכד') וכמובן מספרים. אפשר להניח שהאותיות יהיו אותיות
למה השרת משתמש בכל כך הרבה query plans לאותה פרוצדורה?
אחד הייתרונות בשימוש בפרוצדורות בSQL Server, הוא שימוש חוזר בquery plan. כאשר אנו משתמשים בפרוצדורה, השרת יוצר query plan, ולאחר מכן כל שימוש נוסף בפרוצדורה עובד לפי הquery plan, שנמצא כבר בcache, ולא צריך לגרום לייצור נוסף של query plan. כמובן שלא תמיד ניתן להשתמש באותו query plan. לפעמים יש נסיבות, שבהן למרות שיש כבר query plan לפרוצדורה בתוך הcache, השרת יוצר query plan נוסף לאותה פרוצדורה. הסיבה הידועה ביותר ליצירה של query plan נוסף, היא set options שונים בsessions ש
What are you waiting for?
עדי כהן מומחה SQL Server בעל כ-15 שנות ניסיון מגוון בתחום. ר"צ DBA בחברה למסחר פיננסי באינטרנט מטעם נאיה טכנולוגיות. אחד ה-views הכי יעילים באיתור בעיות ביצועים הוא sys.dm_os_waiting_tasks. כדי להבין את הView, צריך קצת להכיר את צורת העבודה של השרת. בצורה מאד מופשטת, אפשר לחלק את תהליכים שרצים בשרת לשלושה סוגים: הסוג הראשון משתמש במעבד ורץ. הסטטוס של תהליך מסוג זה הוא running. סוג שני מוכן לרוץ ומחכה לזמן מעבד. הסטאטוס של סוג תהליך מסוג זה הוא runnable. הסוג השלישי אינו רץ, ומ
SQL Server Profiler and server side trace
עדי כהן מומחה SQL Server בעל כ-15 שנות ניסיון מגוון בתחום. ר"צ DBA בחברה למסחר פיננסי באינטרנט מטעם נאיה טכנולוגיות. סרטון הדרכה המראה איך להפעיל-Server Side Trace באמצעות SQL Server Profiler #SQLServer #Profiler #SQLServerProfiler #TraceFile #AdiCohn #עדיכהן #ITPRO #DEV #SQLTrace
Error handling in SQL Server - TRY/CATCH and @@error
עדי כהן מומחה SQL Server בעל כ-15 שנות ניסיון מגוון בתחום. ר"צ DBA בחברה למסחר פיננסי באינטרנט מטעם נאיה טכנולוגיות. סרטון הדרכה המראה איך לטפל בשגיאות בקוד T-SQL תוך שימוש ב-TRY/CATCH #errorhandling #DEV #AdiCohn #עדיכהן #SQLServer #Scripting
בדיקת ניצול הנפח של tempdb
עדי כהן מומחה SQL Server בעל כ-15 שנות ניסיון מגוון בתחום. ר"צ DBA בחברה למסחר פיננסי באינטרנט מטעם נאיה טכנולוגיות. בתחילת יום עבודה אחד, קיבלתי התרעה על חוסר מקום באחד הדיסקים של אחד השרתים שלנו. בבדיקה מהירה שעשיתי, ראיתי, שאכן אחד מקבצי tempdb, גדל מאד במהלך הימים האחרונים. מאחר שמדובר בשרת פיתוח, הנחתי שמדובר בתהליך שבנה טבלה זמנית (ענקית), אבל סיים לרוץ ופינה את השטח. ניסיתי לכווץ את הקובץ ע"י הפקודה dbcc shrinkfile. הפקודה רצה ללא בעיה, אבל גודלו של tempdb לא השתנה.
