אינדקסים חלק 2 - ilDBA Portal

אינדקסים חלק 2

19/12/2011 | פורסם על ידי

בחלק הראשון דיברנו על המבנה של האינדקס ואיך מחפשים בו.
תזכורת למי שפיספס: חלק 1
בחלק זה נתחיל להיכנס לנושאים ספציפיים יותר בשימוש של אינדקס ב- Oracle.

כמה מקום אינדקס תופס?

ראינו איך אינדקס בנוי, עכשיו אפשר להבין כמה מקום הוא תופס. מכיוון שהעץ מאד רחב, אז מספר הצמתים שהם לא עלים קטן יחסית למספר העלים (למשל, אם לכל צומת יש 100 ילדים, אז בעץ מלא של 3 רמות יש root אחד, 100 צמתים נוספים ו- 10000 עלים. כלומר בעץ עם 10101 צמתים, רק 101 הם לא עלים שזה אחוז אחד). בעלים, כמו שאמרנו, יש את הערכים עצמם ו- ROWID לכל רשומה.

כדי לדעת את גודל האינדקס אנחנו צריכים לדעת את הדברים הבאים:

  1. גודל כולל של כל הערכים המאונדקסים. אפשר לחשב על ידי הפונקציה vsize שמחזירה את הגודל האמיתי של הערך בבתים. אפשר גם להעריך על ידי גודל הערך כפול מספר הרשומות (זה כמובן מדויק אם גודל העמודה קבוע כמו עמודה מסוג char או date).
  2. גודל כולל של ערכי ROWID. את זה קל לדעת כי ROWID הוא בגודל קבוע של 10 בתים, ולכן צריך להכפיל את מספר הרשומות ב- 10.
  3. PCTFREE של האינדקס. גם באינדקס אפשר להגדיר PCTFREE לצורך עדכונים וגם אותו צריך כמובן לקחת בחשבון כשמחשבים גודל של אינדקס.
  4. על כל אלה צריך להוסיף עוד מקום, עבור הצמתים שהם לא עלים וכל מיני header-ים שלא דיברנו עליהם ושיש בבלוקים השונים. המספר הזה משתנה (למשל בגלל שאנחנו לא יודעים בדיוק כמה צמתים שהם לא עלים יש וכו'). בסה"כ נעריך את זה בעוד 15-20%.

דוגמא:

בדוגמא שנציג ניקח שדה מסוג date עם מיליון רשומות. החישוב הוא די פשוט לשדה כזה כי date הוא בגודל קבוע של 7 בתים ולכן כל הערכים שאמורים להיות באינדקס מסתכמים לכ- 7MB :

SQL> select sum(vsize(mydate)) size_in_bytes from ildba;

SIZE_IN_BYTES
-------------
7000000

על זה צריך להוסיף עוד כ- 10MB של ROWID למיליון רשומות, 10% של PCTFREE (שזה ה- default) ועוד 15-20%, ככה שהחישוב מביא אותנו לקצת יותר מ- 20MB.

בואו נראה מה גודל של אינדקס שניצור:

SQL> create index ildba_idx on ildba(mydate);

Index created.

SQL> select bytes/1024/1024 index_size
2    from user_segments where segment_name='ILDBA_IDX';
INDEX_SIZE
----------
22

ולסיום החלק הזה, אם ניצור את אותו אינדקס רק עם PCTFREE 0 החישוב הנ"ל מביא אותנו לקצת פחות מ- 20MB:

SQL> drop index ildba_idx;

Index dropped.

SQL> create index ildba_idx on ildba(mydate) pctfree 0;
Index created.

SQL> select bytes/1024/1024 index_size
2    from user_segments where segment_name='ILDBA_IDX';
INDEX_SIZE
----------
19

האם יש השפעה של גודל בלוק על מבנה האינדקס?

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

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

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

דוגמא:

בדוגמא נראה אינדקס שבגודל בלוק של 8KB יהיה בעל שתי רמות. אחרי שנבנה אותו מחדש ב- tablespace עם בלוקים בגודל 16KB האינדקס יהיה בעל רמה אחת בלבד.

SQL> select count(*) from ildba;
COUNT(*)
----------
512

SQL> create index ildba_idx on ildba(mydate) compute statistics;
Index created.

SQL> select index_name,blevel from user_indexes;
INDEX_NAME                         BLEVEL
------------------------------ ----------
ILDBA_IDX                               1

SQL> alter index ildba_idx rebuild tablespace tbs_16k;
Index altered.

SQL> exec dbms_stats.gather_index_stats(user,'ILDBA_IDX');
PL/SQL procedure successfully completed.

SQL> select index_name,blevel from user_indexes;
INDEX_NAME                         BLEVEL
------------------------------ ----------
ILDBA_IDX                               0

סיכום חלק 2

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

אז נתראה בחלק השלישי של הסדרה, והפעם על rebuild של אינדקסים.

מקווה שנהניתם.

נתראה ברשומה הבאה !

לירון אמיצי.

ניתן ליצור קשר עם לירון דרך עמוד האודות שלו: אודות.

The following two tabs change content below.
ירון אמיצי הוא סמנכ"ל שירותי מומחה בחברת בריליקס ו-DBA בכיר בעל נסיון של למעלה מ- 15 שנים. ללירון תואר Oracle Ace ומתמחה בנושאי ביצועים, תשתיות, פתרונות זמינות גבוהה, גיבויים ושחזורים. ללירון יש גם בלוג עצמאי בכתובת: https://amitzil.wordpress.com

6 תגובות ל- “אינדקסים חלק 2”

טל ברדה | 30/12/2011 בשעה 00:54
commenter

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

טל ברדה | 30/12/2011 בשעה 00:57
commenter

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

commenter

אהלן טל,

תודה על ההערה, לא הסברתי את הנושא כמו שצריך במאמר. ה- PCTFREE באינדקס הוא המקום שאורקל משאיר פנוי בכל בלוק של האינדקס בזמן הבניה (הראשונית או פעולת rebuild). כלומר, אם יש לי טבלה מלאה ואני בונה עליה אינדקס, בכל בלוק באינדקס יהיה 10% מקום פנוי (זאת ברירת המחדל) כדי לאפשר לאורקל להכניס עוד ערכים (ערכים חדשים במקום הזה באינדקס שיכולים לנבוע מפעולות insert או update לטבלה עצמה).

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

מקווה שזה יותר ברור.

לירון

[…] תזכורת של המאמרים הקודמים: חלק 1, חלק 2 […]

[…] של המאמרים הקודמים: חלק 1, חלק 2, חלק […]

[…] תזכורת של המאמרים הקודמים: חלק 1, חלק 2 […]

השאר תגובה:

שם (חובה):
אימייל (לא יפורסם) (חובה):
תגובה (חובה):

*



מאמרים קשורים

Baruch Osoveskiy

תיקון מהיר לדיסק איטי

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

OS Background operations

אורי לרנר בטיפ קצר ושימושי על העברת פעולות לרקע במערכת [...]
רשימת

רשימת הפיצ'רים החדשים של אורקל 12.1

אורקל פרסמו את הספרות הרשמית לגרסה 12.1 שיצאה לאחרונה וזמינה להורדה. בין שאר הספרים (החשובים כל אחד שלעצמו), פורסם הספר המסקרן ביותר בעיני – Oracle Database 12c Release 1 (12.1) New Features. זהו ספר שראוי שכל DBA [...]
גרסת

גרסת אורקל 12c זמינה להורדה

בשעה טובה ולאחר המתנה סופר ארוכה, גרסת אורקל 12c (גרסה 12.1) זמינה סוף סוף להורדה רשמית מהאתר של אורקל. הגרסה החדשה מנסה לתת פתרונות לעולם ה"ענן" – ומוסיפה פיצ'רים חדשים שבאים לתת מענה בדיוק [...]
Copyright 2019 ilDBA Portal. Brought to you by Brillix - Israel Leading DBA company. Sponsored by: DBSnaps - Database Video Tutorialss
Website Security Test
%d בלוגרים אהבו את זה: