سلام و عرض ادب خدمت دوستان گرامی
امیدوارم حالتون خوب باشه
اگر در جایی مشغول به فعالیت هستید که AlwaysON راه اندازی شده باشه ، ممکنه این سناریو براتون رخ بده
فرض کنید دوتا سرور دارید که بر روی اون AlwaysON راه اندازی کردین و این ها به صورت Synchronous هستند .
حالا سرور دوم از کار افتاده و عملا سبب شده فایل لاگ شما داره به شدت رشد میکنه.
اگر در این حالت دستور زیر رو اجرا کنید.
select name,log_reuse_wait_desc from sys.databases
ملاحظه خواهید کرد که در Wait ها نوشته Availability_group . در این حالت اگر شما بیاین دیتابیس رو از Availability_Group خارج کنید مشکلی که پیش میاد بهتون خطا میده که Chain در فایل LOG با MDF همخوانی نداره و به نظر میاد دیتابیس شما به مشکل خورده و نه میشه ازش Backup تهیه کرد نه دستورات DBCC اجرا میشه و اگر دیتابیس رو Detach کنید با مشکلات عدیده ای مواجه خواهید شد.
راه حل اول : اینکه ارتباط سرور دوم رو برقرار کنید تا لاگها ارسال شده و این مشکل حل بشه
راه حل دوم : تغییر مد Replica از Synchronous به Asynchronous که سبب میشه این Wait به Log_Backup تبدیل بشه که به راحتی با یک Log Backup مشکل فضای شما حل میشه و مساله ای نخواهید داشت.
اگر اشتباها اومدین دیتابیس رو از Availability group حذف کردین راهش این هست که با استفاده از کد زیر:
use Master
Go
ALTER AVAILABILITY GROUP MyAG ADD DATABASE YourDB;
GO
دیتابیس رو سوری به AlwaysON اضافه کنید و مراحل بالا رو طی کنید.

امیدوارم این نکته مفید واقع شده باشه.
ارادتمند شما
حمیدرضا صادقیان
ID:@Hamidreza_Sadeghian
Channel :@SQL_Server

#Log_FIle #LDF #LOG_Growth #AlwaysON #Availability_GROUP #Log_Backup

یکی از مسائلی که در خیلی از SQL Server ها میبینم این هست که دوستان میان یک جاب تعریف می کنند برای Shrink Log . میشه بپرسم چرا؟
باور کنید این تفکر غلطیه اگر در هر دوره یا کلاسی این رو یاد گرفتین.
اگر Recovery Model دیتابیس شما Full هست و براساس میزان تراکنش ها مرتب ازش Log Backup بگیرید و همچنین سایز اولیه فایل رو درست تعریف کنید خیلی به ندرت پیش میاد که فایل شما رشد کنه. اونم برای زمانی هست که یک تراکنش خیلی بزرگی در سیستم شما درج بشه یا تغییرات عجیب غریبی رخ بده که در اون فضای خالی فایل Log شما قرار نگیره و مجبور به رشد باشه.
یکی از دلایل کندی دیتابیسهاتون میتونه همین مساله باشه.
حالا بیاین با یک مثال بهتون شرح بدم چه بلایی دارید سر SQL Server و OS میارید و مطمئن باشید در پل صراط ، یقه شمارو این دو بزرگوار خواهند گرفت 😁
فرض کنید شما یک پولی رو دادین به یکی که باهاش کار کنه و شما هم از سودش منتفع بشین. خوب تا اینجاش خیلی هم عالیه خوش به حالتون 😅
چالش اینجاست که عصر همون روز میگین شرمنده میشه پولمو بدین من پول کم آوردم. خوب اون بنده خدا هم میگه باشه بیا و واریز می کنه.
دوباره یک ساعت بعد میگین خوب بیا داداش این همون پوله ولی من تیکه تیکه (میزان رشد فایل) بهت این پول رو میدم. میگه باشه چیکار کنیم قبول.
دوباره عصر فردا میشه باز میگین ببخشید میشه پولمو پس بدی من دوباره پول کم اوردم( جبران کمبود فضای دیسک با شرینک کردن فایل لاگ) به محض اینکه پول رو گرفتی دوباره میگی من تا فردا تیکه تیکه بهت این پول رو میدم و این داستان هر روز ادامه داره.
به نظرتون اون شخص با شما چه برخوردی میکنه؟ چی میگه بهتون؟
آفرین ،‌دقیقا OS هم همین حرفهارو بهتون میزنه ولی چون ما توانایی شنیدنش رو نداریم به این رفتار زشت ادامه میدیم.
حالا در این پس دادن فضاو دوباره گرفتن فضا ، تمام دستورات شما باید منتظر بمونه تافضای کافی برای نوشتن داشته باشه و این میشه که وقتی سیستم شلوغه میزان فحش برثانیه به سیستم عزیز شما افزایش پیدا می کنه.
حالا برای اینکه این میزان فحش برثانیه رو کم کنید از همین الان برید این جاب رو کلا حذف کنید و با مدیریت درست لاگ بکاپ و همچنین تنظیم یک فضای اولیه برای این فایل برای همیشه از شر این Shrink کردن های روزانه خلاص بشین.

باشد که رستگار شویم و کمتر فحش بخوریم. 😁

#log_Backup
#TransactionLog
#Shrink