ברוך שלח לי את הסרטון האדיר הבא. הוא לא ממש קשור לבסיסי נתונים ישירות אבל הוא עדיין שווה צפיה.
מדובר בסרטון שמסביר איך עובדים כל מיני סוגים של מיונים בצורה ויזואלית במיוחד ואפילו עם סאונד.
אני מפנה אתכם ל-1:06 – שם יש ויזואליזציה של merge sort שאורקל מהשתמש בו לפעמים בכל מיני סיטואציות…
המשך קריאה… →
עד אורקל 12, כאשר רצינו לשלוף את N הרשומות הראשונות (או אחרונות) של שליפה היינו צריכים לעשות מאמץ מיוחד: לשלוף את הרשומות, לפלטר אותן לתוכן הרלוונטי, למיין את הרשומות ואז לפלטר אותן שוב ל-N הרשומות הרלוונטיות. בחלק מהמקרים, הדבר הזה לא נעשה בצורה הנכונה ואז הרשומות שלנו לא חזרו בסדר הנכון או שהדבר לקח יותר מדי משאבים.
החל מגרסה 12, אורקל עושים זאת שוב ופותרים לנו את הבעיה בהינף פקודה. הפקודה החדשה היא הרחבה של פקודת ה-Select הרגילה והיא נראית ככה:
[ OFFSET offset { ROW | ROWS } ]
[ FETCH { FIRST | NEXT } [ { rowcount | percent PERCENT } ]
{ ROW | ROWS } { ONLY | WITH TIES } ]
למעדיפים את התיעוד הרשמי, אז זה נמצא כאן.
עוד אחד מהפיצ'רים האלה שאנחנו מיישמים בצורה ידנית עד שבאים אורקל ופותרים לנו את הבעיה בהינף פקודה אחת…
עד גרסה 12, אם היינו רוצים עמודה שתקבל ערכים בצורה עצמאית (לדוגמה מספר רץ למספר הזמנה או משהו דומה) היינו צריכים לבוא וליישם את זה בעצמנו. היינו צריכים להגדיר sequence, היינו צריכים להגדיר trigger שידאג לטפל בטבלה או שהיינו מגדירים קוד חיצוני שיטפל בהכנסת ערכים לעמודה (פונקצית הכנסה לטבלה וכו').
החלק מגרסה 12 נוסף פיצ'ר נחמד שמטפל בכל הדברים האלה בעצמו.
בפוסט הקודם שלי כתבתי על יצירה במקביל של אינדקסים על אותן עמודות וציינתי בין היתר שניתן ליצור את האינדקסים רק אם משנים חלק ממאפייני הרקע שלהם. כדוגמה נתתי את Reverse Key Index ונשאלתי במה מדובר.
מכוון שהאינדקס הזה נמצא איתנו כבר לא מעט זמן (אורקל 8 אם אני זוכר נכון) הוא עדיין לא מאוד נפוץ והרגשתי שזה יהיה מעניין לכתוב קצת על אינדקסים באופן כללי ועל האינדקס הזה בפרט.
המשך קריאה… →
לאחרונה התעורר אצל לקוח צורך לעשות הסבה של אינדקס על טבלה עם פרטישנים מפורמט של אינדקס אחד גלובלי (כזה שיש אחד לטבלה והוא מצביע למידע בכל הפרטישנים) לפורמט של אינדקס מקומי (מבנה אינדקס לכל אחד מהפרטישנים בנפרד).
הבעיה עם הפעילות הייתה שהאינדקס החדש שרצינו ליצור הכיל את אותן עמודות של האינדקס הקודם. זה אמר שאם רצינו ליצור אינדקס נוסף, לא יכולנו – אורקל מניח (ובצדק) שאין משמעות לשני אינדקסים על אותן עמודות ובאותו סדר ולא מאפשר את זה (ORA-1408).
מה שהיינו צריכים לעשות בפועל זה לזרוק את האינדקס הישן וליצור את האינדקס החדש במקומו. הדבר הזה אמר לחיות כמה שעות בלי אינדקס על העמודות המרכזיות של הטבלה עד שהאינדקס יבנה מחדש ובעצם לפגוע משמעותית בצורה שבה האפליקציה עבדה. מה שיותר מסוכן בסיפור הזה הוא שלמרות הצורך שהתעורר, לא היינו בטוחים שהשינוי הזה בכלל יעזור לאפליקציה…
אז מה עושים?
המשך קריאה… →
לאחרונה נתקלתי אצל לקוח בתופעה מוזרה – למרות ששרתי הלקוח היו בארצות הברית, הזמנים שנרשמו על דגימות ה-AWR הופיעו עם שעות של ישראל. באופן עקרוני לא אמורה להיות בעיה עם כזה דבר (לפעמים זה אפילו דיי נוח) אבל כשמתחילים להשתמש ב-ASH אז "לפני שעתיים" מוגדר אצלו לפי אזור הזמן המקומי (שהוא לוס אנג'לס) ולא לפי זה שמתחשב בדגימה (שהוא ישראל).
כשעשינו דגימה ידנית, אז הדגימה נכנסה עם השעה של המשתמש המקומי (לוס אנג'לס) ואחר כך חזרה לדגימות לפי שעון ישראל:
instance 1: Instance DB Name Snap Id Snap Started Level ------------ ------------ --------- ------------------ ---- 8346 17 Mar 2014 17:00 1 8347 17 Mar 2014 08:07 1 8348 17 Mar 2014 17:30 1 instance 2: Instance DB Name Snap Id Snap Started Level ------------ ------------ --------- ------------------ ---- 8346 17 Mar 2014 17:00 1 8347 17 Mar 2014 17:07 1 8348 17 Mar 2014 17:30 1
מה שיותר בלבל את העניינים היה שמדובר היה ב-RAC כך שהזמן של הדגימה בשני השרתים לא היה אותו הדבר!
המשך קריאה… →