כתבתי בפוסט הקודם על ה-SQL*UnLoader וסיפרתי איזה כלי מצוין זה. אני עדיין חושב שזה כלי מצוין אבל לצערי נתקלתי בו בבאג מעצבן שרציתי לספר עליו. עדיין אין פתרון לזה אבל העברתי את הפרטים למפתח (ואפילו קיבלתי תשובה באימייל שהוא יתקן את זה בגרסה הקרובה). אני מקווה שזה יקרה בקרוב.. 🙂
פעם פעם, מזמן מזמן, כתבתי על איך ניתן לייצר קבצי CSV על ידי שימוש בפיצ'רים של SQL*Plus ואחרי זה כתבתי עוד פוסט על איך ניתן לייצר קבצי CSV על ידי שימוש בקוד PL/SQL.
היום נדבר על כלי חיצוני (חינמי לשימוש לא מסחרי) שמאפשר לנו לתת לו מצד אחד שליפה (או סקריפט עם שליפה) ומצד שני לקבל קובץ CSV תקין למהדרין. התוכנה המגניבה הזו נקראת SQL*Unloader.
הכלי פותח על ידי FangXin Lou שהוא Oracle Ace מסין.
יוצא לי לאחרונה לקרוא ולכתוב הרבה לאחרונה על הפיצ'רים החדשים של אורקל 12c. לפעמים אני קורא על משהו שלא מושך את תשומת הלב שלי מספיק כדי לכתוב על זה באופן ישיר, אבל אחרי כמה שבועות אני נשאל איך מיישמים פונקציונליות בדיוק כזו ואז אני פתאום נזכר בפיצ'ר (ומתבעס שהוא בגרסה הבאה)…
בדיוק הדבר הזה קרה לי השבוע.
אחד הפיצ'רים שרפרפתי עליהם ולא מצאתי אותם מספיק שימושיים כדי לכתוב עליהם היא העובדה שהחל מאורקל 12c אפשר ליצור sequence ברמה של ה-Session. על פניו, לא נשמע כל כך מלהיב ואפילו לא מאוד שימושי – הרי מה כבר אפשר לעשות עם sequence כזה?
בפוסט הקודם הסברתי על התהליך שקורה בזמן שאנחנו מבצעים טרנזאקציות. דיברנו על מנגנון ה-isolation של אורקל ועל מנגנון ה-durability. בנוסף, תיארנו בעיה: במערכות שבהן יש הרבה מאוד טרנזאקציות קצרות שרצות במקביל נוצר עומס על קובץ ה-redo log.
הבעיה הזו עלולה להפוך להיות גורם מאוד משמעותי ולגרום לכך שתהיה לנו מערכת שחסומה מבחינת כמות הטרנזאקציות שהיא יכולה לבצע במקביל. למעשה זה לא משנה כמה תהליכי כתיבה נריץ במקביל, אם צוואר הבקבוק במקרה הזה יהיה המנגנון הטבעי של אורקל שאמור להגן עלינו מפני אובדן המידע לא נוכל להכניס יותר רשומות לבסיס הנתונים.
המשך קריאה… →
הפוסט הזה הוא הכנה לפוסט נוסף על הפרמטר commit_write. מכוון שהמאמר יצא ארוך במיוחד, פיצלתי אותם לשניים. בפוסט הזה נדבר על איך טרנזאקציות עובדות ובפוסט הבא נדבר על איך לעקוף את זה…
אורקל, כמו בסיסי נתונים יחסיים אחרים, מאפשר לנו עבודה עם טרנזאקציות – זה הבסיס למרבית המערכות שמבוססות על בסיסי נתונים. כשאנחנו עובדים עם טרנזאקציה, אנחנו רוצים שהנתונים שלנו ישמרו כמו שצריך אבל איך אנחנו מגדרים "כמו שצריך"?
כדי לענות על השאלה הזו ישבו טובי המומחים באקדמיה והגדירו סטנדרט שנקרא ACID: Atomic, Consistent, Isolation, Durability. כדי להבין מה זה אומר, בואו ונפרק את ההגדרה:
העניין הוא ש-ACID עולה לנו: הוא עולה לנו זמן והוא עולה לנו משאבים. מה קורה אם מה שחשוב לנו זה הביצועים ואנחנו מוכנים לוותר על אחד מעקרונות ה-ACID בתמורה לזמן ולמשאבים?
על פניו, לא מדובר במשהו חדש – כתבתי על זה גם בעבר בנושאים הקשורים ל-NoSQL. בפוסט הזה נדבר על התהליך שקורה מתחת לפני השטח כשעושים טרנזאקציה בבסיס הנתונים. הפוסט הבא יתמקד ב-Durability ואיך ניתן לשחרר קצת את החבל מהבחינה הזו באורקל (מבלי ללכת לפתרונות NoSQL).
לפני שנצלול לעסק, אזהרה: הפוסט הזה מדבר על נושאים שמשפיעים על האמינות של בסיס הנתונים. שינוי הפרמטרים וההתנהגות שיוזכרו בפוסט הזה ובפוסט הבא הן פעולות מסוכנות. אם אתם לא בטוחים במאה אחוזים שהבנתם את הסיכונים שקשורים לפרמטרים האלה, אל תשנו אותם ובכל מקרה אני לא אחראי לתוצאות.
בגרסה החדשה של אורקל (12c) נעשו כמה שינויים מעניינים במנגנון הותיק של ה-data guard. אחד הפיצ'רים שנוספו למנגנון הוא ה-FarSync – מנגנון שבא לעזור למערכות להעלות את רמת ההגנה שיש על המידע (Zero-Data-Loss) מבלי להשפיע על זמני התגובה של המערכת.
כדי להסביר את התכונה החדשה הזו, נעשה שיעור קצר בעולם ה-Data Guard וה-Protection modes שלו.
המשך קריאה… →