none
Insert is taking too much time RRS feed

  • שאלה

  • שלום ,

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

    אנחנו מחזיקים באפליקצייה טבלת לוג, המתעדת הודעות שגיאה וריצות ארוכות (מעל ל 15 שניות - אצלנו במערכת זה נחשב ארוך ) , אנחנו מקבלים תיעוד על insert , שאורכים מעל 15 שניות ,

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

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

    ניסינו לחשוב יחד על גורמים שיכולים לעכב הכנסה לטבלה ( הרי בסה"כ מדובר באלוקציה , דף קיים או דף חדש ועדכון של האינדקס ) והכיוון הראשון שחשבנו עליו היה נעילות  , הרצנו Profiler ( אחרי שפתחנו את blocked process threshold ל 5 שניות ) ו ב Event הרלוונטי לא נלכדו נעילות . ניסינו לאתר האם היו אירועי גדילה של ה File באותו זמן וגם לא איתרנו ( הוא גם אמור לתעד את זה ל Default Trace ) .

    שללנו ג'ובים שרצים ברקע ,NetWork ,  האם יש עוד דרך להצליב מידע או כיוון שניתן לתחקר שיכול להעיד על איטיות ב Insert ?

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

    נשמח לשמוע רעיונות נוספים היכולים ליצור עיכוב ב DML  .

    תודה.

    יום שני 23 אפריל 2012 11:23

תשובות

  • אהלן נינג'ה!

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

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

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

    ודבר האחרון זה לבדוק האם בנקודת הזמן של הלוגים על ההכנסות לטבלה מסויימת כולם באותו הזמן התעכבו או רק חלקם ובמידה וכולם באותה נקודת הזמן התעכבו הייתי מציע לבדוק ביצועים כלליים על השרת (IO/CPU וכו')...

    בהצלחה,


    חיים פישנר.




    • הוצע כתשובה על-ידי haim fishner יום שני 23 אפריל 2012 14:20
    • נערך על-ידי haim fishner יום שני 23 אפריל 2012 14:24
    • הצעה כתשובה בוטלה על-ידי haim fishner יום שלישי 24 אפריל 2012 16:36
    • סומן כתשובה על-ידי pituachMVP, Editor יום שני 30 אפריל 2012 20:29
    יום שני 23 אפריל 2012 14:16
  • בהמשך לבדיקות שנעשו כבר:

    1. אתה רושם שיש לכם clustered index ואלו הרי קובעים את הסדר של הנתונים בעמודים + אתה רושם שהבעיה בהכנסת נתונים.

    אם האינדקסים הראשיים שלכם הם לא על נתונים כמו ID שהוא שדה IDENTITY או טור דומה בו אתם כל רשומה חדשה שנכנסת מגיעה בסיום אלא הם על טור כמו שרשרת אז יכול להיות שאתם מכניסים נתונים שאמורים להגיע באמצע הרשומות ולכן אתם סובלים מבעיית page split. נסה לתפוס בפרופיילר את האירועים של פיצול העמודים מפני שאלו יכולים פעולות כבדות (אם זה הבעיה אז אחד הפתרונות זה לקבוע פרמטר של GAP אבל קודם נאתר את הבעיה לפני שקופצים לפתרונות שיכולים ליצור בעיות אחרות).

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

    דרך אחרת היא לתפוס את הנתונים של מערכת ההפעלה דרך ה SQL למשל עם אירועים מורחבים (extended events)

    3. הייתי משקיע עוד זמן לגבי בדיקת הנעילות

    4. הייתי בודק אם הבעיה קשורה רק להכנסה של נתונים וכיצד אתם מכניסים את הנתונים. האם פעולת ההכנסה עצמה יוצרת את הבעיה או הפעולה מסביב (במלים אחלרות האם הבעיטה והאיטיות לא נובעת מהאפליקציה ולא מהשרת). כדי לבדוק את זה ניתן ברמת האפליקציה ליצור לוג ולעבוד למשל עם Trace Log (אני לא יודע הרבה ולא פירטת על האפליקציה שקוראת לשרת ה SQL אבל בדוט נט למשל יש מחלקות TRACE נהדרות שמאפשרות 3 סוגי מאזינים בהם ניתן לעשות שימוש. אם תבחר ב EventLogTraceListener תוכל אחר כך להצליב את הנתונים עם הפרופיילר)


    signature

    יום שני 23 אפריל 2012 20:32
    מנחה דיון

  • אני אתייחס לתגובה שלך רונן,

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

    אבל אהבתי את הכיוון :)

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

    גיא גלצר כתב על זה כאן - monitoring-page-splits

    ואני אצוטט משם-

    "I demonstrated that all the tools available by SQL Server to monitor page splits actually monitor
    both types (mid-page and end-page), and there is no way to monitor only "real" page splits,
    which are a common concern for DBAs.
    I then showed that there is one undocumented and unsupported way to achieve this goal,
    which is by looking at the transaction log using the "sys.fn_dblog" function and tracking the
    "LOP_DELETE_SPLIT" operation. This is the only indication in SQL Server for mid-page splits.
    I also showed that the same is true for SQL Server 2012."

    אבל, ואני מדגיש במידה ואתה מכיר משהו אחר ובאמת ניתן לנטר את הPAGE SPLITS באמצעות הprofiler אני אשמח לדעת כיצד אתה רואה זאת או איכן אני שוגה.

     

    לגבי כל שאר הטיפים, כבר סימנתי לך כ"מועיל" :)


    חיים פישנר.



    • נערך על-ידי haim fishner יום שני 23 אפריל 2012 21:37
    • סומן כתשובה על-ידי pituachMVP, Editor יום שני 30 אפריל 2012 20:28
    יום שני 23 אפריל 2012 21:34
  • טוב, חבל האמת שלא הצלחתי לקלוע בניחושים לפעמים זה עובד ;)

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

    לגבי אילו COUNTERS לשים ולמה הייתי מציע לך לקרוא על זה קצת אם אתה לא מכיר למשל בלינקים האלו או בכל מקום אחר ;)

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

     

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

    איך לעשות את זה ? אני אתן לך את האופציה שאני הייתי עושה את זה וזה ע"י -

    • יצירת טבלת LOG נוספת שתשמור נתונים לגבי אותם סשינים + נתוני מסגרת נוספים איכותיים שניתן להוציא מתוך הDMV'S כמו משך זמן הWAIT, טיפוס הWAIT, מי הריץ את השאילתה, אם מישהו נעל אז מי נעל, שם הHOST, שם האפליקציה שמריצה את אותו הSESSION וכו'.
    • לאחר מכן הייתי מגדיר JOB שמבצע שליפה עם JOINS על הDMV'S המפנקים שיש לנו ששולף את אותן השדות שקיימים בטבלת LOG שיצרתי, ומסנן לשלוף רק את הבקשות של סשיינים שמחקים יותר מX זמן, נגיד 50MS נשמע לי סביר בשביל להיפטר מכל ה"רעש".
      ואת השליפה מכניס לטבלת הLOG.
    • דואג להריץ את הג'וב בטווח זמנים קצר ככל האפשר (1-10 שניות) ואחרי הדגימה שכבר אני יודע שנכתבו לי מספר מספיק של הכנסות שהתעכבו יתר על המידה, הייתי עוצר את הJOB שמוציא את המידע על הWAITS ומתחיל לתחקר את הטבלת לוגים הנ"ל בכדי לנסות להבין מה הסיפור.
    • לדעתי אחרי שתקבל את הטבלה הזאת תדע לכוון לאיכן הבעיה (DISK/CPU/NETWORK או אפילו נעילות וכו') למרות שכבר אמרת שבדקתם, תתפלא לגלות שיש סיכוי שהפרופיילר לא תפס בגלל שהEVENT שהגדרת לו לא מוגדר לקפוץ על סוג מסויים של WAIT TYPE וכו'..
      לכן הייתי הולך קודם על הדרך הזאת כדי לנסות להבין יותר טוב במה להתמקד.

     

    אשמח להמשיך לעזור ברגע שיהיו לך את הWAIT TYPES מתוך הDMV'S על אותן הכנסות שמתעכבות.

    בהצלחה! :)


    חיים פישנר.





    • הוצע כתשובה על-ידי haim fishner יום שני 23 אפריל 2012 21:04
    • נערך על-ידי haim fishner יום שני 23 אפריל 2012 21:05
    • הצעה כתשובה בוטלה על-ידי haim fishner יום שלישי 24 אפריל 2012 16:35
    • סומן כתשובה על-ידי pituachMVP, Editor יום שני 30 אפריל 2012 20:28
    יום שני 23 אפריל 2012 20:44
  • * חיים צודק. את פיצול העמודים תופסים באירועים מורחבים.

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

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

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


    signature

    • סומן כתשובה על-ידי pituachMVP, Editor יום שני 30 אפריל 2012 20:28
    יום שלישי 24 אפריל 2012 06:49
    מנחה דיון
  • הי,

    תבדוק את ה- Disk Utilization באותו זמן והאם יש לך כתיבה של דפים מה- Transaction Log ל- Data Files היינו Checkpoint באותו זמן.

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

    תגדיל את אינטרבל ה-   Checkpoint ותראה האם הבעיה קוראת לעיתים פחות דחופות, בכל מקרה הכוון זה בדיקת Disk ע"י Performance Monitor ולא ע"י Profiler.

    בהצלחה


    אסף שלם

    • סומן כתשובה על-ידי pituachMVP, Editor יום שני 30 אפריל 2012 20:28
    יום חמישי 26 אפריל 2012 20:47

כל התגובות

  • אהלן נינג'ה!

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

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

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

    ודבר האחרון זה לבדוק האם בנקודת הזמן של הלוגים על ההכנסות לטבלה מסויימת כולם באותו הזמן התעכבו או רק חלקם ובמידה וכולם באותה נקודת הזמן התעכבו הייתי מציע לבדוק ביצועים כלליים על השרת (IO/CPU וכו')...

    בהצלחה,


    חיים פישנר.




    • הוצע כתשובה על-ידי haim fishner יום שני 23 אפריל 2012 14:20
    • נערך על-ידי haim fishner יום שני 23 אפריל 2012 14:24
    • הצעה כתשובה בוטלה על-ידי haim fishner יום שלישי 24 אפריל 2012 16:36
    • סומן כתשובה על-ידי pituachMVP, Editor יום שני 30 אפריל 2012 20:29
    יום שני 23 אפריל 2012 14:16
  • שלום חיים,

    א. אין לנו טריגרים ב DB .

    ב. לצערי , אין לנו constraints ב DB .

    ג. באותה נקודת זמן , לא מתחרשת בעיה כל שהיא מבחינת DML's על אובייקטים אחרים .

    ד. כדי לבדוק במקביל IO\CPU אני אצטרך להריץ PerfMon , נכון ?

    תודה.

    יום שני 23 אפריל 2012 18:49
  • בהמשך לבדיקות שנעשו כבר:

    1. אתה רושם שיש לכם clustered index ואלו הרי קובעים את הסדר של הנתונים בעמודים + אתה רושם שהבעיה בהכנסת נתונים.

    אם האינדקסים הראשיים שלכם הם לא על נתונים כמו ID שהוא שדה IDENTITY או טור דומה בו אתם כל רשומה חדשה שנכנסת מגיעה בסיום אלא הם על טור כמו שרשרת אז יכול להיות שאתם מכניסים נתונים שאמורים להגיע באמצע הרשומות ולכן אתם סובלים מבעיית page split. נסה לתפוס בפרופיילר את האירועים של פיצול העמודים מפני שאלו יכולים פעולות כבדות (אם זה הבעיה אז אחד הפתרונות זה לקבוע פרמטר של GAP אבל קודם נאתר את הבעיה לפני שקופצים לפתרונות שיכולים ליצור בעיות אחרות).

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

    דרך אחרת היא לתפוס את הנתונים של מערכת ההפעלה דרך ה SQL למשל עם אירועים מורחבים (extended events)

    3. הייתי משקיע עוד זמן לגבי בדיקת הנעילות

    4. הייתי בודק אם הבעיה קשורה רק להכנסה של נתונים וכיצד אתם מכניסים את הנתונים. האם פעולת ההכנסה עצמה יוצרת את הבעיה או הפעולה מסביב (במלים אחלרות האם הבעיטה והאיטיות לא נובעת מהאפליקציה ולא מהשרת). כדי לבדוק את זה ניתן ברמת האפליקציה ליצור לוג ולעבוד למשל עם Trace Log (אני לא יודע הרבה ולא פירטת על האפליקציה שקוראת לשרת ה SQL אבל בדוט נט למשל יש מחלקות TRACE נהדרות שמאפשרות 3 סוגי מאזינים בהם ניתן לעשות שימוש. אם תבחר ב EventLogTraceListener תוכל אחר כך להצליב את הנתונים עם הפרופיילר)


    signature

    יום שני 23 אפריל 2012 20:32
    מנחה דיון
  • טוב, חבל האמת שלא הצלחתי לקלוע בניחושים לפעמים זה עובד ;)

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

    לגבי אילו COUNTERS לשים ולמה הייתי מציע לך לקרוא על זה קצת אם אתה לא מכיר למשל בלינקים האלו או בכל מקום אחר ;)

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

     

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

    איך לעשות את זה ? אני אתן לך את האופציה שאני הייתי עושה את זה וזה ע"י -

    • יצירת טבלת LOG נוספת שתשמור נתונים לגבי אותם סשינים + נתוני מסגרת נוספים איכותיים שניתן להוציא מתוך הDMV'S כמו משך זמן הWAIT, טיפוס הWAIT, מי הריץ את השאילתה, אם מישהו נעל אז מי נעל, שם הHOST, שם האפליקציה שמריצה את אותו הSESSION וכו'.
    • לאחר מכן הייתי מגדיר JOB שמבצע שליפה עם JOINS על הDMV'S המפנקים שיש לנו ששולף את אותן השדות שקיימים בטבלת LOG שיצרתי, ומסנן לשלוף רק את הבקשות של סשיינים שמחקים יותר מX זמן, נגיד 50MS נשמע לי סביר בשביל להיפטר מכל ה"רעש".
      ואת השליפה מכניס לטבלת הLOG.
    • דואג להריץ את הג'וב בטווח זמנים קצר ככל האפשר (1-10 שניות) ואחרי הדגימה שכבר אני יודע שנכתבו לי מספר מספיק של הכנסות שהתעכבו יתר על המידה, הייתי עוצר את הJOB שמוציא את המידע על הWAITS ומתחיל לתחקר את הטבלת לוגים הנ"ל בכדי לנסות להבין מה הסיפור.
    • לדעתי אחרי שתקבל את הטבלה הזאת תדע לכוון לאיכן הבעיה (DISK/CPU/NETWORK או אפילו נעילות וכו') למרות שכבר אמרת שבדקתם, תתפלא לגלות שיש סיכוי שהפרופיילר לא תפס בגלל שהEVENT שהגדרת לו לא מוגדר לקפוץ על סוג מסויים של WAIT TYPE וכו'..
      לכן הייתי הולך קודם על הדרך הזאת כדי לנסות להבין יותר טוב במה להתמקד.

     

    אשמח להמשיך לעזור ברגע שיהיו לך את הWAIT TYPES מתוך הDMV'S על אותן הכנסות שמתעכבות.

    בהצלחה! :)


    חיים פישנר.





    • הוצע כתשובה על-ידי haim fishner יום שני 23 אפריל 2012 21:04
    • נערך על-ידי haim fishner יום שני 23 אפריל 2012 21:05
    • הצעה כתשובה בוטלה על-ידי haim fishner יום שלישי 24 אפריל 2012 16:35
    • סומן כתשובה על-ידי pituachMVP, Editor יום שני 30 אפריל 2012 20:28
    יום שני 23 אפריל 2012 20:44

  • אני אתייחס לתגובה שלך רונן,

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

    אבל אהבתי את הכיוון :)

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

    גיא גלצר כתב על זה כאן - monitoring-page-splits

    ואני אצוטט משם-

    "I demonstrated that all the tools available by SQL Server to monitor page splits actually monitor
    both types (mid-page and end-page), and there is no way to monitor only "real" page splits,
    which are a common concern for DBAs.
    I then showed that there is one undocumented and unsupported way to achieve this goal,
    which is by looking at the transaction log using the "sys.fn_dblog" function and tracking the
    "LOP_DELETE_SPLIT" operation. This is the only indication in SQL Server for mid-page splits.
    I also showed that the same is true for SQL Server 2012."

    אבל, ואני מדגיש במידה ואתה מכיר משהו אחר ובאמת ניתן לנטר את הPAGE SPLITS באמצעות הprofiler אני אשמח לדעת כיצד אתה רואה זאת או איכן אני שוגה.

     

    לגבי כל שאר הטיפים, כבר סימנתי לך כ"מועיל" :)


    חיים פישנר.



    • נערך על-ידי haim fishner יום שני 23 אפריל 2012 21:37
    • סומן כתשובה על-ידי pituachMVP, Editor יום שני 30 אפריל 2012 20:28
    יום שני 23 אפריל 2012 21:34
  • * חיים צודק. את פיצול העמודים תופסים באירועים מורחבים.

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

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

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


    signature

    • סומן כתשובה על-ידי pituachMVP, Editor יום שני 30 אפריל 2012 20:28
    יום שלישי 24 אפריל 2012 06:49
    מנחה דיון
  • תודה לכולם על התגובות , אני אתחיל לבדוק .

    יום שלישי 24 אפריל 2012 08:09
  • בטח שמותר :)!

    אפילו רצוי, עכשיו סוף סוף הבנתי את הפואנטה של הכפתור הזה "הצע כתשובה" עד עכשיו לא הבנתי למה מראש הוא לא מסמן לי אותו כאשר אני עונה על השאלה..

    תודה רבה על ההסבר ועכשיו אני אתחיל ל"התנהג בהתאם" ;)


    חיים פישנר.

    יום שלישי 24 אפריל 2012 17:19
  • כן עניין הניחושים תמיד מהווה אתגר למזל (אולי גם לנסיון לפעמים) יותר מאשר למחשבה :-)

    חג שמח
    וכמו תמיד... בתאבון במנגלים

    * DBANinja אל תשכח לעדכן אותנו היכן אתה עומד בבדיקה והאם הגיעה הישועה


    signature

    יום רביעי 25 אפריל 2012 17:10
    מנחה דיון
  • הי,

    תבדוק את ה- Disk Utilization באותו זמן והאם יש לך כתיבה של דפים מה- Transaction Log ל- Data Files היינו Checkpoint באותו זמן.

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

    תגדיל את אינטרבל ה-   Checkpoint ותראה האם הבעיה קוראת לעיתים פחות דחופות, בכל מקרה הכוון זה בדיקת Disk ע"י Performance Monitor ולא ע"י Profiler.

    בהצלחה


    אסף שלם

    • סומן כתשובה על-ידי pituachMVP, Editor יום שני 30 אפריל 2012 20:28
    יום חמישי 26 אפריל 2012 20:47
  • DBANinja אני אסגור את השירשור עצל ידי סימון כל התשובות שנתנו בו מפני שאני רואה שעבר דיי הרבה זמן מאז שהגבת. אם עדיין עולות שאלות אתה מוזמן כמובן להעלות אותם בשירשור חדש או כאן או לפתוח את השירשור לפי ראות עינייך :-)

    signature

    יום שני 30 אפריל 2012 20:28
    מנחה דיון