رسیدگی به خرابی Online Redo Log – بخش اول

مقدمه
فایل های Online Redo Log در پایگاه داده اوراکل، تراکنش هایی که در پایگاه داده رخ می دهد را ذخیره می کند.
Online Redo Logها در پایگاه داده اوراکل چندین هدف را دنبال می کنند:
-یک مکانیزم برای ذخیره سازی تغییرات پایگاه داده تا در صورت خرابی دیسک، روشی برای بازیابی تراکنش ها وجود داشته باشد.

-در زمانی که Instance Failure رخ می دهد و درحالی که هنوز تغییرات در datafile نوشته نشده است، می توان تراکنش های Commit شده را ریکاوری کرد.
-این امکان را می دهد تا با استفاده از ابزار LogMiner تاریخچه تراکنش های پایگاه داده را بررسی کرد.
در هر پایگاه داده حداقل دو گروه Online Redo Log وجود دارد و امکان ایجاد چندین گروه نیز وجود دارد. هر گروه حداقل دارای یک عضو می باشد که هر عضو یک فایل فیزیکی برروی دیسک می باشد. فرایند پس زمینه (background process) به نام Log Writer در پایگاه داده اوراکل وظیفه نوشتن اطلاعات تراکنش ها را از روی Redo Log Buffer (در حافظه) برروی Online Redo Log Fileها (در دیسک) دارد.
رسیدگی به خرابی Online Redo Log – بخش اول

وضعیت های مختلف Online Redo Log
گروه های Online Redo Log File می توانند دارای ظرفیت های مختلف باشد(توصیه می شود همه گروه ها دارای ظرفیت یکسان باشد). هر زمان فرایند Log Switch اتفاق می افتد وضعیت گروه ها تغییر می کند و فرایند پس زمینه Log Writer شروع به نوشتن در گروه جدید می کند.

هرزمان یکی از فرایندهای ذیل رخ دهد فرایند پس زمینه Log Writer شروع به نوشتن برروی اعضای گروه ها می-کند:
-یک سوم Redo Log Buffer پر شده باشد
-هر سه ثانیه یکبار
-در هر Commit
برخی از وضعیت های مختلفی که هر گروه از Online Redo Logها می تواند داشته باشد:
-CURRENT: گروهی که فرایند پس زمینه درحال نوشتن برروی آن می باشد.
-ACTIVE: گروهی که جهت Crash Recovery مورد نیاز می باشد.
-INACTIVE: گروهی که برای Crash Recovery موردنیاز نمی باشد.
-UNUSED: گروهی که به تازگی ایجاد شده است و هنوز مورد استفاده پایگاه داده قرار نگرفته است.
-CLEARING : گروهی که توسط دستور alter database پاک شده است.
شما می توانید با استفاده از ویوی V$LOG وضعیت گروه های Online Redo Log را مشاهده کنید.

همچنین هر Member در گروه ها وضعیت‌های مختلفی میتواند داشته باشد که به شرح ذیل می باشد:
-INVALID: این Member یا در دسترس نیست و یا به تازگی ایجاد شده است.
-DELETED: این Member دیگر مورد استفاده نمی باشد.
-STALE: این Member دارای محتویات کاملی نیست.
-NULL: پایگاه داده درحال استفاده از این Member می باشد.
برای دیدن وضعیت Memberها می توان از ویوی V$LOGFILE استفاده کرد.

سناریوهای خرابی یک Member

زمانی که گروه در وضعیت INACTIVE می باشد
زمانی که یک گروه در وضعیت Inactive می باشد و یک Member از این گروه خراب می شود، برای دیدن خرابی، باید Alert Log را مانیتور کرد و سپس در جهت رفع مشکل پیش آمده اقدامات لازم را انجام داد.
بررسی وضعیت پایگاه داده با مانیتور کردن Alert Log.
$ less /oracle/app/diag/rdbms/orcl19c/orcl19c/trace/alert_orcl19c.log

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

sql> alter database drop logfile member ‘/[member_path]/[member_name]’;

و برای ایجاد مجدد آن Member ازدستور زیر استفاده می کنیم.

Sql> ALTER DATABASE ADD LOGFILE member ‘/[member_path]/[member_name]’ to GROUP n;

لازم بذکر است مسیر Member خراب شده و گروه آن در Alert Log قابل مشاهده می باشد و همچنین تا زمانی که پایگاه داده اقدام به نوشتن لاگ برروی این گروه نکند، از خرابی Member آگاه نشده و آن را نمایش نخواهد داد.

زمانی که گروه در وضعیت ACTIVE می باشد.
زمانی که یک گروه در وضعیت Active می باشد و یک Member از این گروه خراب می شود، مانند سناریو پیشین می توان با مانیتور کردن Alert Log متوجه این موضوع شد و سپس در جهت رفع مشکل پیش آمده اقدامات لازم را انجام داد.
بررسی وضعیت پایگاه داده با مانیتور کردن Alert Log.

$ less /oracle/app/diag/rdbms/orcl19c/orcl19c/trace/alert_orcl19c.log

همانطور که گفتیم، زمانی که یک گروه در وضعیت Active می باشد یعنی در فرایند Crash Recovery مورد استفاده قرار می گیرد، در نتیجه خرابی Memberهای این گروه ها به مراتب از گروه های مورد بررسی قبلی از اهمیت بیشتری برخوردار می باشد. با خرابی یک Member از هر گروه با هروضعیتی، مشکل جدی برای پایگاه داده پیش نخواهد آمد اما با توجه به وضعیت گروه و احتمال خرابی دیگر Memberها، رسیدگی به آن ها اولویت بندی می شود.
ابتدا گروه را از وضعیت Active خارج می کنیم تا مخاطرات احتمالی را به حداقل برسانیم.

Sql> ALTER SYSTEM checkpoint;

سپس مانند سناریو پیشین Member خراب شده را حذف و مجدد ایجاد می‌کنیم.

Delete Member

sql> alter database drop logfile member ‘/[member_path]/[member_name]’;

Recreate Member

Sql> ALTER DATABASE ADD LOGFILE member ‘/[member_path]/[member_name]’ to GROUP n;

لازم بذکر است مسیر Member خراب شده و گروه آن در Alert Log قابل مشاهده می باشد.

زمانی که گروه در وضعیت Current می باشد.
زمانی که یک گروه در وضعیت Current می باشد و یک Member از این گروه خراب می شود، مانند سناریوهای پیشین می توان با مانیتور کردن Alert Log متوجه این موضوع شد و سپس در جهت رفع مشکل پیش آمده اقدامات لازم را انجام داد. گروه های Current حساس ترین گروه در RedoLogGroupها می‌باشند اما همانطور که پیشتر گفته شد، خرابی یک Member از هر گروه با هر وضعیتی، نمی تواند مشکل جدی برای پایگاه داده ایجاد کند.
بررسی وضعیت پایگاه داده با مانیتور کردن Alert Log.

$ less /oracle/app/diag/rdbms/orcl19c/orcl19c/trace/alert_orcl19c.log

ابتدا عملیات سوییچ را انجام می دهیم تا پایگاه داده برروی گروه دیگری لاگ ها را بنویسد تا مخاطرات احتمالی کم تر شود.

Sql> alter system switch logfile;

در اینجا گروه به وضعیت Active تغییر می کند و مانند سناریو پیش می شود. پس از عملیات سوییچ، گروه را از وضعیت Active خارج می کنیم.

Sql> ALTER SYSTEM checkpoint;

و بعد مانند سناریوهای گذشته Member خراب شده را حذف و مجدد ایجاد می کنیم.

Delete Member

sql> alter database drop logfile member ‘/[member_path]/[member_name]’;

Recreate Member

Sql> ALTER DATABASE ADD LOGFILE member ‘/[member_path]/[member_name]’ to GROUP n;

خلاصه
در این بخش Redo Log Groupها را تعریف کردیم و همچنین به وضعیت های مختلف هر گروه و هر Member پرداختیم و نیز در ادامه سناریوهای مختلف از دست رفتن یک Member از یک گروه با هر وضعیتی را بررسی کردیم.
در بخش بعد سناریوهای مطرح شده در این بخش را برای از دست رفتن یک گروه بررسی می کنیم.