פוסטים

איך אורקל מצליחים לקרוא 2.5 מיליארד רשומות בשנייה

הפוסט הזה פורסם לראשונה ב-ilDBA: איך אורקל מצליחים לקרוא 2.5 מיליארד רשומות בשנייה. אני מעתיק אותו גם לכאן לצורך התיעוד. אם הגעתם עד כאן, תנו קפיצה קלה ל-ilDBA ופרגנו לנו גם שם… 🙂

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


במסיבת עיתונאים שנערכה שלשום בערב (10 ביוני 2014) בסן פרנסיסקו, הכריז לארי אליסון על התכונה החדשה ביותר שמתווספת לאורקל 12c – ה-In Memory Option. ההכרזה אומנם הייתה שלשום אבל השחרור הרשמי של הפיצ’ר לקהל החדש יהיה רק בעוד חודש.
הטכנולוגיה החדשה היא אחת המסקרנות ביותר – זוהי הטכנולוגיה שאמורה להפוך את גרסת אורקל 12c שיצאה כבר לפני שנה למובילה הטכנולוגית המובהקת בתחום בסיסי הנתונים.
המשך קריאה…

שינוי בגרסה 12: שינוי רוחב מקסימלי עמודה מסוג varchar2

עד גרסה 12 הייתה לנו בעיה קטנה. אם היינו יוצרים קוד ב-PL/SQL, היינו יכולים להגדיר משתנים מסוג varchar2 באורך של עד 32K תווים וזה עבד בסדר גמור. העניין הוא ש-varchar2 של pl/sql ושל sql לא היה אותו דבר וזה היה גורם לנו לעיתים קרובות לבעיות.

החל מגרסה 12 ניתן להגדיר בבסיס הנתונים ש-varchar2 של sql הוא גם עד 32k ובכך ליישר קו בין השפות.
המשך קריאה…

פיצ’ר חדש: הרצת קוד PL/SQL המקושר לשליפה

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

עד גרסה 12, הפתרון היה פשוט – הולכים על פונקציית PL/SQL: כותבים פונקציה, שומרים אותה בבסיס הנתונים ואז משתמשים בה.

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

פיצ’ר חדש: שליפות Top-N בלי מאמץ (כמעט)

עד אורקל 12, כאשר רצינו לשלוף את N הרשומות הראשונות (או אחרונות) של שליפה היינו צריכים לעשות מאמץ מיוחד: לשלוף את הרשומות, לפלטר אותן לתוכן הרלוונטי, למיין את הרשומות ואז לפלטר אותן שוב ל-N הרשומות הרלוונטיות. בחלק מהמקרים, הדבר הזה לא נעשה בצורה הנכונה ואז הרשומות שלנו לא חזרו בסדר הנכון או שהדבר לקח יותר מדי משאבים.

החל מגרסה 12, אורקל עושים זאת שוב ופותרים לנו את הבעיה בהינף פקודה. הפקודה החדשה היא הרחבה של פקודת ה-Select הרגילה והיא נראית ככה:

[ OFFSET offset { ROW | ROWS } ]
[ FETCH { FIRST | NEXT } [ { rowcount | percent PERCENT } ]
    { ROW | ROWS } { ONLY | WITH TIES } ]

למעדיפים את התיעוד הרשמי, אז זה נמצא כאן.

המשך קריאה…

פיצ’ר חדש: עמודת Identity

עוד אחד מהפיצ’רים האלה שאנחנו מיישמים בצורה ידנית עד שבאים אורקל ופותרים לנו את הבעיה בהינף פקודה אחת…

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

החלק מגרסה 12 נוסף פיצ’ר נחמד שמטפל בכל הדברים האלה בעצמו.

המשך קריאה…

פיצ’ר חדש: המרה של אינדקסים באורקל 12c

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

הבעיה עם הפעילות הייתה שהאינדקס החדש שרצינו ליצור הכיל את אותן עמודות של האינדקס הקודם. זה אמר שאם רצינו ליצור אינדקס נוסף, לא יכולנו – אורקל מניח (ובצדק) שאין משמעות לשני אינדקסים על אותן עמודות ובאותו סדר ולא מאפשר את זה (ORA-1408).

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

אז מה עושים?
המשך קריאה…