امکان خراب شدن همه چیز وجود دارد  و DBA ها باید برای هر شرایط غیر مترقبه ای  آماده باشند  یک failure بر در دسترس بودن، یکپارچگی یا قابلیت استفاده پایگاه داده تأثیر مستقیم می گذارد. واکنش به خرابی ها و اختلالات سرویس یک جزء کلیدی از کار DBAهاست. این به این معنی است که اطمینان حاصل کنید که پشتیبان گیری مناسب برای تمام اشیاء پایگاه داده حیاتی شما گرفته شده است.

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

بازیابی به حالت فعلی

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

برای بازیابی موفقیت آمیز به حالت فعلی، فرآیند بازیابی باید بتواند محتویات پایگاه داده را به شکلی که دقیقاً در نقطه شکست (یا درست قبل از آن) دیده شده، بازنشانی کند. برای بازیابی به حالت فعلی، فرآیند بازیابی باید یک نسخه پشتیبان کامل و معتبر از image پیدا کند و آن image copy را بازیابی کند. سپس بازیابی از طریق log پایگاه داده به جلو حرکت کرده و تمام تغییرات پایگاه داده را اعمال می کند.

اگر آخرین نسخه کامل image از بین رفته باشد یا از بین برود، در صورت وجود، image copy قبلی ممکن است بازیابی شود. فرآیند بازیابی می‌تواند با نسخه پشتیبان قدیمی‌تر شروع شده، هر incremental copy (نسخه افزایشی) اعمال شود، و سپس در آرشیولاگ‌ها و اکتیو لاگها به جلو حرکت کند. البته در چنین حالتی به log های پایگاه داده بیشتری نیاز خواهد بود، بنابراین روند بازیابی بیشتر طول می کشد.

اگر هیچ image copy به عنوان نقطه شروع در دسترس نباشد، ممکن است بتوان شی پایگاه داده را فقط با استفاده از log پایگاه داده بازیابی کرد. اگر داده ها load شده  باشند و فرآیند load  لاگ شده باشد، بازیابی ممکن است به سادگی با اعمال رکوردهای لاگ انجام شود.

بازیابی به روش نقطه در زمان (PIT)

دومین نوع سنتی بازیابی، بازیابی (point in time) نقطه در زمان (PIT) است که معمولاً برای مقابله با یک مشکل در سطح برنامه انجام می شود. بازیابی PIT گاهی اوقات به عنوان بازیابی نسبی نامیده می شود زیرا تنها بخشی از داده های موجود پس از بازیابی باقی می ماند. بازیابی تا یک نقطه از زمان، اثرات تمام تراکنش‌هایی را که از آن زمان مشخص شده رخ داده‌اند، حذف می‌کند.

برای انجام بازیابی PIT، یک نسخه پشتیبان از image بازیابی می‌شود و سپس تغییرات با حرکت به جلو (Forward) از طریق log پایگاه داده (یا پشتیبان‌گیری از log) اعمال می‌شوند. با این حال، فقط رکوردهای log تا زمان مشخص شده پردازش می شوند. گاهی اوقات نقطه بازیابی به عنوان تاریخ و زمان واقعی مشخص می شود. گاهی اوقات با استفاده از یک RBA در log پایگاه داده مشخص می شود.

برای بازیابی موفقیت آمیز در یک نقطه از زمان، فرآیند بازیابی باید بتواند محتویات پایگاه داده را به شکلی که در یک نقطه ثابت قبلی دیده شده، بازنشانی کند. نکته کلیدی این است که همه تغییرات خوب در داده ها را حفظ کنید، در حالی که همه “بد” ها را حذف کنید. بازیابی PIT را می توان با بازیابی image copy  و حرکت به جلو (Forward) در لاگ ها برای اعمال هرگونه تغییر انجام داد. یا فقط در لاگ‌ها به عقب برگردید (Backward) و تغییرات پایگاه داده را که پس از PIT رخ داده است، حذف ‌کنید.

صرف نظر از روشی که برای انجام بازیابی PIT استفاده می شود، DBA باید تا نقطه ای بازیابی انجام دهد که داده ها سازگار باشند. یک نقطه بازیابی ثابت، یکپارچگی داده ها، یکپارچگی ارجاعی و یکپارچگی تراکنش را تضمین می کند. برخی از DBMS ها مانند DB2 یک یوتیلیتی QUIESCE برای دستیابی به یک نقطه سازگاری ارائه می دهند، در حالی که برخی دیگر نیاز دارند که اشیاء پایگاه داده در طول image copy متوقف شده (یا در حالت فقط خواندنی باشند) تا نقطه سازگاری را ثبت کنند.

مسئله دیگر این است که مشخص کنید دقیقاً از زمان تراکنش بد یا failure که شما در حال بازیابی از آن هستید، چه چیزی اجرا شده است. DBA می‌تواند زمان‌بندی کار را بررسی کند، لاگی را از لاگ‌های پایگاه داده قالب‌بندی کند، و کنسول رایانه را برای پیام‌ها بررسی کند تا به تعیین فرآیندهایی که پس از وقوع failure انجام شده است کمک کند.

بازیابی تراکنش

بازیابی تراکنش، نوع سوم بازیابی است. در حالی که انواع سنتی بازیابی در سطح شی پایگاه داده بازیابی می شوند، بازیابی تراکنش به کاربر اجازه می دهد تا بخش خاصی از پایگاه داده را بر اساس معیارهای تعریف شده توسط کاربر بازیابی کند. این امر می تواند در سطح تراکنش یا برنامه کاربردی باشد. یک تراکنش با دیدگاه کاربر از فرآیند تعریف می‌شود، شاید مجموعه‌ای از پانل‌ها که شامل عملیات استخدام جدید هستند، یا مجموعه‌ای از مشاغل که به دفتر کل پست می‌شوند. نکته مهم این است که ممکن است بین تراکنش هایی که می خواهید اصلاح کنید و تراکنش ها (یا واحدهای بازیابی) در DBMS همبستگی وجود داشته باشد یا نباشد.

انواع مشکلات بازیابی تراکنش ایده‌آل هستند که شامل سناریوهایی مانند «حذف تمام به‌روزرسانی‌های پایگاه داده انجام‌شده توسط یک کاربر خاص از چهارشنبه گذشته در ساعت ۱۱:۵۰ صبح» یا «معکوس کردن تمام حذف‌های پایگاه داده انجام‌شده توسط یک برنامه کاربردی خاص از ساعت ۲۰:۰۰ دیروز است. ” در واقع، بسیاری از انواع مشابه از مشکلات مانند این وجود دارد که می تواند در سطح برنامه یا تراکنش رخ دهد.

پس از شناسایی تراکنش برای بازیابی، می توانید درخواست UNDO یا REDO کنید. بازیابی UNDO فقط اثرات تراکنش‌های بد را حذف می‌کند، در حالی که بازیابی REDO همه تراکنش‌ها را پس از یک مقطع زمانی مشخص حذف می‌کند و سپس فقط تراکنش‌های خوب را دوباره اعمال می‌کند. به طور معمول، بازیابی تراکنش با استفاده از SQL معکوس انجام می شود. یعنی، لاگ را بررسی کنید و INSERT ها را به DELETEs، DELETEs را به INSERTs تغییر دهید و تأثیر هر به روز رسانی را معکوس کنید.

موارد دیگر

گزینه‌های دیگری نیز وجود دارد، به عنوان مثال اگر رویکرد شما برای پشتیبان‌گیری و بازیابی استفاده از نرم‌افزار مدیریت فضای ذخیره‌سازی باشد، نسخه پشتیبان‌گیری یک image برای اشیاء پایگاه داده وجود نخواهد داشت. در این مورد، برای انجام بازیابی باید نرم افزار مدیریت ذخیره سازی را مستقر کنید. فرآیند بازیابی واقعی به نوع نرم افزار مدیریت ذخیره سازی مورد استفاده و همچنین نحوه (یا اگر) تعامل آن با مکانیسم های بازیابی DBMS بستگی دارد.

علاوه بر این، ما نمی توانیم بازیابی فاجعه خارج از سایت را نادیده بگیریم، حتی اگر این نادرترین نوع بازیابی پایگاه داده باشد. هنگامی که یک بلای طبیعی (آتش سوزی، سیل، و غیره) یا سایر حوادث شدید، استفاده از مرکز پردازش داده اولیه شما را غیرممکن می کند، بازیابی فاجعه خارج از محل مورد نیاز است. در این مورد، باید کل محیط سیستم خود را مجدداً راه اندازی کنید، همچنین DBMS، اشیاء پایگاه داده و داده های خود را بازیابی کنید.

این مقاله توسط کریگ اس. مولینز نوشته شده است.

ترجمه: یاسینه پورابراهیم