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

בעיה ב-SQL*UnLoader – ORA-24347

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

המשך קריאה…

מדריך ליצירת קובץ CSV באמצעות SQL*UnLoader

פעם פעם, מזמן מזמן, כתבתי על איך ניתן לייצר קבצי CSV על ידי שימוש בפיצ'רים של SQL*Plus ואחרי זה כתבתי עוד פוסט על איך ניתן לייצר קבצי CSV על ידי שימוש בקוד PL/SQL.

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

הכלי פותח על ידי FangXin Lou שהוא Oracle Ace מסין.

המשך קריאה…

פיצ'ר חדש: Sequence-ים ברמת ה-Session

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

בדיוק הדבר הזה קרה לי השבוע.

אחד הפיצ'רים שרפרפתי עליהם ולא מצאתי אותם מספיק שימושיים כדי לכתוב עליהם היא העובדה שהחל מאורקל 12c אפשר ליצור sequence ברמה של ה-Session. על פניו, לא נשמע כל כך מלהיב ואפילו לא מאוד שימושי – הרי מה כבר אפשר לעשות עם sequence כזה?

המשך קריאה…

איך משפרים מהירות של טרנזאקציות (הפתרון המסוכן)

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

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

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

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

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

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

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

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

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

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

המשך קריאה…