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

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

تاریخ:دوشنبه 24 آبان 1389-08:10 ق.ظ

مبحث Transaction Log در  Sql Server با توجه به قابلیتهای ترمیم و بازیابی اطلاعات از اهمیت ویژه ای برخوردار است و بی تردید درک ساختار و عملکرد آن در تمام مراحل طراحی ، پیاده سازی و پشتیبانی سیستمهای عملیاتی لازم است. امیدوارم که این نوشته ها در این راه مفید باشند. نظرات شما دوستان گرامی موجب خوشحالی است.


نقاط کنترل خودکار[1]

 

SQL Server همیشه بصورت خودکار نقاط کنترل را تولید می‌کند. دوره زمانی بین تولید خودکار نقاط کنترل به زمان وابسته نبوده و به تعداد رکوردهای موجود فایل گزارش تراکنش بستگی دارد. دوره زمانی بین نقاط کنترل می‌تواند خیلی متغییر باشد. درصورتیکه تغییرات کمی در داده‌های بانک اطلاعاتی صورت می‌گیرد این زمان زیاد بوده و در صورت تغییرات زیاد بانک اطلاعاتی زمان وقوع نقاط کنترل کم خواهد بود.

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

  • درصورتیکه از مدل ترمیم کامل[3] و یا گزارش تراکنش انباشته[4] استفاده شود، یک نقطه کنترل هنگامی ایجاد می‌گردد که تعداد رکوردهای جدید ایجاد شده (از نقطه کنترل قبلی) به تعداد رکوردهای برسد که SQL Server تخمین زده که میتواند در زمان مشخص شده برای ترمیم بانک اطلاعاتی در شروع مجدد پردازش نماید.
  • در صورتیکه از مدل ساده برای ترمیم بانک اطلاعاتی استفاده شود ، یک نقطه کنترل خودکار هنگامی ایجاد میشود که 70 درصد فایل گزارش تراکنش پر شود و یا تعداد رکوردهای جدید ایجاد شده (از نقطه کنترل قبلی) به تعداد رکوردهای برسد که SQL Server تخمین زده که می‌تواند در زمان مشخص شده برای ترمیم بانک اطلاعاتی در شروع مجدد پردازش نماید.

نقاط کنترل خودکار در مدل ساده ترمیم قسمت بدون استفاده فایل تراکنش را خواهند برید. در صورتیکه در دو مدل ترمیم  کامل و تراکنش انباشته این عمل صورت نمی‌گیرد.



[1] Automatic Checkpoints

[2] recovery interval

[3] full

[4] bulk-logged

 

تراکنشهای طولانی مدت

قسمت فعال فایل گزارش تراکنش باید شامل تمام تراکنشهای کامل نشده باشد. درصورتیکه در کاربردی از تراکنشهائی استفاده شود که کامل نشوند و یا بازگشت پیدا نکنند SQL Server  نمی‌تواند که MinLSN را به جلو ببرد و این باعث بوجود آمدن دو مشکل می‌گردد :

·     در هنگام شروع مجدد SQL Server تعداد زیادی تراکنش کامل نشده وجود خواهد داشت که در زمان مشخص شده برای ترمیم SQL Server نمی‌توان آنها را ترمیم کرد.

·     فایل گزارش تراکنش ممکن است بعلت اینکه نمی‌توان بعد از رکورد MinLSN را حذف نمود، بسیار بزرگ شود. و این مورد حتی در مورد مدل ترمیم ساده صادق است.(در هر نقطه کنترل خودکار در مدل ساده قسمت غیر فعال فایل گزارش تراکنش حذف می‌گردد که در این حالت این اتفاق روی نمی‌دهد).

 

البته ذکر این نکته ضروری است که قسمت فعال فایل گزارش تراکنش شامل رکوردهای که جهت تکثیر[1] علامت خورده اند نیز میباشد و در صورتیکه در مدت زمان معین عمل تکثیر صورت نگیرد مشکلات گفته شده در بالا نیز در این حالت هم بوجود می‌آیند.

 

بریدن فایل گزارش تراکنش[2]

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

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

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

 

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

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

نکته : بانک اطلاعاتی tempdb همیشه از مدل ترمیم ساده استفاده می‌کند و همیشه در این مدل در  هر نقطه کنترل ، رکوردهای قبل از MinLSN حذف می‌گردند. بنابراین مدل ترمیم ساده برای بانکهای اطلاعاتی که تغییرات داده‌ای آنها زیاد است مناسب نیست و در مواردی که بانک اطلاعاتی حاوی اطلاعات ثابت و یا با حداقل تغییر هستند مناسب می‌باشد. البته در مدل ساده همانگونه که گفته شد اطلاعات تراکنشهای فعال همیشه جهت ترمیم بانک اطلاعاتی توسط SQL Server نگهداری می‌شوند. برای دیدن مدل ترمیم یک بانک اطلاعاتی میتوان از دستور زیر استفاده استفاده نمود.

 

 SELECT  DATABASEPROPERTYEX('dbname','RECOVERY')                       

نتیجه این پرس و جو یکی از جملات FULL , BULK_LOGGED , SIMPLE خواهد بود.

برای تغییر مدل ترمیم بانک اطلاعاتی میتوان از دستور زیر استفاده نمود.

ALTER DATABASE dbname  SET RECOVERY FULL

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

 

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

 

عمل بریده شدن فایل گزارش تراکنشها در موارد زیر اتفاق می‌افتد :

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

 

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

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


                                    

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


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



ادامه دارد قسمت هفتم

[1] replicate

[2] Truncating the Transaction Log




mino monsters 2 evolution hack
شنبه 5 اسفند 1396 08:33 ق.ظ
من بسیار خوشحالم که این وب سایت را کشف کردم. من می خواستم
با تشکر از شما برای آن زمان به دلیل این فوق العاده است
خواندن!! من قطعا هر کمی از آن را دوست داشتم و من نیز هستم
شما به عنوان مورد علاقه خود برای ذخیره اطلاعات جدید در وبلاگ خود ذخیره کردید.
How we can increase our height?
چهارشنبه 22 شهریور 1396 12:26 ب.ظ
Post writing is also a fun, if you be acquainted with after that you can write otherwise it
is difficult to write.
Foot Issues
یکشنبه 15 مرداد 1396 01:33 ب.ظ
Your mode of telling all in this paragraph is actually pleasant, every one be able to simply know
it, Thanks a lot.
 
لبخندناراحتچشمک
نیشخندبغلسوال
قلبخجالتزبان
ماچتعجبعصبانی
عینکشیطانگریه
خندهقهقههخداحافظ
سبزقهرهورا
دستگلتفکر