Truncating the Transaction Log
اگر رکوردهای موجود در فایل منطقی Transaction Log هیچگاه حذف نشوند ، این فایل به اندازه کل فضای موجود بر روی دیسک سخت که توسط فایلهای فیزیکی Transaction Log نگهداری می‌شوند گسترش می‌یابد. گاهی اوقات ، دیگر نیازی به رکوردهای تراکنش قدیمی جهت ترمیم و احیاء بانک اطلاعاتی نبوده و باید آنها برای ایجاد فضا جهت رکوردهای جدید حذف شوند. عمل حذف رکوردهای تراکنش جهت کم کردن حجم Transaction Log را Truncating the Transaction Log می‌گویند.

قسمت فعال Transaction Log هیچگاه نمی‌تواند بریده شود. قسمت فعال Transaction Log همیشه جهت ترمیم بانک اطلاعاتی، مورد نیاز می‌باشد. همانگونه که قبلا" گفته شد رکورد شروع قسمت فعال Transaction Log توسط شماره رکورد MinLSN مشخص می‌گردد.

مدل ترمیم انتخابی بانک اطلاعاتی مشخص می‌کند که چه تعداد رکورد تراکنش قبل از قسمت فعال باید نگهداری شوند. هر چند که رکوردهای تراکنش قبل از رکورد MinLSN در ترمیم تراکنشهای فعال هیچ نقشی ندارند ولی آنها جهت ترمیم بانک اطلاعاتی هنگام بازیابی پشتیبان Transaction Log ها تا نقطه خرابی مورد نیاز می‌باشند. در صورت از دست دادن بانک اطلاعاتی به هر دلیل میتوان با بازیابی آخرین پشتیبان بانک اطلاعاتی و سپس بازیابی Transaction Log ها بعد از آن پشتیبان به ترمیم بانک اطلاعاتی پرداخت. این بدین معنا است که مجموعه پشتیبانهای Transaction Log ها باید شامل تمام تراکنشهای بعد از پشتیبانگیری از بانک اطلاعاتی باشند و هنگام نگهداری پشتیبانهای Transaction Log تا هنگام ذخیره نشدن پشتیبان Transaction Log هیج رکوردی نباید حذف گردد.

رکورهای تراکنش قبل از MinLSN تنها برای ایجاد پشتیبان Transaction Log ها مورد استفاده قرار می‌گیرند.


  • در مدل ترمیم ساده ، Transaction Log ها نگهداری نمی‌شوند و تمام رکوردهای تراکنش قبل از MinLSN در هر زمانی بجزء هنگامیکه دستور پشتیبانگیری در حال پردازش باشد می توانند بریده شوند. گزینه های NO_LOG و TRUNCATE_ONLY تنها گزینه های دستور BACKUP LOG هستند که برای مدل ترمیم ساده معتبر می‌باشند که البته در جای خود بیشتر توضیح داده خواهند شد.


نکته : بانک اطلاعاتی tempdb همیشه از مدل ترمیم ساده استفاده می‌کند و همیشه در این مدل در هر Checkpoint ، رکوردهای قبل از MinLSN حذف می‌گردند. بنابراین مدل ترمیم ساده برای بانکهای اطلاعاتی که تغییرات داده‌ای آنها زیاد است مناسب نیست و در مواردی که بانک اطلاعاتی حاوی اطلاعات ثابت و یا با حداقل تغییر هستند مناسب می‌باشد. البته در مدل ساده همانگونه که گفته شد اطلاعات تراکنشهای فعال همیشه جهت ترمیم بانک اطلاعاتی توسط SQL Server نگهداری می‌شوند. برای دیدن مدل ترمیم یک بانک اطلاعاتی میتوان از دستور زیر استفاده استفاده نمود.
 SELECT  DATABASEPROPERTYEX('dbname','RECOVERY')

نتیجه این پرس و جو یکی از جملات FULL , BULK_LOGGED , SIMPLE خواهد بود.
برای تغییر مدل ترمیم بانک اطلاعاتی میتوان از دستور زیر استفاده نمود.
ALTER DATABASE dbname  SET RECOVERY FULL


  • در مدلهای ترمیم کامل و یا bulk_logged ، رکوردهای تراکنش جهت پشتیبان گیری از Transaction Log نگهداری می شوند و رکوردهای تراکنش قبل از MinLSN تا قبل از اینکه از Transaction Log پشتیبان گرفته نشود قابل حذف نخواهند بود.

توضیح : در مدل ترمیم کامل تمام عملیات داده ای انجام شده در بانک اطلاعاتی بصورت کامل در Transaction Log ثبت می‌شوند، بنابراین میتوان عمل ترمیم را تا یك نقطه و یا تراکنش مشخص انجام داد. برای حفاظت صددرصد داده‌ها مدل ترمیم کامل بهترین انتخاب است. در مدل ترمیم کامل با توجه به ثبت تمام عملیات بر روی داده‌ها ، حجم عملیات ثبت بالا می رود هر چند این مدل بهترین حفاظت از داده‌ها را فراهم می‌کند ولی بسته به مورد شاید استفاده از مدلهای دیگر نیازها را برآورده کرده و در نتیجه سربار نوشتن داده های کمتری نیز داشت. در مدل ترمیم Bulk_Logged داده‌های تغییر یافته توسط دستورات SELECT INTO ،BULK INSERT، CREATE INDEX و عملیات بر روی فیلدهای Text و (Binary (WRITETEXT , UPDATETEXT که معمولا داده‌های زیادی توسط آنها نوشته می شود در فایل گزارش تراکنش ثبت نمی‌شوند بلکه تصاویر صفحات تغییر یافته ثبت می‌شوند و بدین ترتیب در این مدل ترمیم بانک اطلاعاتی تا انتهای هر پشتیبان Transaction Log ، که شامل تراکنشها و تصاویر صفحات تغییر یافته است امکان پذیر بوده و ترمیم تا یک زمان یا تراکنش خاص امکان پذیر نخواهد بود.

عمل Truncating the Transaction Log در موارد زیر اتفاق می‌افتد :

  • در انتهای اجرای کامل هر دستور BACKUP LOG.
  • هنگام وقوع یک Checkpoint در مدل ترمیم ساده (چه این Checkpoint توسط دستور صریح CHECKPOINT یا بصورت خودکار توسط سیستم ایجاد گردد) تنها درصورتیکه دستور BACKUP فعال باشد عمل Truncating انجام نخواهد شد.

Transaction Log ها به قسمتهایی بنام قسمت مجازی (Virtual Log File) تقسیم می‌شوند. قسمتهای مجازی واحد بریده شدن تراکنشها از Transaction Log می‌باشند. هنگامیکه یک Transaction Log بریده می‌شود تمام رکوردهای تراکنش قبل از قسمت مجازی شامل MinLSN ، حذف می‌گردند.

شکل زیر یک فایل Transaction Log با چهار قسمت مجازی را نمایش می‌دهد. این فایل بعد از ایجاد هیچگاه Truncate نشده است. گزارش منطقی از قسمت مجازی یک شروع شده و در پایان قسمت مجازی چهار تمام می‌شود و فضای بالای قسمت مجازی چهار استفاده نمی‌شود.
ضمیمه 67726

شکل زیر همان Transaction Log را بعد از Truncate شدن نشان می‌دهد. همانگونه که ملاحظه می‌گردد قسمتهای مجازی قبل از قسمت مجازی شامل MinLSN بریده شده‌اند.
ضمیمه 67727

Truncate شدن Transaction Log اندازه فیزیکی فایل Transaction Log را کم نمی‌کند بلکه اندازه فایل گزارش منطقی را کاهش می‌دهد. با عمل shrink می‌توان حجم فیزیكی فایل Transaction Log را کم كرد. که در ادامه مطالب در جای خود بیشتر توضیح داده خواهد شد.


مكانيزم Transaction
هر عملي كه باعث تغيير در Database مي شود داراي 2 وضعيت مي باشد . يا اجرا شده يا با رخداد Error متوقف مي شود. حال براي اجراي چندين دستور در غالب يك دستور بايستي طوري عمل شود تا يا تمامي دستورات اجرا شده يا به ازاي رخداد يك خطا ، هيچيك از آن دستورات اجرا نشود. از اين رو بايستي مكانيزمي وجود داشته باشد تا اين كار مديريت شود .
Transaction شيي است كه با كمك آن اين كار انجام ميشود . دستوري كه به Database ارسال ميشود ابتدا در Log File مربوط به آن Database ثبت شده و تا پايان زمان نوشتن آن در Data File كل عمليات باز مي باشد . در اين حالت ميگويند "تراكنش باز است و در صورت موفقيت آميز بودن اجراي دستورات و ثبت كامل درData File تراكنش Commit خواهد شد .در صورت عدم موفقيت تمامي دستورات از Transaction Log ، Rollback ميشود .
به عنوان مثال :
Begin Tran
Update …..
Inert ….
Delete ....
اگر خطايي رخ ندهد Commit <كنترل رخداد خطا >
در صورت بروز خطا Rollback
در صورت بروز خطا هيچيك از دستورات فوق اجرا نمي شود و در صورت عدم بروز خطا همگي اجرا مي شود .
بنا به تنظيمات Recovery Model در دیتابیس ، Transaction Log ارسالي در Log file بصورت تاريخچه ايي باقي مي ماند و يا از Log File خارج مي شود .
از اين رو از Log File مي توان در كارهاي زير استفاده کرد:

  1. بازيابي دیتابیس از طريق تراكنشهاي قبلي (تاريخچه ايي)
  2. بازيابي دیتابیس در زماني كه سرويسهاي Start ، SQL Server مي شود (بصورت پيش فرض تمامي تراكنشهاي باز از Rollback ، Log File مي شود).
  3. بازيابي دیتابیس در زماني كه دیتابیس خراب مي شود و مي خواهيم در زماني مشخص دیتابیس را بازسازي كنيم.
  4. انتشار اطلاعات (Replication) از نوع Transactional از Transaction Log استفاده مي كند.
  5. براي راه اندازي Stand By Server ( راه كاري براي ايجاد بستر مطمئن در نگهداري دیتابیس) از Transaction Log استفاده مي شود.

با توجه به مطالب فوق نگهداري Transaction Log يكي از مهمترين امكاناتي است كه مي تواند در نگهداري دیتابیس و پشتيباني مطمئن از آن مورد استفاده قرار گیرد. از اين روي Transaction Log Backup راه كاري براي مراقبت مناسب از Log File مي باشد .