آموزش سیستم مدیریت پایگاه داده - بازیابی اطلاعات

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

طبقه‌بندی Failure

برای مشاهده جایی که مشکل رخ داده است، یک خرابی را به دسته‌های مختلفی تقسیم می‌کنیم، به شرح زیر −

Failure تراکنش

یک تراکنش باید در صورت ناتوانی در اجرا یا رسیدن به نقطه‌ای که نمی‌تواند ادامه دهد، منصرف شود. این موضوع Failure تراکنش نامیده می‌شود که تنها چند تراکنش یا فرآیند متضرر می‌شوند.

دلایلFailure تراکنش ممکن است عبارت باشند از −

• خطاهای منطقی − جایی که یک تراکنش نمی‌تواند به اتمام برسد زیرا دارای خطای کد یا هر شرایط خطا دیگری است.

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

Failure سیستم

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

ممکن است شامل خطاهای سیستم عامل باشد.

Failure دیسک

در اوایل رشد فناوری، مشکل متداولی بود که درایوهای هارد دیسک یا درایوهای ذخیره سازی به طور مکرر خراب می‌شدند.

خرابی‌های دیسک شامل ایجاد بخش‌های خراب، عدم دسترسی به دیسک، برخورد سر دیسک یا هرگونه خرابی دیگری است که باعث نابودی کل یا بخشی از ذخیره سازی دیسک می‌شود.

ساختار ذخیره‌سازی

سیستم ذخیره‌سازی را قبلاً توضیح داده‌ایم. به طور خلاصه، ساختار ذخیره‌سازی را می‌توان به دو دسته تقسیم کرد −

• ذخیره‌سازی فراری − همانطور که از نامش پیداست، ذخیره‌سازی فراری قادر به بقای خود در صورت خرابی سیستم نیست. دستگاه‌های ذخیره‌سازی فراری بسیار نزدیک به CPU قرار می‌گیرند؛ به طور معمول، آنها به چیپست خود تعبیه می‌شوند. به عنوان مثال، حافظه اصلی و حافظه نهان مثال‌هایی از ذخیره‌سازی فراری هستند. آنها سریع هستند اما تنها مقدار کوچکی از اطلاعات را می‌توانند ذخیره کنند.

• ذخیره‌سازی غیرفراری − این حافظه‌ها برای بقای خود در صورت خرابی سیستم طراحی شده‌اند. آنها بزرگ در ظرفیت ذخیره‌سازی داده هستند اما کند در دسترسی هستند. ممکن است شامل هارد دیسک، نوارهای مغناطیسی، حافظه فلش و حافظه غیرفراری (پشتیبانی شده توسط باطری) باشند.

بازیابی و اتمی

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

زمانی که یک DBMS از یک خرابی بازیابی می‌کند، باید موارد زیر را حفظ کند −

• وضعیت تمام تراکنش‌های در حال اجرا باید بررسی شود.

• ممکن است یک تراکنش در حالت میانی عملیاتی باشد؛ DBMS باید در این حالت اتمیتی تراکنش را تضمین کند.

• باید بررسی شود که آیا تراکنش در حال حاضر قابل انجام است یا نیاز به برگشت رفتن دارد.

• هیچ تراکنشی به حالت ناهماهنگ در DBMS اجازه داده نمی‌شود.

دو نوع تکنیک وجود دارد که می‌تواند به یک DBMS در بازیابی و حفظ اتمیتی تراکنش کمک کند −

• حفظ لاگ‌های هر تراکنش و نوشتن آنها در یک ذخیره‌سازی پایدار قبل از واقعیت تغییرات پایگاه داده.

• حفظ صفحات سایه که تغییرات بر روی یک حافظه فراری انجام می‌شود و سپس پایگاه داده واقعی به روزرسانی می‌شود.

بازیابی براساس لاگ

لاگ یک دنباله از رکوردها است که سوابق عملیات‌هایی که توسط یک تراکنش انجام شده‌اند را نگهداری می‌کند. مهم است که لاگ‌ها قبل از انجام واقعی تغییرات نوشته شوند و در یک رسانه ذخیره‌سازی پایدار قرار گیرند که ایمنی خرابی را دارد.

بازیابی براساس لاگ به شرح زیر عمل می‌کند −

• فایل لاگ روی یک رسانه ذخیره‌سازی پایدار نگهداری می‌شود.

• زمانی که یک تراکنش وارد سیستم می‌شود و شروع به اجرا می‌کند، یک لاگ درباره آن نوشته می‌شود.

<Tn
, Start>

• زمانی که تراکنش یک مورد X را تغییر می‌دهد، لاگ‌ها به شکل زیر نوشته می‌شوند −

<Tn, X, V1, V2>

مقدار X از V₁ به V₂ تغییر کرده است.

• زمانی که تراکنش به پایان می‌رسد، لاگ ثبت می‌شود −

<Tn, commit>

پایگاه داده می‌تواند با استفاده از دو رویکرد تغییر یابد −

• تغییر مؤجل پایگاه داده − تمام لاگ‌ها روی ذخیره‌سازی پایدار نوشته شده و پایگاه داده زمانی که یک تراکنش متعهد می‌شود به‌روزرسانی می‌شود.

• تغییر فوری پایگاه داده − هر لاگ تغییرات واقعی در پایگاه داده را دنبال می‌کند. به عبارتی، پایگاه داده فوراً پس از هر عملیات به‌روزرسانی می‌شود.

بازیابی با تراکنش‌های همروند

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

چک‌پوینت

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

بازیابی

زمانی که یک سیستم با تراکنش‌های همروند دچار خطا می‌شود و بازیابی می‌شود، به صورت زیر عمل می‌کند −

• سیستم بازیابی لاگ‌ها را به صورت معکوس از انتها تا آخرین چک‌پوینت می‌خواند.

• دو لیست، لیست عملیات واگردانی (undo) و لیست عملیات تکراری (redo) را نگه می‌دارد.

• اگر سیستم بازیابی یک لاگ با <T_n, شروع> و <T_n, تایید> یا فقط <T_n, تایید> را مشاهده کند، تراکنش را در لیست عملیات تکراری قرار می‌دهد.

• اگر سیستم بازیابی یک لاگ با <T_n, شروع> اما بدون یافتن لاگ تایید یا لاگ لغو (abort) مشاهده کند، تراکنش را در لیست عملیات واگردانی قرار می‌دهد.

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