تبلیغات
NiceSoft - معماری SQL Server قسمت هفتم - ساختار Transaction Log

معماری SQL Server قسمت هفتم - ساختار Transaction Log

تاریخ:دوشنبه 24 آبان 1389-07:45 ب.ظ

معماری فیزیكی فایل گزارش تراكنش

فایل گزارش تراكنش می‌تواند با یك یا چند فایل فیزیكی پیاده سازی گردد. منطقا" فایل گزارش تراكنش از تعدادی ركورد پشت سر هم رشته‌ای تشكیل می‌شود و بصورت فیزیكی این ركوردهای پشت سر هم باید بصورت كارا در یك مجموعه از فایلهای فیزیكی پیاده‌سازی گردند.

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

ذخیره اطلاعات در فایل گزارش تراكنش بصورت چرخشی است. برای مثال در شكل زیر یك فایل گزارش فیزیكی كه به چهار قسمت مجازی تقسیم شده نمایش داده شده. هنگام ایجاد بانك اطلاعاتی فایل منطقی گزارش از ابتدای فایل فیزیكی گزارش آغاز می‌شود. و ركوردهای جدید به انتهای فایل منطقی گزارش اضافه می‌شوند و گسترش به سمت انتهای فایل فیزیكی گزارش ادامه می‌یابد. با انجام یك عمل بریدن ركوردهای قبل از قسمت مجازی شامل MinLSN حذف می‌گردند.

هنگامیكه انتهای فایل منطقی گزارش به انتهای فایل فیزیكی گزارش برسد ، ركوردهای جدید بصورت چرخشی دوباره از ابتدای فایل فیزیكی گزارش ذخیره می‌شوند.



این چرخش تا هنگامیكه انتهای فایل منطقی گزارش به ابتدای فایل گزارش فیزیكی نرسد، ادامه خواهد داشت. درصورتیكه ركوردهای تراكنش قدیمی بریده شوند اغلب فضای كافی برای ركوردهای جدید تراكنش تا نقطه كنترل بعدی وجود خواهد داشت و فایل گزارش تراكنش هیچگاه پر نمی‌شود.

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

  • اگر گزینه گسترش خودكار (autogrow) برای فایل گزارش تراكنش فعال باشد و فضای كافی بر روی دیسك سخت وجود داشته باشد ،اندازه فایل فیزیكی گزارش به اندازه تعریف شده افزایش (growth_increment) افزایش یافته و ركوردهای جدید تراكنش در فضای اضافه شده ذخیره می‌شوند.
  • اگر گزینه گسترش خودكار (autogrow) برای فایل گزارش تراكنش فعال نباشد و یا فضای كافی بر روی دیسك سخت به مقدار افزایش تعیین شده) ( growth_increment وجود نداشته باشد، خطای شماره 1105 روی خواهد داد.

در صورتیكه فایل گزارش دارای چندین فایل فیزیكی باشد، فایل منطقی گزارش قبل از چرخش ابتدا به ترتیب بر روی تمام فایلهای فیزیكی گسترش خواهد یافت و در انتها به ابتدای فایل فیزیكی اول چرخش خواهد نمود.


كوچك كردن[1] فایل گزارش تراكنش

 

اندازه فایل گزارش تراكنش بصورت فیزیكی در حالتهای زیر كاهش می‌یابد:

·         هنگام اجرای دستور DBCC SHRINKDATABASE.

·         هنگام اجرای دستور DBCC SHRINKFILE با اشاره به فایل گزارش تراكنش مورد نظر.

·         هنگام اجرای دستور خودكار كوچك شدن (autoshrink).

 

عمل كم كردن حجم فایل گزارش تراكنش به عمل بریده شدن آن بستگی دارد. بریده شدن فایل گزارش تراكنش موجب كم شدن اندازه فیزیكی فایل آن نمی‌گردد ، بلكه اندازه فایل منطقی گزارش را كم می‌كند و قسمتهای مجازی فایل گزارش را كه اطلاعات فایل منطقی را در خود نگهداری نمی‌كنند غیر فعال می‌كند. واحد كاهش اندازه فیزیكی فایل گزارش تراكنش به اندازه یك قسمت مجازی می‌باشد. برای مثال در یك فایل گزارش تراكنش 600 مگا بایتی كه به شش قسمت مجازی 100 مگا بایتی تقسیم شده واحد كاهش اندازه فیزیكی آن در اندازه‌های 100 مگا بایتی می‌باشد و اندازه آن برای مثال می‌تواند به 500 یا 400 مگا بایت كاهش یابد و هیچگاه اندازه آن در این حالت به اندازه‌های 433 و یا 525 مگا بایت كاهش پیدا نمی‌كند.

قسمتهای مجازی فایل گزارش تراكنش كه حاوی گزارش منطقی تراكنشها هستند هیچگاه نمی‌توانند آزاد گردند. و درصورتیكه تمام قسمتهای مجازی نگهدارنده گزارش منطقی تراكنشها باشند عمل كم كردن اندازه فیزیكی فایل گزارش تراكنش نمی‌تواند انجام گیرد. علاوه بر این عمل كم كردن اندازه فیزیكی فایل گزارش تراكنش تنها در صورتی انجام خواهد شد كه قسمتهای مجازی غیر فعال در انتهای فایل گزارش فیزیكی تراكنشها قرار گرفته باشند. هنگام كم شدن اندازه فیزیكی فایل گزارش تراكنش فضاهای خالی باید از انتهای فایل فیزیكی آزاد شوند و قسمتهای مجازی غیرفعال انتهای فایل به اندازه مورد درخواست كاربر آزاد خواهند گردید. اندازه مورد درخواست كاربر (target_size) به سمت قسمت مجازی بعدی  نزدیكترین محدوده قسمت مجازی موجود گرد خواهد گردید. برای مثال اگر كاربر مقدار فضای 325 مگا بایت را برای اندازه فایل گزارش تراكنشی با اندازه 600 مگا‌‌ بایت و قسمتهای مجازی 100       مگا بایتی مشخص كند ، دو قسمت مجازی آخر در صورت غیر فعال بودن حذف شده و اندازه فایل به 400 مگا بایت كاهش می‌یابد.

 

دستورات DBCC SHRINKDATABASE و DBCC SHRINKFILE اندازه فایل فیزیكی تراكنشها را بصورت زیر كم می‌كنند.

  • اگر هیچ قسمتی از فایل منطقی گزارش موجود در قسمتهای مجازی ورای اندازه مشخص شده توسط كاربر نبوده و قسمتهای مجازی بالاتر از فضای درخواستی كاربر غیرفعال باشند ، عمل كم كردن فایل گزارش تراكنش با حذف این قسمتهای مجازی غیر فعال انجام خواهد گردید.
  • اگر قسمتی از فایل منطقی گزارش در قسمتهای مجازی بالای اندازه مشخص شده توسط كاربر باشد.SQL Server هر اندازه از فضا را كه بتواند ( قسمتهای مجازی غیر فعال در انتهای فایل فیزیكی) آزاد می‌كند و یك پیام نیز جهت راهنمائی درباره اعمالی كه می‌توان با انجام دادن آنها  فایل منطقی را از قسمتهای مجازی انتهای فایل خارج نمود ، ارائه می‌نماید. بعد از انجام آن عملیات با اجرای مجدد دستور DBCC فضای باقی مانده آزاد می‌گردد.

 

برای مثال فرض كنید یك بر روی یك فایل گزارش با حجم 600 مگا بایت و 6 قسمت مجازی كه شروع فایل منطقی آن در قسمت مجازی 3 و انتهای فایل منطقی آن در قسمت مجازی 4 قرار دارد، دستور DBCC SHRINKFILE  با target_size 255     مگا بایت را اجرا كنیم.



قسمتهای مجازی 5 و 6 با توجه به اینكه حاوی هیچ قسمتی از فایل منطقی نیستند و در انتهای فایل فیزیكی واقع شده‌اند ، بلافاصله آزاد می‌شوند.  برای رسیدن به اندازه مورد درخواست قسمت مجازی 4 نیز باید آزاد گردد ولی با توجه به اینكه این قسمت حاوی قسمتی از فایل منطقی گزارش می‌باشد این امر ممكن نخواهد بود. بعد از آزادسازی قسمتهای 5 و 6  مدیر بانك اطلاعاتی SQL Server  فضای خالی باقی مانده از قسمت مجازی 4 را با ركوردهای ساختگی[2] پر می‌كند. این عمل باعث میشود كه انتها فایل منطقی گزارش بر ابتدای قسمت مجازی 1 منطبق می‌گردد. و اطلاعات تمام تراكنشهای اصلی موجود در قسمت مجازی 4 به قسمت مجازی 1 منتقل می‌شوند.



دستور DBCC SHRINKFILE  همچنین یك پیام مبنی بر اینكه تمام فضای مورد درخواست آزاد شده است و اینكه برای آزاد سازی احتمالی بقیه فضا باید از دستور  BACKUP LOG  استفاده نمود ، نمایش می‌دهد. بعد از انتقال قسمت فعال فایل گزارش به قسمت مجازی 1 ، دستور BACKUP LOG قسمت مجازی شماره 4 را می‌برد (truncate).




با توجه به اینكه قسمت مجازی 4 دیگر هیچ قسمتی از فایل منطقی گزارش را نگهداری نمی‌كند و بریده شده است ، در صورت اجرای مجدد دستور DBCC SHRINKFILE  با target_size  255 مگا بایت ، قسمت مجازی 4 هم آزاد شده و اندازه فایل فیزیكی گزارش تراكنشها به اندازه مورد درخواست كاهش خواهد یافت.





[1] Shrinking

[2] dummy





choc
دوشنبه 17 اردیبهشت 1397 06:03 ب.ظ
The other day, while I was at work, my cousin stole my
apple ipad and tested to see if it can survive a thirty foot drop, just so she can be a
youtube sensation. My apple ipad is now destroyed and she has 83 views.
I know this is completely off topic but I had to share it with someone!
chocolate
دوشنبه 10 اردیبهشت 1397 09:51 ب.ظ
I would like to thank you for the efforts you've put in penning this
site. I am hoping to check out the same high-grade blog posts by you
later on as well. In truth, your creative writing abilities
has encouraged me to get my own blog now ;)
hepatitis c foot pain
سه شنبه 6 تیر 1396 09:11 ب.ظ
Hello, Neat post. There is an issue together
with your website in web explorer, might check this? IE nonetheless is the marketplace chief
and a large component of people will leave out
your magnificent writing due to this problem.
http://bobbistinebaugh.jimdo.com/2016/02/27/chiropodists-favor-shoe-lifts-for-leg-length-imbalances/
یکشنبه 4 تیر 1396 01:02 ب.ظ
Hello my family member! I wish to say that this post is amazing,
nice written and include approximately all vital infos.
I would like to peer more posts like this.
http://shawanabuchenau.bravesites.com
چهارشنبه 20 اردیبهشت 1396 05:33 ق.ظ
My brother recommended I would possibly like this website.
He was entirely right. This put up actually made my
day. You cann't consider simply how much time I had spent for this information! Thank you!
BHW
جمعه 18 فروردین 1396 12:37 ب.ظ
I must thank you for the efforts you've
put in penning this website. I'm hoping to view the same high-grade blog
posts by you later on as well. In truth, your creative writing abilities
has encouraged me to get my own, personal website now ;)
مریمی
دوشنبه 26 اردیبهشت 1390 09:45 ق.ظ
سلام
بسیار عالی و مفید بود
مرسی
AmirAzari
پنجشنبه 22 اردیبهشت 1390 10:25 ق.ظ
Thank's
 
لبخندناراحتچشمک
نیشخندبغلسوال
قلبخجالتزبان
ماچتعجبعصبانی
عینکشیطانگریه
خندهقهقههخداحافظ
سبزقهرهورا
دستگلتفکر