در قسمت اول انواع بازیابی پایگاه داده، نحوه عملکرد آنها و اینکه چگونه DBA ها باید برای سناریوهای بازیابی آماده شوند را بررسی کردیم. در این مقاله، بیایید کمی عمیق تر به مسائل و تصمیماتی بپردازیم که DBA ها باید برای رسیدگی به آنها در حین کار بر روی بازیابی پایگاه داده آماده شوند.
اولین چیزی که DBA ها باید از آن آگاه باشند، اهداف زمان بازیابی (recovery time objectives) یا RTO ها برای اشیاء پایگاه داده مورد نظر است. در یک دنیای ایده‌آل، RTO  و رویه‌های پشتیبان با توجه به زمان بازیابی برای هر شی ایجاد می‌شود.
این مسئولیت DBA است که اطمینان حاصل کند  از داده ها مطابق با RTO (هدف زمان بازیابی) مشخص شده برای هر table space پشتیبان تهیه می شود. با این حال، نیازهای زمانی، کمبود منابع، یا سایر مسائل کاهش دهنده می تواند، مانع انجام کارها شود، بنابراین RTO ممکن است وجود نداشته باشد یا در جایی مستند نشده باشد. به هر حال، DBA باید با صحبت با SMEها و کاربران نهایی آگاه در مورد داده، از اهمیت شی برای چارچوب‌بندی نیازمندی‌های بازیابی مطلع شود.
اما معمولاً می توانید با خیال راحت فرض کنید که پاسخ همیشه این خواهد بود: “من فوراً به آن نیاز دارم!” این بدان معنی است که DBA باید گزینه های بازیابی موجود را بررسی کند و گزینه ای را انتخاب کند که کمترین زمان خرابی را ایجاد کند و سریع ترین را اجرا کند.
بنابراین، بهترین استراتژی بازیابی چیست؟ بستگی دارد.
از لحاظ تاریخی، بازیابی بیشتر برای بلایا و خرابی‌های سخت‌افزاری انجام می‌شد، اما دیگر اینطور نیست. اکثر بازیابی‌ها این روزها ناشی از مشکلات برنامه هستند. مطالعات اخیر تحلیلگران صنعت نشان می دهد که اغلب خرابی سیستم ناشی از مشکلات نرم افزاری است نه مشکلات سخت افزاری.
در واقعیت، تعداد کمی از DBA ها به دلیل خرابی سخت افزار به جز در هنگام آزمایش نیاز به بازیابی دارند. اگرچه مدیاهای سخت افزاری همچنان به شکست و خرابی خود ادامه می دهند، اما این روزها به ندرت کاملا خراب می شوند چراکه با RAID های رایج، افزونگی در سیستم‌های ذخیره‌سازی تعبیه شده است، بنابراین خرابی دستگاه ذخیره‌سازی بسیار غیر معمول است. خطاهای کاربر و خرابی برنامه ها شایع ترین دلیل برای بازیابی پایگاه داده و در نتیجه دلیل اصلی در دسترس نبودن سیستم هستند.

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

در تعیین نوع بازیابی برای انجام، DBA باید چندین سؤال را در نظر بگیرد:

• شناسایی تراکنش (Transaction identification):

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

• یکپارچگی داده (Data integrity):

آیا شخص دیگری از زمان بروز مشکل، ردیف ها را به روز کرده است؟ اگر بله آیا هنوز هم می توانید ادامه دهید؟ آیا تمام داده های مورد نیاز هنوز در دسترس است؟ مداخله در سازماندهی مجدد، بارگیری (load) یا حذف انبوه می تواند نیاز به استفاده از یک نسخه پشتیبان تصویر (image) داشته باشد، در نتیجه بازیابی UNDO را حذف می کند. آیا بازیابی باعث از بین رفتن اطلاعات دیگر می شود؟ اگر چنین است، آیا می توان داده های از دست رفته را به نوعی شناسایی کرد و مجدداً اعمال کرد؟

• سرعت (Speed):

اگر چندین تکنیک قابل اجرا باشند، کدام یک احتمالا سریع‌ترین عملکرد را دارد؟ برای انجام بازیابی به چه تعداد لاگ پایگاه داده نیاز است؟ آیا می توان کاری برای کاهش تعداد لاگ ها انجام داد، مانند ادغام کپی های افزایشی؟

• در دسترس بودن (Availability):

چه مدت بعد می تواند برنامه دوباره در دسترس قرار گیرد؟ آیا می توانید آفلاین باشید؟

• تهاجمی (Invasiveness):

شکست در پایگاه داده شما چقدر تهاجمی بود؟ آیا تصمیمات بر اساس داده های بد گرفته شده است؟ آیا می توان به کارهای بعدی اعتماد کرد؟

همه این سؤالات در واقع به سؤال هزینه خلاصه می شود. هزینه کار مجدد چقدر است و آیا واقعاً می توان تعیین کرد که چه چیزی باید دوباره انجام شود؟ این هزینه باید در مقابل هزینه اسکن طولانی مجموعه داده های گزارش برای جداسازی داده ها برای انجام مجدد یا لغو و هزینه اعمال آن داده ها در پایگاه داده متعادل شود. البته، یک سوال دیگر نیز وجود دارد:

کدام یک از این تکنیک‌های بازیابی واقعاً در سایت شما موجود است و آیا برای DBMS مورد نظر کار می‌کنند؟

عوامل زیادی بر طول مدت روند بهبودی تأثیر می گذارد. DBA می تواند با ایجاد یک برنامه پشتیبان گیری و بازیابی هوشمند، اقداماتی را برای کاهش زمان خرابی اجرا کند. عوامل زیر می توانند مدت زمان بهبودی را کوتاه کنند:

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

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

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