ה Instance עצמו מורכב משני חלקים עיקריים : ה – SGA וה – Background Processes

באופן כללי – ה SGA מכיל בתוכו את כל רכיבי הזכרון השונים אשר למעשה מרכיבים את ה"מח", את ה Instance.עם זאת ה Instance מקיים אינטראקציה בלתי פוסקת עם ה Database (בדיוק כפי שהמח שלנו מקיים אינטראקציה בלתי פוסקת עם הגוף שלנו) ולכן בשלב מסויים נתונים חייבים לרדת מה Instance ל Databaseועל אותו משקל בשלב מסויים נתונים חייבים לעלות מה Database ל Instance.
כאן נכנסים לתמונה ה Background Process – אשר מטרתם העיקרית היא ניווט המידע בין החלק הלוגי לפיזי (ולהיפך)

SGA – System Global Area

מכיל את רכיבי הזכרון העיקריים הבאים

1. Shared Pool
2. Buffer Cache
3. Redo Log Buffer

Shared Pool – שמירת תוכניות פעולה.

כאשר אנו רוצים להגיע מיעד אחד ליעד אחר, נאמר מת"א לבאר שבע, עומדים בפנינו מסלולים גישה שונים. אנו צריכים להסתמך על אינפורמציה שונה (דיווחי תנועה, Waze, חבר שכבר תקוע בפקקים) כדי לחשב את תוכנית הפעולה היעילה ביותר.

כאשר אנו מריצים פקודות SQL, אורקל (וליתר דיוק ה Oracle Optimizer) מסתמך על אינפורמציה פנימית ומחשב עבורנו את צורת הפעולה היעילה ביותר (למשל ניתן לגשת לטבלה באמצעות סריקת כל הטבלה או באמצעות אינדקס )

לאחר שאורקל בונה תוכנית פעולה מסויימת (אשר נקראת Execution Plan) הוא בוחר לשמור אותה כך שאם אדם נוסף יריץ את אותה שאילתה – תוכנית הפעולה תהיה קיימת בזכרון כבר ולא יהיה צורך לבנות אותה מחדש. המקום בזכרון בו תוכניות הפעולה נשמרות נקרא ה Shared Pool

Buffer Cache – כי I/O לוגי הוא סוס מנצח.

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

ה Buffer Cache הוא הזכרון של ה Database אשר שומר את המידע עצמו.
לדוגמא אם שלפנו את שכרו עובד מס' 100 – ה Buffer Cache ישמור בתוכו את השכר עצמו, (את הערך 100 עבור אותו עובד). כך שאם יהיה אדם נוסף אשר יצטרך את אותו נתון – המידע כבר יושב בזכרון, הפעולה תהיה הרבה יותר מהירה.

• כאשר אנו צריכים לבצע שליפת נתון אשר יושב פיזית על הדיסק – אנו מכנים את הפעולה Physical I/O
• כאשר אנו צריכים לבצע שליפת נתון אשר יושב לוגית בזכרון – אנו מכנים את הפעולה Logical I/O.
• I/O לוגי תמיד יהיה יותר מהיר מ I/O פיזי.

גם פעולות DML (כגון Update ) נעשות בזכרון. משמעות הדבר שאם נעדכן לעובד מסויים את השכר (נשנה לו את השכר מ 100 ל 200), השכר שלו ישתנה רק בזכרון ולא בדיסק.
גם כשאנחנו עושים COMMIT, העדכון נעשה רק בזכרון. משמעות הדבר שפעולות עדכון על טבלאות יטוסו ! כי שוב, הכל מתבצע בזכרון.

שלבים בתהליך פעולת SELECT  מנקודת הראות של  ה Buffer Cache

1. .User Processמריץ שאילתה ופונה בבקשה ל Server Process ע”מ שיבצע אותה.
2. .ה Server Process בודק אם המידע קיים ב Buffer Cache
3. אם האינפורמציה נמצאת כבר ב Cache האירוע נקרא Cache Hit והנתונים חוזרים User Process
4. .אם הוא לא בזכרון, האירוע נקרא Cache Miss ואז :
5. ה Server Process הולך ל Data Files ומושך משם את הנתונים.
6. האינפורמציה נשמרת ב .Cache
7. הנתונים של השאילתה חוזרים ליוזר.

לסיכום

• I/O לוגי תמיד יהיה יותר מהיר מ I/O פיזי.
• כאשר נבצע פעולת SELECT הנתונים יעלו לזכרון וישלפו פעם הבאה משם.
• כאשר נבצע פעולת DML העדכון יתבצע בזכרון, לא בדיסק, באופן כללי אורקל מחליט לבד מתי להעביר את המידע מהזכרון לדיסק.

ה Redo Log Buffer – להיות בלי, להרגיש עם.

אמרנו שה Shared Pool מבצע את כל פעולות העדכון על הטבלאות בזכרון, ואמרנו שאורקל מוריד את המידע לדיסק מתי ש"מתחשק לו".
מה יקרה אם נבצע פעולת עדכון, נציין Commit, ואז באותה שניה המערכת תקרוס ? (עוד לפני שלאורקל התחשק להוריד את המידע לדיסק) הלכו הנתונים ?
כאן נכנס לתמונה האביר על הסוס הלבן ששמו ה Redo Log Buffer.
במבט ראשון ה Redo Log Buffer מאוד פשוט – תפקידו מורכב משני חלקים:

א. כתיבת לוג סדרתית – בכל פעם שמתבצעת פעולת DML – ה Redo Log Buffer רושם את הפעולה שהתבצעה בלוג, מישהו עשה Update הוא כותב את ה Update שהתבצע אצלו בלוג, מישהו מבצע Insert הוא כותב את ה Insert שהתבצע אצלו בלוג וכן הלאה.

ב. כתיבת מה Redo Log Buffer ל Redo Log File – בכל פעם שמתבצע Commit (וכן במצבים אחרים שפחות רלוונטיים כרגע) ה Redo Log Buffer מעביר את התוכן שלו לקובץ הנקרא Redo Log File.

ה Redo Log File הוא קובץ פיזי שיושב במערכת הקבצים של ה Database ומכיל את מה שה Redo Log Buffer העביר לו.

אם תתרחש קריסה (לפני שאורקל הספיק לכתוב לדיסק) בעלייה הבאה של ה Database אורקל יבין שהיתה קריסה וישתמש בנתונים של ה Redo Log File כדי לבצע Redo לכל הפעולות שעדיין לא נכתבו לדיסק וכך ישחזר את ה Database למצב שבו היה לפני הקריסה (עד ה COMMIT האחרון). זוהי מטרתו העיקרית של ה Redo Log Buffer – יכולת שחזור במקרה של קריסה.