פוסטים

ההשפעה של no logging על data guard

כבר כתבתי בעבר על הקמה של data guard ואחד הדברים שציינו במפורש זה שרצוי מאוד להשתמש ב-force logging כדי להימנע מבעיות של טבלאות שנטענות ב-no logging.

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

המשך קריאה…

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

בפוסט הקודם הסברתי על התהליך שקורה בזמן שאנחנו מבצעים טרנזאקציות. דיברנו על מנגנון ה-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).

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

המשך קריאה…

שינוי קבצי redo log בסביבה של data guard

לא מזמן הייתי אצל לקוח שהיה צריך לשנות את גודל קבצי ה-Redo Logs שלו בסביבה שבה היו מספר בסיסי נתונים של data guard.
שינוי גודל קבצי ה-redo log לא אמורה להיות בעיה קשה או מסובכת במיוחד אבל כאשר מוסיפים את האלמנט של Data Guard אחד (או יותר) זה הופך להיות קצת יותר מאתגר.
אז איך מבצעים את הפעילות?

המשך קריאה…

שימוש ב-Append ו-redo logs

הייתי היום בכנס ilOUG שיוחד לנושאי Data Warehouse ומכוון שהנושא קרוב לליבי (עדיין, כמעט שלוש וחצי שנים ב-DWH של פרטנר) הלכתי לשמוע מה יש בנושא ונהנתי מאוד.

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