shrink لاگ فایل و نجات دیتابیس - مقدمه

موقعیتی را در نظر بگیرید که حجم لاگ فایل(transaction log file) دیتابیس شما افزایش پیدا کرده، سرعت انجام عملیات به شدت کاهش یافته، فضای دیسک سرور کافی نیست و شما در جستجوی یک روش سریع برای shrink لاگ فایل و نجات دیتابیس جهت جلوگیری از دان شدن سرور هستید. به عنوان یک DBA در چنین موقعیت استرس زایی چه تصمیمی می گیرید؟ به احتمال زیاد اولین گزینه انتخابی شما استفاده از shrink لاگ فایل است. 

در آموزش shrink لاگ فایل و نجات دیتابیس به توضیح دو روش جهت shrink لاگ فایل می پردازیم. مزیت روش اول سریع بودن آن و نقطه ضعفش شکسته شدن زنجیره لاگ بک آپ(log backup chain) است به عبارتی دیگر در این روش قابلیت  Point In time recovery یا PTR را از دست خواهیم داد که در ادامه به توضیحات بیشتری در این رابطه اشاره می کنیم. روش دوم نسبت به روش اول کندتر است اما باعث شکسته شدن زنجیره بک آپ های تهیه شده از لاگ فایل نمی شود.

---

shrink لاگ فایل و نجات دیتابیس - معرفی دو روش

قبل از هر چیز بهتر است که میزان حجم مورد استفاده لاگ فایل را بررسی کنیم. با استفاده از دستور DBCC زیر، درصدی از فضای لاگ فایل که قابل استفاده مجدد(reuse) نیست را مشاهده می کنیم:

DBCC SQLPERF (LOGSPACE)

برای لاگ فایل های بزرگ در حالت معمولی می بایست درصد استفاده(Log Space Used) کم و یا نزدیک به صفر باشد. با توجه به اینکه حجم زیادی از لاگ فایل دیتابیس مورد نطر ما(TestUi) در حال استفاده است(Active/Used). بهتر است بررسی کنیم که به چه دلیلی، این حجم از لاگ فایل قابل استفاده مجدد(reuse) نیست. برای این منظور، از کوئری زیر استفاده می کنیم:

select name, log_reuse_wait_desc, recovery_model_desc
   from sys.databases

 در حالتی که recovery model دیتابیس full باشد، اکثر مواقع مقدار "LOG_BACKUP" را در فیلد log_reuse-wait_desc مشاهده می کنیم. در واقع توضیحات موجود در این فیلد بیانگر دلیل عدم استفاده مجدد از فضای لاگ فایل است. مقدار "LOG_BACKUP" به معنای عدم تهیه بک آپ از لاگ فایل می باشد.

در ادامه متناسب با مقدار موجود در فیلد log_reuse-wait_desc می بایست راه حلی برای جلوگیری از رشد لاگ فایل پیدا کنیم به عنوان مثال اگر مقدار “ACTIVE_TRANSACTION” را در این فیلد دیدیم بایستی قبل از  shrink لاگ فایل تراکنش فعال(long-running transaction) که منجر به رشد لاگ فایل و جلوگیری از استفاده مجدد آن شده را شناسایی و آن را commit یا kill کنیم(در آموزشی جداگانه به توضیح مقادیر فیلد log_reuse-wait_desc خواهیم پرداخت). 

shrink لاگ فایل - سریعترین روش

 اگر حجم لاگ فایل شما زیاد است(مثلاً 100 گیگا بایت)، زمان و یا فضای دیسک کافی جهت تهیه بک آپ از لاگ فایلی با حجم 100گیگا بایت را ندارید استفاده از این روش به شما پیشنهاد می شود. اما باید این ریسک را بپذیرید که زنجیره/توالی لاگ بک آپ(log backup chain) را از دست خواهید داد به عبارتی دیگر شما قابلیت بازگشت به اطلاعات در فاصله زمانی بین آخرین بک آپی که از لاگ فایل تهیه کرده اید را با بک آپ differential که بعد از اتمام shrink لاگ فایل تهیه خواهیم کرد از دست می دهید. اما قابلیت Point-in-time recovery را مجدداً پس از تهیه differential backup خواهید داشت. این روش بیشتر از یک دقیقه طول نخواهد کشید حتی در مورد لاگ فایل های با حجم بسیار بالا

در ابتدا لازم است که نام لاگ فایل دیتابیس مورد نظر را داشته باشیم. برای این منظور می توانیم از properties و قسمت files دیتابیس مورد نظر استفاده کنیم و یا با استفاده از sp_helpfile بصورت زیر، نام لاگ فایل را استخراج کنیم:

 

--می شود point-in-time recovery این روش باعث از دست دادن 
alter database TestUi set recovery SIMPLE
 
--Trucate انجام 
CHECKPOINT --  آماده سازی لاگ فایل جهت استفاده مجدد
 

--کاهش حجم لاگ فایل به یک مگابایت 
DBCC SHRINKFILE('TestUi_log', 1)

در این روش ابتدا recovery model دیتابیس را به simple تغییر می دهیم و در ادامه با استفاده از دستور checkpoint رکوردهای لاگ موجود در حافظه را به دیسک و فایل ldf منتقل می کنیم و به عبارتی دیگر، فایل لاگ را جهت استفاده مجدد آماده می کنیم و در پایان با استفاده از دستور DBCC SHRINKFILE عملیات shrink لاگ فایل را انجام می دهیم(جزئیات بیشتر در مورد دستور SHRINKFILE و تفاوت truncate و shrink در آموزش جداگانه ای توضیح داده می شوند). بعد از انجام مراحل بالا لازم است که مجدداً recovery model دیتابیس را به full برگردانیم:

 
alter database TestUi set recovery FULL
 

همانطور که می دانید برای تغییر recovery model از simple به full بایستی بعد از اجرای دستور بالا، حتماً یک بک آپ Full و یا Differential از دیتابیس TestUi تهیه شود. با توجه به اهمیت سریع انجام شدن عملیات، ترجیحاً یک differential backup از دیتابیس تهیه می کنیم:

--بعد از تهیه بک آپ زیر انجام خواهد شد full recovery model تغییر به 
backup database MyDatabase to disk='D:\mydb.dif'
with differential, compression, stats

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

در توضیح نکته بالا، به جای استفاده از TRUNCATEONLY  به عنوان پارامتر دوم دستور DBCC SHRINKFILE از یک مقدار عددی(واحد آن مگابایت است) استفاده کنیم.

 shrink لاگ فایل - روش دوم

اگر حفط قابلیت  point-in-time recovery برای سازمان از اهمیت بالایی برخوردار است(معمولاً در سیستم های حساس اینگونه است)، زمان و فضای کافی جهت تهیه بک آپ از لاگ فایل را دارید و یا اینکه حجم لاگ فایل زیاد نیست، استفاده از این روش به شما پیشنهاد می شود. در این روش ابتدا یک بک آپ از لاگ فایل تهیه می کنیم. این کار را با استفاده از ویزارد، اجرای job و یا اسکریپت زیر می توانید انجام دهید:

BACKUP LOG TestUi TO DISK='D:\transactionLog1.trn'
WITH COMPRESSION, STATS

متناسب با حجم لاگ فایل ممکن است انجام عملیات بالا زمانبر باشد. در ادامه مانند روش اول، نیاز به دانستن نام فایل جهت shrink لاگ فایل داریم:

DBCC SHRINKFILE('TestUi_log', 1) -- کاهش حجم لاگ فایل به یک مگابایت

نکته: برخی مواقع لازم است مراحل بالا(تهیه بک آپ از لاگ فایل و اجرای دستور SHRINKFILE) را چند دفعه تکرار کنید(معمولاً یک یا دو مرتبه کفایت می کند).

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

---

shrink لاگ فایل و نجات دیتابیس - جمع بندی

با توجه به اینکه معمولاً shrink لاگ فایل توسط ادمین های دیتابیس انجام می شود، در آموزش shrink لاگ فایل و نجات دیتابیس از پرداختن به مباحث ابتدایی اجتناب شد و بیشتر تمرکز بر روی ارائه روش های shrink لاگ فایل قرار گرفت. همانطور که در طول آموزش اشاره شد یک نکته مهم در رابطه با shrink لاگ فایل پیداکردن دلیل حجیم شدن و رفع آن، قبل از اجرای عملیات shrink است. در آموزش هایی جداگانه به نحوه مدیریت حجم لاگ فایل، تفاوت دو عملیات truncate و shrink، نحوه تشخیص اینکه لاگ فایل دیتابیس ما قابل shrink هست یا نه خواهیم پرداخت.

  

 

• قبلی
• بعدی