اندازهی قلم متن
تخمین مدت زمان مطالعهی مطلب:
دو دقیقه
در بعضی مواقع ممکن است که در حین کار و با تراکنشهای باز، دیتابیس SQL Server دچار مشکل شود و از دسترس خارج شود و این فرض را هم در نظر بگیرید که بک آپ دیتابیس مربوط به زمانی بیش از حد انتظار است. آیا ممکن است که دیتابیس را با وجود از دست دادن فایل لاگ آن بازگردانی کرد؟
جواب: بله ولی بدون عواقب نیست.
بطور معمول در زمانی که تراکنشهای باز بر روی سرور دیتابیس وجود دارد و بانک کرش میکند، کرش ریکاوری، تراکنشهای باز را رول بک میکند. این امر مانع از اثرات پراکنده از تراکنشهای فعلی در پایگاه داده میباشد.
اگر لاگ در دسترس نباشد هنگامی که کار سرور SQL شروع میشود، پایگاه داده در حالت SUSPECT قرار داده میشود. در این مواقع تنها راه آن لاین نمودن بانک ( البته منظور آماده بکار نمودن بانک نیست) استفاده از حالت قابلیت تعمیر اورژانسی است که از نسخه 2005 افزده شده است که با ساخت یک فایل لاگ جدید و سپس اجرا نمودن DBCC CHECKDB با استفاده از REPAIR_ALLOW_DATA_LOSS انجام میشود.
مشکل اینجاست که اگر شما به همین طریق بخواهید ادامه بدهید و از این قابلیت اورژانسی استفاده کنید، مسلما امکان وجود دستهای از تغییرات در بانک که ممکن است در میانه اعمال بروز رسانی چند رکورد فروش در یک جدول نیمی از تراکنشهای آنها روی بانک اعمال شده و بعد از راه اندازی دوباره با لاگ جدید، امکان برگرداندن آنها وجود داشته باشد، مواجه شوید. به این معنی که در بهترین حالت، پایگاه داده بدست آمده با برنامه هماهنگ نیست و یا اینکه به بک آپی که وجود دارد رضایت بدهید.
حالت تعمیر اورژانسی، زمانیکه همه راهحلهای بازگردانی بانک مغلوب شوند آخرین روش مانده است. این حالت، حالتی بین دو شر، ریکاور کردن بانک به حالتی نا هماهنگ با نرم افزار و یا برگرداندن به زمانی خیلی عقبتر است که در نهایت اقدام به انجام هر دو و هماهنگتر کردن بانک برای کار با برنامه میشوید که بسیار وقت گیر و مشکل ساز است.
ولی باز ممکن است این وضعیت پیش بیاد چون شما از اتفاقی که در زمان کرش در بانک افتاده اطلاعی ندارید. برای جلوگیری از این موارد در آینده سازوکار بک آپ گیری از بانک را باید تغییر بدهید و دفعات بک آپ گیری را افزایش بدهید و نیز از روشهای جدید که قابلیت دسترسی بالا دارند استفاده کنید همانند mirroring و SQL Server 2012 Availability Groups است.
جواب: بله ولی بدون عواقب نیست.
بطور معمول در زمانی که تراکنشهای باز بر روی سرور دیتابیس وجود دارد و بانک کرش میکند، کرش ریکاوری، تراکنشهای باز را رول بک میکند. این امر مانع از اثرات پراکنده از تراکنشهای فعلی در پایگاه داده میباشد.
اگر لاگ در دسترس نباشد هنگامی که کار سرور SQL شروع میشود، پایگاه داده در حالت SUSPECT قرار داده میشود. در این مواقع تنها راه آن لاین نمودن بانک ( البته منظور آماده بکار نمودن بانک نیست) استفاده از حالت قابلیت تعمیر اورژانسی است که از نسخه 2005 افزده شده است که با ساخت یک فایل لاگ جدید و سپس اجرا نمودن DBCC CHECKDB با استفاده از REPAIR_ALLOW_DATA_LOSS انجام میشود.
مشکل اینجاست که اگر شما به همین طریق بخواهید ادامه بدهید و از این قابلیت اورژانسی استفاده کنید، مسلما امکان وجود دستهای از تغییرات در بانک که ممکن است در میانه اعمال بروز رسانی چند رکورد فروش در یک جدول نیمی از تراکنشهای آنها روی بانک اعمال شده و بعد از راه اندازی دوباره با لاگ جدید، امکان برگرداندن آنها وجود داشته باشد، مواجه شوید. به این معنی که در بهترین حالت، پایگاه داده بدست آمده با برنامه هماهنگ نیست و یا اینکه به بک آپی که وجود دارد رضایت بدهید.
حالت تعمیر اورژانسی، زمانیکه همه راهحلهای بازگردانی بانک مغلوب شوند آخرین روش مانده است. این حالت، حالتی بین دو شر، ریکاور کردن بانک به حالتی نا هماهنگ با نرم افزار و یا برگرداندن به زمانی خیلی عقبتر است که در نهایت اقدام به انجام هر دو و هماهنگتر کردن بانک برای کار با برنامه میشوید که بسیار وقت گیر و مشکل ساز است.
ولی باز ممکن است این وضعیت پیش بیاد چون شما از اتفاقی که در زمان کرش در بانک افتاده اطلاعی ندارید. برای جلوگیری از این موارد در آینده سازوکار بک آپ گیری از بانک را باید تغییر بدهید و دفعات بک آپ گیری را افزایش بدهید و نیز از روشهای جدید که قابلیت دسترسی بالا دارند استفاده کنید همانند mirroring و SQL Server 2012 Availability Groups است.
منبع: ^
لینکهای مرتبط:
1. Is the recovery interval guaranteed? ^
2. Scaling and Sharding Deep Freeze ^
3. Why Database Operations Hit the Wall ^
4. Avoiding logging for user operations ^
5. Resolving the Database Performance Problem Blame Game ^