פוסטים

המדריך הבסיסי לטרנזאקציות באורקל

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

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

כדי לענות על השאלה הזו ישבו טובי המומחים באקדמיה והגדירו סטנדרט שנקרא ACID: Atomic, Consistent, Isolation, Durability. כדי להבין מה זה אומר, בואו ונפרק את ההגדרה:

  1. Atomic– טרנזאקציות ישמרו בצורה של הכול או כלום. אין חצי טרנזאקציה.
  2. Consistent– אם ביצענו מספר פעולות שתלויות אחת בשנייה אנחנו רוצים שהטרנזאקציה תשמור את הנתונים בצורה אמינה.
  3. Isolation– כל עוד אנחנו מבצעים טרנזאקציה, אף אחד לא צריך לדעת על זה.
  4. Durability– אם בסיס הנתונים שלנו נופל, אנחנו רוצים שכל המידע שביצענו לו commit יהיה שם גם אחרי שהוא יעלה בחזרה.

העניין הוא ש-ACID עולה לנו: הוא עולה לנו זמן והוא עולה לנו משאבים. מה קורה אם מה שחשוב לנו זה הביצועים ואנחנו מוכנים לוותר על אחד מעקרונות ה-ACID בתמורה לזמן ולמשאבים?

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

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

המשך קריאה…

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

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

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


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

סמינר שבוע אורקל: Deep Dive into Oracle NoSQL – המצגת

במסגרת שבוע אורקל העברתי אתמול סמינר על Oracle NoSQL זו השנה השנייה.  הסמינר נקרא Deep Dive into Oracle NoSQL Technologies and Solutions והוא מסביר על עולם ה-Big Data באופן כללי, מסביר מה זה NoSQL ומתמקד בפתרון מבית אורקל – Oracle NoSQL (אבולציה של מוצר שאורקל קנו כבר לפני 8 שנים בערך – SleepyCat). במסגרת הסמינר אנחנו יורדים ממש לפרטים – מהסבר כללי על איך זה עובד ועד הבנה של ה-Java API של המוצר כדי להבין תכונות שלו.

Oracle_NoSQLDatabase_Logo_650

להלן הסילבוס של הסמינר:

המשך קריאה…

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

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

מכוון שזה ספר שראוי מאוד להתעמק בו, אני אפרסם לעת עתה רק את הקישורים לכותרות.
עיון מעמיק יותר אני אעשה בהמשך (עדיין, מדובר בספר של למעלה מ-120 עמודים) ואציין נקודות חשובות יותר או פחות בעיני. בנתיים, שימו לב לסעיף 1.4.1.3: Multitenant Architecture – בעיני זה אחד הפיצ’רים המסקרנים ביותר וכנראה גם אחד מהשינויים המשמעותיים ביותר בגרסה החדשה.

המשך קריאה…

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

בשעה טובה ולאחר המתנה סופר ארוכה, גרסת אורקל 12c (גרסה 12.1) זמינה סוף סוף להורדה רשמית מהאתר של אורקל. הגרסה החדשה מנסה לתת פתרונות לעולם ה”ענן” – ומוסיפה פיצ’רים חדשים שבאים לתת מענה בדיוק לנקודה הזו. לקריאה נוספת: Plug into the Cloud with Oracle Database 12c.

הפיצ’רים הבולטים ביותר (מתוך האתר של אורקל, הרשימה המלאה תפורסם בפוסט נפרד): המשך קריאה…

Oracle Restart – לניהול בסיס נתונים Single Node

לאחרונה יוצא לי להתעסק באופן כמעט בלעדי עם שרתי RAC של אורקל. אני מאוד אוהב את התשתית של ה-grid – במיוחד מאז שהיא עברה מהפכה קטנה בין גרסאות 10 ו-11 ועכשיו היא הפכה למוצר נוח ויציב בהרבה ממה שהוא היה קודם. אחד הדברים היפים שאני אוהב במיוחד בתשתית הזו הוא תהליך העליה של הקלסטר.

כאשר מדברים על עליה של בסיס נתונים, ביצוע Startup ואז הפעלה של ה-listener בדרך כלל מכסים 99 אחוז מתהליך העליה. לעומת זאת, כאשר חושבים על עליה של cluster, מדובר על לא מעט תהליכים שצריכים לעלות בצורה מדורגת, מסודרת ובאופן שתלוי אחד בשני. הכוונה היא שברור שלא יעלה על הדעת שמנגנוני ה-cluster לא יעלו לפני רכיבים בכל שרת בנפרד או ש-Disk groups של ASM יעלו אחרי בסיס הנתונים הרגיל. אם זה היה קורה אז בסיס הנתונים היה עולה (או לא) לפי גחמות מערכת ההפעלה.

הפתרון שאורקל נותנים לעליה של ה-grid הוא תהליך המנוהל על ידי root (בלינוקס) ומעלה את התהליכים לפי ההגדרות של resource-ים ו-service-ים. זה דורש קצת התרגלות אבל ברגע שמתרגלים מדובר ביכולת נהדרת שקשה לשחזר אותה בצורה המסורתית של העבודה. כל זה טוב ויפה אם יש לנו סביבה של RAC, אבל מה קורה כאשר יש לנו שרת ב-Stand alone (כלומר, לא קלסטר)?

המשך קריאה…