פוסטים שנכתבו על ידי זהר אלקיים

עולם ה- Big Data ופתרון ה- Hadoop – מאמר מתוך Oracle Newsletter

לאחרונה פורסם מאמר שכתבתי ל-Oracle Newsletter בנושא Big Data ו-Hadoop. המאמר התחלק לשני חלקים: החלק הראשון הוא תאור כללי של Big Data ו-Hadoop והחלק השני הוא תיאור הפתרון של אורקל לנושא.

מצורף המאמר להנאתכם:

עולם ה-Big Data ופתרון ה- Hadoop

כמויות המידע שנוצרות מדי יום הן בלתי נתפסות. לאור הדרישות שהולכות ומתגברות, אנחנו נתקלים בעולם חדש עם המון buzzwords. מבין כל המונחים החדשים אנחנו שומעים שוב ושוב על Big Data ו-Hadoop ונראה שהטכנולוגיות הללו ייקחו חלק חשוב בעתיד הנראה לעין.

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

המשך קריאה…

הקלטה של וובינר – מבוא ל-Data Guard Broker

לפני שבועיים בערך העברתי וובינר במסגרת ilDBA בנושא מבוא ל-Data Guard Broker.

הוובינר היה מאוד מוצלח – הגיעו לא מעט אנשים והפידבקים שקיבלתי היו חיוביים. תודה רבה לכל מי שהשתתף!

הבטחתי להעלות את המצגת + הוידאו של הוובינר לאתר והנה אני גם מקיים… 🙂

תהנו!

המשך קריאה…

כמה מילים על bind peeking ואיך למחוק Execution Plan מה-Library Cache

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

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

אחד הדברים הקשים ביותר לכוונון בעיני זה שליפות שלפעמים עובדות מהר ולפעמים לא ובתת הקטגוריה הזו, שליפות שמתנהגות ככה אבל לכולן יש את אותו ה-SQL ID ואותו Execution Plan (באותה סביבה, כמובן). איך דבר כזה יכול לקרות? לדוגמה אם משתמשים ב-Bind Variables אז התוכנית של השליפה מתוכננת על ידי ה-Optimizer פעם אחת וכל השליפות שבאות אחריה עושות soft parse וחוסכות לעצמן את הצורך ב-parse מיותר.
כל זה טוב ויפה אבל איך האופטימייזר יודע להעריך כמויות רשומות ותוכנית יעילה? בגרסה 9i נוספה תכונה מעניינת: Bind Peeking. האופטימייזר שנתקל בשליפה עם bind variables בפעם הראשונה "מציץ" לתוך המשתנים האלה, רואה איזה ערכים יש שם ומשתמש בהם כדי לקבוע תוכנית פעולה לשליפה שלנו.

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

רגע, רגע, מה?!
המשך קריאה…

התנהגות מוזרה של ה-DG Broker ב-startup mount

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

כמו שעשיתי מאות פעמים בעבר, הורדתי את בסיס הנתונים בצורה מסודרת באמצעות sqlplus ו-shutdown immediate, העלתי את בסיס הנתונים באמצעות startup mount אבל בסיס הנתונים נפתח למצב Open:

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.

Total System Global Area 778387456 bytes
Fixed Size 1374808 bytes
Variable Size 461374888 bytes
Database Buffers 310378496 bytes
Redo Buffers 5259264 bytes
Database mounted.
SQL>
SQL> select status from v$instance

STATUS
------------
OPEN

מוזר, מה פה קורה פה?

המשך קריאה…

יצירת Data Guard באורקל 11 – הדרך המהירה (דמו משבוע אורקל 2011)

כמו שהבטחתי, הנה החלק הראשון בדמו של יצירת מערך Data Guard באורקל 11. אם יש למישהו הערות, אני אשמח לשמוע. בנוסף, אני מצרף את הקובץ של ה-demo שהשתמשנו בו בפועל ואין כמעט הסברים – כל ההסברים הנדרשים יהיו פה או במצגת.

הערה קטנה לפני שנתחיל – אנחנו נשתמש בשיטה שקיימת רק באורקל 11 וזה שכפול הסביבה on-line דרך RMAN מבלי לקחת גיבוי לקבצים קודם. ניתן להשתמש בשיטה הזו אם בסיס הנתונים קטן יחסית או אם הרשת בין השרתים מספיק חזקה כדי לבצע כזו פעולה של שכפול בסיס הנתונים. זו השיטה הפשוטה ביותר שאני מכיר להקים כזו סביבה והיא גם אחת המהירות שבהן. אם תהיה דרישה אני אעלה גם הסבר איך מקימים Data Guard בקונפיגורציות אחרות (לדוגמה לא דרך DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE או באורקל 10).

כמו שמוסבר במצגת, הקמת הסביבה מתחלקת לשישה שלבים:

  1. הכנת שרת ה-Primary.
  2. הכנת פרמטרים בבסיס הנתונים הראשי.
  3. קונפיגורציית רשת של אורקל בשני השרתים.
  4. העלאת בסיס הנתונים המשני בקוניפגורציה מינימלית.
  5. יצירת בסיס הנתונים המשני (on-line).
  6. הפעלת ה-Data Guard לגילגול Archive-ים.

המשך קריאה…