none
אינדוקס RRS feed

  • שאלה

  • שלום,

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

    השאלה היא איזה תהליך של תחזוקת אינדקסים הכי חסכוני מבחינת IO ו ניפוח קובץ הלוג?

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

    האם הבעיה מוכרת למישהו? ומה ניתן לעשות בכדי להימנע מהבעיה?

    תודה

    יום חמישי 30 יולי 2015 10:53

תשובות

  • בוקר טוב,

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

    * אם דנים במקום שצריך בדיסק בשביל העותק של האינדקס אז חשוב מאוד להבין כמה מקום תופס האינדקס עצמו! תוכל להעזר ב DMV הבא sys.dm_db_index_physical_stats על מנת לקבל יותר מידע על האינדקסים והמקום שהם תופסים כרגע (ככה תוכל לדעת כמה מקום אתה צריך בשביל העותק של האינדקס). כמובן שצריך לזכור שבנוסף למקום שצריך בשביל העותק, צריך גם מקום נוסף בשביל פעולת המיון וסידור הנתונים.

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

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

    Clustered
    Non-clustered
    Indexed view
    XML
    Filtered
    Spatial
    Compressed Indexes

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

    ** פעולת בנייה מחדש היא פעולה כבדה יחסית שנעשית כטרנזקציה בודד (Single Atomic Transaction), בעוד פעולת אירגון האינדקס אמורה להיות הרבה יותר קלה, מידע כן נרשם בלוג אבל ניתן לבצע אותה בשלבים ולעצור (הפעולה נעשית ב Small Discrete Transactions). למרות זאת כאשר המצב של האיחוי גרוע אז מהר יותר לבנות את האינדקס מחדש. ישנם מקרים שבהם דווקא פעולת אירגון יכולה למלא את הקובץ לוג. הייתרון הוא שניתן כאמור לבצע במספר פעמים ולכן נוכל לעצור ולבצע שוב.

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

    >> לגבי הבעיה שאתה מציג שקשורה ל NETAPP, אתה יכול לפנות אליהם ישירות יש להם איל טלפו בישראל: ‎03 920 5555. אין לי שום כלי לבדוק את הבעיה אבל סתם ככה מהרגשה הייתי זורק את המילה snapshot או VSS (שעש למעשה שימוש ב snapshot)... זה מזכיר לי את העניין של "נמיתוק של עד כמה שניות, אבל זו סתם זריקה בלי בסיסי :-)

    טוב... מספיק להיום..
    אני מקווה שזה היה מועיל :-)

    אני אחפש כמה קישורים מהר ואוסיף בעוד כמה שניות

    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]


    • נערך על-ידי pituachMVP, Editor שבת 01 אוגוסט 2015 03:21
    • סומן כתשובה על-ידי כהן יניב יום ראשון 02 אוגוסט 2015 13:46
    שבת 01 אוגוסט 2015 03:20
    מנחה דיון
  • קישורים שכדאי לעזור עליהם בנושא זה!

    1. מאמר נהדר הכולל הסבר מקוצר על מבנה הנתונים מאחורי הלקעים. מאמר חובה כשאר מתחילים לדון על ה INTERNALS
    https://www.simple-talk.com/sql/database-administration/brads-sure-guide-to-indexes/

    2. מאמר מאוד נחמד וקליל על ההבדלים בין הפעולות
    http://blogs.msdn.com/b/pamitt/archive/2010/12/23/notes-sql-server-index-fragmentation-types-and-solutions.aspx

    3. מאמר שפונה לצד המעשי של בדיקות, כולל מסד נתונים והצגה של הדברים מבחינה מספרית מאחורי הקלעים בהסתמך על מס דנהתונים הזה. מאמר מאוד ישן ולא בדקתי אם מסד הנתונים בכלל עדיין ניתן להורדה:
    http://www.sqlskills.com/blogs/kimberly/indexes-in-sql-server-20052008-part-2-internals/

    4. המאמר הרשמי מה BOL של מייקרוסופט. נחמד מקקוצר אבל בדרך כלל אני לא את ה BOL כמקור לימודי
    https://msdn.microsoft.com/en-us/library/ms189858.aspx?f=255&MSPPError=-2147217396

    5. לסיום מאמר שנראה נחמד מאוד אם אם כי לא עברתי על כולו
    http://sqltouch.blogspot.co.il/2013/07/index-optimization-rebuild-and.html


    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]

    • סומן כתשובה על-ידי כהן יניב יום ראשון 02 אוגוסט 2015 13:48
    שבת 01 אוגוסט 2015 03:28
    מנחה דיון

כל התגובות

  • בוקר טוב,

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

    * אם דנים במקום שצריך בדיסק בשביל העותק של האינדקס אז חשוב מאוד להבין כמה מקום תופס האינדקס עצמו! תוכל להעזר ב DMV הבא sys.dm_db_index_physical_stats על מנת לקבל יותר מידע על האינדקסים והמקום שהם תופסים כרגע (ככה תוכל לדעת כמה מקום אתה צריך בשביל העותק של האינדקס). כמובן שצריך לזכור שבנוסף למקום שצריך בשביל העותק, צריך גם מקום נוסף בשביל פעולת המיון וסידור הנתונים.

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

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

    Clustered
    Non-clustered
    Indexed view
    XML
    Filtered
    Spatial
    Compressed Indexes

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

    ** פעולת בנייה מחדש היא פעולה כבדה יחסית שנעשית כטרנזקציה בודד (Single Atomic Transaction), בעוד פעולת אירגון האינדקס אמורה להיות הרבה יותר קלה, מידע כן נרשם בלוג אבל ניתן לבצע אותה בשלבים ולעצור (הפעולה נעשית ב Small Discrete Transactions). למרות זאת כאשר המצב של האיחוי גרוע אז מהר יותר לבנות את האינדקס מחדש. ישנם מקרים שבהם דווקא פעולת אירגון יכולה למלא את הקובץ לוג. הייתרון הוא שניתן כאמור לבצע במספר פעמים ולכן נוכל לעצור ולבצע שוב.

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

    >> לגבי הבעיה שאתה מציג שקשורה ל NETAPP, אתה יכול לפנות אליהם ישירות יש להם איל טלפו בישראל: ‎03 920 5555. אין לי שום כלי לבדוק את הבעיה אבל סתם ככה מהרגשה הייתי זורק את המילה snapshot או VSS (שעש למעשה שימוש ב snapshot)... זה מזכיר לי את העניין של "נמיתוק של עד כמה שניות, אבל זו סתם זריקה בלי בסיסי :-)

    טוב... מספיק להיום..
    אני מקווה שזה היה מועיל :-)

    אני אחפש כמה קישורים מהר ואוסיף בעוד כמה שניות

    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]


    • נערך על-ידי pituachMVP, Editor שבת 01 אוגוסט 2015 03:21
    • סומן כתשובה על-ידי כהן יניב יום ראשון 02 אוגוסט 2015 13:46
    שבת 01 אוגוסט 2015 03:20
    מנחה דיון
  • קישורים שכדאי לעזור עליהם בנושא זה!

    1. מאמר נהדר הכולל הסבר מקוצר על מבנה הנתונים מאחורי הלקעים. מאמר חובה כשאר מתחילים לדון על ה INTERNALS
    https://www.simple-talk.com/sql/database-administration/brads-sure-guide-to-indexes/

    2. מאמר מאוד נחמד וקליל על ההבדלים בין הפעולות
    http://blogs.msdn.com/b/pamitt/archive/2010/12/23/notes-sql-server-index-fragmentation-types-and-solutions.aspx

    3. מאמר שפונה לצד המעשי של בדיקות, כולל מסד נתונים והצגה של הדברים מבחינה מספרית מאחורי הקלעים בהסתמך על מס דנהתונים הזה. מאמר מאוד ישן ולא בדקתי אם מסד הנתונים בכלל עדיין ניתן להורדה:
    http://www.sqlskills.com/blogs/kimberly/indexes-in-sql-server-20052008-part-2-internals/

    4. המאמר הרשמי מה BOL של מייקרוסופט. נחמד מקקוצר אבל בדרך כלל אני לא את ה BOL כמקור לימודי
    https://msdn.microsoft.com/en-us/library/ms189858.aspx?f=255&MSPPError=-2147217396

    5. לסיום מאמר שנראה נחמד מאוד אם אם כי לא עברתי על כולו
    http://sqltouch.blogspot.co.il/2013/07/index-optimization-rebuild-and.html


    signature   Ronen Ariely
     [Personal Site]    [Blog]    [Facebook]

    • סומן כתשובה על-ידי כהן יניב יום ראשון 02 אוגוסט 2015 13:48
    שבת 01 אוגוסט 2015 03:28
    מנחה דיון