در مطلب قبلی در مورد ساختار instance صحبت کردیم و گفتیم که SGA بخشی از instance اوراکل است که میان تمامی فرایندهای پس زمینه و فریندهای سرور به صورت اشتراکی است. در این مطلب می خواهیم در مورد چند مورد از مولفه های SGA صحبت کنیم. زمانی که اوراکل را نصب می کنید اواکل به صورت پبشفرض بخشی از فضای حافظه اصلی را بر حسب مگابایت برای SGA در نظر می گیرد و هر زمان که instance آغاز شود، اوراکل SGA را ایجاد می کند.

در مطالب مربوط به مدیریت حاظه (oracle memory management) در مورد چگونگی مدیریت حافظه صحبت می کنیم ولی برای اینکه شما آشنا شوید باید بگوییم که در اوراکل یک پارامتر به نام memory_target و memory_max_target وجود دارد که میزان SGA را تعیین می کنند.

همچنین زمانی که instance اوراکل را اجرا می کنید، در خروجی میزان فضای SGA نمایش داده می شود. به طور مثال شکل زیر میزان فضای SGA را در ماشین من نشان می دهد. این فضا به میزان حافظه اصلی شما بستگی دارد. اوراکل در زمان نصب مقداری را پیشنهاد می دهد ولی شما می توانید در زمان نصب مقدار دلخواه را تعیین کنید و یا اینکه پس از نصب، پارامتر memory_target را تغییر دهید.

همانطور که از شکل بالا (شکل ۱) می بینید از دستور startup برای آغاز (start) کردن instance استفاده کرده ایم و سپس در خط بعدی مجموع کل فضای SGA (یا System Global Area) نشان داده می شود. در این خروجی میزان SGA و هر یک از مولفه های آن بر حسب بایت است.

در خطوط بعدی میزان حافظه به هر کدام از مولفه های SGA نشان داده شده است. در این مطلب می خواهیم برخی از این مولفه ها را به اختصار توضیح دهیم که عبارتند از:

۱ – database buffer cache که buffer cache نیز نامیده می شود.

۲ – redo log buffer

۳ –  shared pool

۴ – large pool

۵ – java pool

۱ – buffer cache

database buffer cache که آنرا buffer cache نیز می گویند یکی از مولفه های SGA است. در شکل ۱ می بینید که چه میزان از کل فضای SGA بر حسب بایت به آن تعلق گرفته است. buffer cache فضایی برای ذخیره و کَش کردن داده هایی است که دیتا فایل ها (data file) ها خوانده می شود.

ما هنوز در مورد دیتا فایل ها صحبت نکردیم ولی تا این حد بدانید که دیتا فایل ها، فایل های فیزیکی هستند که داده ها بر روی آنها به صورت دائمی ذخیره می شوند. فرض کنید که کاربر درخواست بازیابی یا واکشی داده ها را از طریق دستور select به instance می دهد. پایگاه داده برای پاسخ به این درخواست دو کار را انجام می دهد:

۱ – اول از همه buffer cache را بررسی می کند که آیا داده های مورد نظر درون این فضا وجود دارند. اگر وجود داشت، پس با همین داده ها پاسخ کاربر را می دهد.

۲ – اگر داده ها در فضای buffer cache نبود، آنگاه به سراغ دیتا فایل ها می رود و داده هایی که کاربر نیاز دارد را خوانده و پاسخ کاربر را می دهد ولی این داده های تازه خوانده شده را بازهم به درون فضای buffer cache می آورد و در آنجا ذخیره و کَش می کند.

ولی چرا اوراکل داده ها را درون فضای buffer cache ذخیره می کند؟ دلیل آن این است که شاید دستورهای دیگری در آینده اجرا شوند که به همین داده ها نیاز داشته باشند. پس اوراکل زمانی که کمبود فضا برای داده های جدیدتر احساس نشود، این داده ها را درون buffer cache نگه می دارد.

حال فرض کنید کاربر درخواست update را ارسال کرده و داده ها درون فضای buffer وجود ندارند. اوراکل چگونه پاسخ می دهد؟ اوراکل در این حالت ابتدا داده ها را از دیتا فایل ها می خواند و سپس آنها را درون buffer cache کپی می کند و سپس تغییرات را اعمال می کند و در نهایت پاسخ کاربر را می دهد.

دیتا فایل ها، فایل های فیزیکی هستند که بر روی دیسک ها ذخیره شده اند و داده ها را به صورت دائمی در خود نگه می دارند ولی buffer cache بخشی از SGA و به طبع بخشی از حافظه اصلی است و با خاموش شدن سرور اوراکل، داده های کَش شده در آن نیز از بین می روند.

کاربرد پارامترهای DB_CACHE_SIZE و DB_nK_CACHE_SIZE در اندازه بلاک ها: معماری اوراکل – مروری بر Data Block

۲ – redo log buffer

 

در حالیکه buffer cache محلی برای نگهداری داده ها و یا داده های تغییر کرده است و دیتا فایل ها فایل های فیزیکی برای نگهداری دائمی داده هستند، چگونه این داده و یا تغییرات از روی buffer cache به دیتا فایل ها اعمال و کپی می شوند؟ آیا یکباره این تغییرات اعمال خواهند شد؟

پاسخ به این سوال ها این است که تغییرات یکباره از buffer cache به درون دیتا فایل ها اعمال نمی شوند بلکه پیش از هر چیز باید لاگ شوند. این مطلب را به یاد داشته باشید که در معماری تمامی پایگاه داده ها، پیش از انکه هر تغییری درون پایگاه داده ثبت نهایی شود، اول باید اثر تغییرات اعمال شده درون فایل هایی لاگ (log) شود.

redo log buffer فضایی از SGA است که تغییرات اعمال شده بر روی پایگاه داده را در خود نگه می دارد. هر تغییر در غالب یک رکورد است که هر رکورد دقیقا تعیین می کند که کدام نوع تغییر بر روی کدام داده و در کدام زمان رخ داده است. بنابراین رکوردهای redo حاوی اطلاعاتی هستند که از آنها می توانیم پایگاه داده را باسازی کنیم.

زمانی که توسط یک گروه از دستورهای DML یا DDL داده های پایگاه داده را تغییر می دهید، این تغییرات اولا بر روی buffer cache نوشته می شوند و سپس اثر این تغییرات در غالب رکورد redo بر روی فضای redo log buffer نوشته می شوند. پس از آن حتما باید رکوردهای redo از فضای redo log buffer به درون فایل های فیزیکی به نام online redo log نوشته شوند و در نهایت پس از نوشتن شدن رکوردهای redo در online redo log ها، تغییرات از buffer cache به درون دیتا فایل ها نوشته می شوند.

online redo log چیست

همانطور که دیتا فایل ها، فایل های فیزیکی هستند که به صورت دائمی، داده های جدید و یا تغییر کرده را از درون buffer cache در خود نگه می دارند، online redo log ها نیز فایل های فیزیکی هستند که رکوردهای redo را از درون redo log buffer در خود نگه می دارند.

گفتیم که هر رکورد redo یک تغییر را بر روی پایگاه داده نشان می دهد، پس فایل های online redo log زمانی لازم هستند که خرابی به وجود بیاد و بخواهیم توسط رکوردهای redo پایگاه داده را بازیابی (یا ریکاوری – recovery) کنیم. به عبارت دیگر هر رکورد redo اثر یک تراکنش نهایی شده است. تراکنش نهایی شده (Commited Transaction) به این معنی است که یک تراکنش بر روی پایگاه داده اجرا شده و پس از انجام یک سری دستورها، آن تراکنش با موفقیت به اتمام رسیده است و حال باید اثرات آن تراکنش به صورت یک رکورد redo درون online redo log ذخیره شود.

Online Redo Log های اوراکل – پیش گفتار

Online Redo Log های اوراکل – انتقال رکورد redo به فایل

Online Redo Log های اوراکل – مفهوم Log Switch

Online Redo Log های اوراکل – مفهوم مالتی پلکس کردن

Online Redo Log های اوراکل – ایجاد گروه ها و فایل ها