online redo log (بخوانید ریدولاگ) یکی از اصلی ترین فایل هایی است که برای انجام ریکاوری لازم و ضروری هستند. online redo log ها شامل تمامی تغییرات (اثرات) تراکنش های نهایی شده (comitted transaction) هستند که درون پایگاه داده اتقاق افتاده اند. بنابراین به این خاطر که فایل های online redo log، حاوی اثرات تمامی تراکنش های نهایی شده هستند از آنها برای محافظت از instance پایگاه داده استفاده می شود. از این رو لازم است تا به هر یک از instance های پایگاه داده حداقل یک ریدولاگ اختصاص داده می شود.

اهمیت و کاربرد فایل های Online Redo Log

به طور کلی در مفاهیم پایگاه داده های رابطه ای دو نوع از لاگ ها به نام redo log و undo log وجود دارد. redo log ها، آن لاگ هایی هستند که اثر یک تراکنش نهایی شده را نگه می دارند. تراکنش های نهایی شده آنهایی هستند که اثر آنها بر روی دیتا فایل ها ثبت شده است. بنابراین این لاگ ها برای بازیابی پایگاه داده (database recovery) مهم هستند.

فرض کنید یک تغییر (مانند اجرای دستور INSERT, UPDATE, DELETE) را روی یک جدول انجام می دهید و به هر دلیلی دیتا فایل ها از کار می افتد و شما باید پایگاه داده را بازیابی کنید اما بازیابی که شما را به آخرین نقطه از زمانی ببرد که پایگاه داده و داده های آن در صحت و درستی باشند. منظور این است که باید اثرات تمامی تراکنش های نهایی شده ای که پیش از خرابی دیتا فایل ها ایجاد شده بودند نیز باید در زمان بازیابی اعمال و استفاده شوند. فایل های online redo log یکی از فایل هایی هستند که باید از آنها استفاده شوند زیرا شامل رکوردهایی هستند که هر یک اثر یک تراکنش نهایی شده را مشخص می کند. اصطلاحا به این رکوردها، redo log می گویند.

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

دلیل اینکه online redo log باعث محافظت instance در مقابل از کار افتادن آن می شود این است که هر تغییری بر روی داده ها ابتدا درون فضای buffer cache رخ می دهد و سپس اثر این تغییر به صورت یک رکورد redo (یا redo log) به درون فضای online redo buffer نوشته می شود.

اگر instance پایگاه داده از کار بی افتد، بنابراین اطلاعات درون online redo buffer نیز از بین می روند، پس لازم است طبق قواعدی که جلوتر خواهیم گفت، رکوردهای درون فضای online redo buffer به درون فایل هایی به نام online redo log ریخته شوند که بر روی دیسک قرار دارند.

در واقع از ریدولاگ ها استفاده می کنیم تا اثرات تراکنش هایی را برگردانیم که باید در پایگاه داده و به طور دقیق تر، در دیتا فایل ها ثبت نهایی می شدند. بنابراین فایل های ریدولاگ برای ذخیره سازی اثرات تراکنش های نهایی شده و استفاده از آنها برای بازیابی پایگاه داده است.

تفاوت رکوردهای Redo Log و Undo Log

در مقابل رکودهای undo log وجود دارند که اثرات تراکنش های غیر نهایی شده (uncomitted transaction) ها را در خود نگه می دارند. این رکوردها در اوراکل در غالب tablespace های ویژه ای به نام undo tablespace نگهداری می شوند. رکوردهای undo شامل آن دسته از رکوردهایی هستند که هر یک اثر یک تراکنش غیر نهایی شده را در خود نگه می دارد.

در اوراکل و البته دیگر پایگاه داده های رابطه ای دستوری به نام COMMIT وجود دارد که باعث می شود اجرای یک تراکنش با موفقیت خاتمه یابد و از این رو آنرا یک تراکنش نهایی شده می نامیم. زمانی که دستور COMMIT اجرا شود، تمامی اثرات یک تراکنش باید برای ثبت دائمی بر روی دیتا فایل ها نوشته شود.

اما زمانی که در حین اجرای تراکنش و اینکه تراکنش تابه حال تغییراتی را روی پایگاه داده انجام داده است، ممکن است به هر دلیلی پایگاه داده ازکار بی افتد، این تراکنش ها را غیر نهایی شده تلقی می کنیم و در حین زمان بازیابی پایگاه داده نباید اثرات آنها بر روی پایگاه داده اعمال شوند از این رو در اوراکل فضای مجزایی به نام undo tablespace برای نگهداری آنها وجود دارد.

به یاد داشته باشید که تراکنش هایی غیر نهایی شده دارای اثرات مخرب بر روی پایگاه داده و صحت و درستی داده های پایگاه داده دارد. بنابراین می توانیم تمامی مطالب بالا را در دو خط زیر به صورت ساده و خلاصه بیان کنیم:

۱ – فایل های online redo log و به عبارت بهتر رکوردهای redo log شامل اثرات تراکنش های نهایی شده ای هستند که در زمان بازیابی پایگاه داده باید اثرات آنها به پایگاه داده اعمال شوند.

۲ – رکورده های undo redo شامل اثرات تراکنش هایی غیر نهایی شده هستند که به دلیل تاثیرات مخرب، در زمان بازیابی پایگاه داده، نباید این رکوردها به پایگاه داده اعمال شوند.

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

مفهوم Thread در Online Redo Log های اوراکل

پیش از این توضیح داده بودیم که در پیاده سازی و راه اندازی، محیط اوراکل می تواند به دو صورت standalone و یا تک سروری یا تک instance باشد و یا اینکه به صورت محیط کلاستر اوراکل (Oracle Real Application Cluster ) و یا محیط چند instance باشد. محیط کلاستر یاOracle RAC به معنی وجود چندین instance است که همگی یک پایگاه داده را مدیریت می کنند.

اگر فرض کنیم که شما محیط کلاستر یا چند instance را دارید، در این صورت هر یک از این instance ها، فایل گروه های online redo log خودشان را دارند. به تمامی گروه های online redo log یک instance یک نخ یا thread redo می گویند. هر نخ دارای یک شماره محنصر به فرد است که از عدد یک شروع می شود که اصطلاحا thread number یا #thread می گویند.

بنابرین با فرض محیط کلاستر، اگر فرض کنیم دو instance در کلاستر وجود دارند، و هر کدام دارای سه گروه فایل online redo log باشد، پس تمامی گروه های instace به عنوان نخ شماره ۱ و تمامی گروه های instance دوم به عنوان نخ شماره ۲ در نظر گرفته می شوند.

حال فرض کنید محیط ساده تک سروری و تک instance داریم که بازهم این تک instance دارای سه گروه online redo log است بنابراین تمامی این سه گروه به عنوان نخ شماره ۱ تلقی می شوند. توجه کنید که شماره نخ به تمامی گروه های یک نخ انتساب داده می شود و نه به تک تک فایل های online redo log.

پیدا کردن شماره thread#

بنابراین اگر در ساده ترین حالت فرض کنیم که تک instance داریم که دارای سه گروه است و هر گروه نیز دارای دو فایل online redo log باشد، پس شماره نخ مربوط به این instance عدد ۱ است که به یکجا به تمامی سه گروه online redo log اشاره دارد. کوئری زیر چگونگی پیدا کردن شماره نخ instance فعلی که به آن وارد (لاگین) شده ایم را نشان می دهد و نمونه خروجی کوئری در شل زیر (۱) نشان داده شده است.

بنابراین در شکل بالا می توانید ببینید با اینکه در instance سه گروه فایل online redo log داریم (گروه های شماره ۱ و ۲ و ۳) ولی همگی این سه گروه با یکدیگر به عنوان یک نخ و آن هم نخ شماره ۱ تلقی می شوند. حال اگر در محیط کلاستر باشید و به یک instance دیگر متصل شوید وکوئری بالا را اجرا کنید، چون این instance گروه های online redo log خودش را دارد، پس شماره نخ آن نیز متفاوت و مثلا عدد ۲ است.

بنابراین در محیط Oracle RAC هر instance شماره نخ خودش را دارد که این شماره با شماره نخ instance دیگر متفاوت است و instance در زمان راه اندازی شدن قاعدتا تمامی گروه های online redo log مربوط به نخ خودش را می خواند و استفاده می کند و اثرات هر تراکنشی که در هر یک از instance ها رخ دهد، تنها در فایل ها و گروه های online redo log همان instance نوشته می شود.

جمع بندی فایل های online redo log

۱ – فایل های online redo log با رکوردهای ریدولاگ پر می شوند.

۲ – هر رکورد redo اثر تغییر یک تراکنش نهایی شده را نگه می دارد.

۳ – از رکوردهای online redo log برای بازسازی و بازیابی (ریکاوری) پایگاه داده و اعمال تغییرات انجام شده پس از هر گونه خرابی در دیتا فایل ها استفاده می شود. زیرا اثرات تراکنش های نهایی شده و تغییرات اعمال شده روی پایگاه داده را در خود نگه می دارند.

۴ – تمامی گروه های online redo log به عنوان یک نخ در نظر گرفته و نامیده می شوند.

۵ – در محیط کلاستر اوراکل هر instance دارای یک شماره نخ منحصر به فرد خودش است.