یکی از مهمترین کارهایی که یک مدیر پایگاه داده میتونه داشته باشه , داشتن یک طرج یا پلن برای پشتیبان گیری کارا و موثر از دادها با توجه به شرایط هست تا در مواقع بروز نقص فنی بتونه کمترین گمشدگی داده رو داشته باشه . در این مقاله نگاهی به Database Files و Database File group میاندازیم و سپس به انواع SQLServer Recovery Mode میپردازیم . Database FileGroups حال که در مورد انواع فایلها آشنا شدم بهتره که در مورد File group ها هم بدونیم . File Group ها بر خلاف مورد قبلی به هیچ عنوان مفهموم فیزیکی ندارند بلکه دارای ساختار منطقی هستند . از File group ها برای مقاصد گوناگونی استفاده میشه .مثلا برای مقاصد Back up گیری و Restore کردن یا جدا کردن اعمال OLTP On-line Transaction Processing از OLAP On-Line Analytical Processing. . اگر با این دو اصلاح نا آشنا هستید باید بگویم OLTP دیتابیسی هست که اعمال خواندن و نوشتن وبروزرسانی زیادی دراون داریم در حالی که در OLAPبیشتر به صورت تنها خواندنی هست و بیشتر از اون در گزارش گیری استفاده میکنیم . ما همیشه Primary File Group رو داریم که میتونه حاوی فایلهای mdf و ndf باشه . همچین میتونیم File Group های اختیاری دیگری رو هم داشته باشیم که به اونها User Defined File Group’ گفته میشه که تنها میتونه حاوی فایلهای ndf باشه . علیت اینکار میتونه دلایل متفاوتی داشته باشه . تصور کنید که در دیتابیس شما جدولی وجود دارد که بر خلاف دیگر جدولها بسیار بزرگ هست و متناوب از سوی کاربر درخواست خواندن دارد . در این شرایط میتونیم اون جدول خاص رو در یک فایل ndf مجزا در یک درایو یا هارددیسک مجزا قرار دهیم . به این طریق کارایی برنامه ما بالاتر خوهد رفت . نکته دیگر اینکه فایلهای Transaction Log ما یا همان ndf درون File group ها قرار نمیگیرند . ما میتونیم هنگام تعریف جدول جدید آن را به یک File Group مشخص انتصاب بدیم , البته باید اینجا File Group رو ایجاد کرده باشیم . از پنل Properties قسمت Table Designer مقدار Text/Image Filegroup را به file group مورد نظر انتصاب میدیم . [h=3]Recovery Models[/h] حال به بحث اصلی مان برمیگردیم . تعین Recovery Model برای دیتابیس نقش مهمی در تعین استراتژی ما برای Disaster recovery بازی میکنه . اگر بخواهیم خیلی ساده هدف Recovery Models رو بیان کینم , میتونیم بگیم برای این بوجود اومده تا نحوه نگهداری یا maintenance فایلهای T-Log رو مدیریت کنه . Full Recovery Model این مدل که پیشفرض هم میباشد , کاملترین نوع هست که کمترین کمشدگی داده رو داریم . در اینجا ما( PIT ( Point In Time Restore رو داریم یعنی میتونیم به هر لحظه ای از زمان دیتابیس رو برگردونیم . مناسب دیتابیس های OLTP هست و نیازمند Back up گیری مستمر از Log هست . Simple شرایطی رو در نظر بگیرید که در صورت Failure برای شما کافی باشد که تنها به وضعیت آخرین Back up گیری برگردید و لازم نداشته باشید که به یک زمان مشخص برگردید , در این صورت Simple مناسب حال شماست . مثلا فرض کینید که شما همیشه آخر شب Back up میگیرید و یک Failure در ساعت 10 صبح برای شما رخ میده . در صورتی که مد Simple باشید , داده های بین ساعات 12 شب تا 10 صبح رو از دست خواهید داد و اگر این برای شما اهمیتی نداشته باشد که دادهای بین آخرین Back up تا زمان Failure رو از دست بدهید از مد Simple استفاده کنید . در این مد شما به Back up گیری از فایل log نیازی ندارید , PIT Recovery رو ندارید و Maintenance سادست و بیشتر مناسب دیتابیس های OLAP هست . Bulk-logged این مد با Full تفاوت چندانی ندارد , تنها تفاوت آنها در اعمال Bulk انبوه هست . مثلا فرض کنید دادههایی رو از دیتابیسی دیگر به این دیتابیس Import میکنید , در اینجا تنها یک Transaction در فایل لاگ ثبت میشود در صورتی که اگر در مد full بود , به تعداد رکورهایی که درج میشد تراکنش ثبت میشد . به عبارت جامعتر , در این مد اعمال Bulk یا انبوه به صورت minimal لاگ میشود . اگر ما یک میلیون رکورد رو به صورت انبوه درج میکردیم , به ازای همه اون یک میلیون ما تنها یک تراکنش در فایل لاگ ذخیره میکردیم در حالی که در مد Full یک میلیون تراکنش ثبت میشد . در اینجا ما PIT Restore رو نداریم . نکته مهمی که باید به خاطر داشته باشید این است که در صورتی که در مد Full or Bulk -logged هستید , حتما باید از فایل لاگ Back up بگیرید تا Trancate شود در غیر اینصورت این فایل آنقدر رشد خواهد کرد و تمام فضای درایو رو به خودش اختصاص خواهد داد . بعضا دیتابیس هایی دیده شده است که علیرغم اینکه حجم فایل mdf آن کم است , حجم فایل log آن چندین برابر mdf آن هست . این ناشی از Back up گیری نکردن از فایل log هست .
