نکات شرینک کردن فایل های دیتابیس در SQL Server

با ايده گرفتن از Arik Poznanski نتيجه گيريم رو از شرينك كردن فايل هاي ديتابيس اول مينويسم

«شرينك كردن در صورت نياز»

ما دو نوع شرينك كردن داريم

  • شرينك كردن ديتا فايل (خيلي بد)
  • شرينك كردن لاگ فايل (بد)

يه سري مفاهيم اوليه در شرينك هست كه در هر دو نوع شرينك ثابته اول اين مفاهيم رو مرور كنيم.
وقتي فايل هاي ديتابيس ميخوان بزرگ بشن بر اساس Autogrowth ي كه ست كرديد اون مقدار مورد نظر براي اطمينان از نداشتن بد سكتور بايد zero byte فرمت بشه حال فرض كنيد رشد بانك به صورت درصدي باشه (كه به صورت پيشفرض هست) و ديتابيس شما گيگا بايتي باشه چه حجم زيادي بايد zero byte فرمت بشه و اين يعني افت Performance. البته خبر خوب اينه كه عمل بزرگ شدن فايل از SQL Server 2005 به بعد فقط براي ديتا فايل با zero byte فرمت انجام نميشه (Instant File Initialization).همه اينا رو گفتم تا برسم به اينجا كه بزرگ شدن فايل يه عمليات زمانبريه پس اگه شما از نظر حجم Storage مشكلي نداريد تا جاي كه امكان داره فايلهاي ديتابيستون رو شرينك نكنيد.

چرا شرينك كردن ديتا فايل خيلي بده!
وقتي شما ديتا فايلتون رو شرينك ميكنيد SQL مياد Extent (واحدي هست براي مديريت فضا شامل هشت Page پشت سر هم) هاي آخر فايل رو بدون توجه به ترتيب منطقي Page ها و Index ها تو قسمت هاي خالي اول فايل ميزاره و اين يعني تك تكه شدن (Fragmentation) ايندكس هاي شما (البته Clusterd ها) بنابراين كلا بيخيال اين نوع شرينك بشيد…
نکته:شرینک کردن با سویچ TRUNCATEONLY این جابجائی Extend ها رو نداره
همونطور كه ميدونيد شرينك كردن يكي از Task هاي موجود در Maintenance Plan هستش و بقول استادم

SQL Server ي كه Maintenance Plan نداشته باشه معلومه DBA بالاسرش نيست

پس تقريبا همه سرور ها Maintenance Plan رو دارن چندتا نكته

  • شرينك كردن رو تا حد ممكن اتومات نكنيد
  • با انجام Rebuild Index و بعد Shrink فقط و فقط وقت و منابع وكارايي و… سرور رو هدر كردين.دلیلش چيه؟

چرا شرينك كردن لاگ فايل بده؟
وقتی شما لاگ فایلتون (Transactional Log File) رو شرینک میکنید همونطور که قبلا گفتم با توجه به اینکه لاگ فایل باید zero byte فرمت بشه موقع بزرگ شدن فایل بسته به میزان Autogrowth انتخابی سیستم شما افت Performance داره.البته از بین دو نوع شرینکی که گفتم انجام این نوع شرینک منطقی هست که البته بیشتر افراد برای «پراندن لاگ» میان لاگ فایل رو شرینک میکنن پس اگه شما مشکل حجم Storage ندارید میتونید این نوع شرینک رو هم انجام ندید توجه کنید تمام این پیشنهاد های که داده میشه با توجه به اینه که مدل Recovery شما رو FULL ست شده.

یک نکته مهم «Truncate شدن لاگ اندازه فیزیکی اونو کم نمیکنه»

همنطور که میدونید اگه مدل Recovery شما FULL باشه بعد از لاگ بکاپ گرفتن لاگ فایل شما Truncate میشه ولی نکته مهم اینه Truncate شدن لاگ اندازه فیزیکی اونو کم نمیکنه بلکه اون قسمت رو مجددا قابل نوشتن میکنه.همنطور که گفتم انجام این نوع شرینک منطقی هست. کی و کجا؟
فرض کنید شما تو سرور ساعت 5 صبح Maintenance Plan تعریف کردید و همیشه میبنید که لاگ بکاپ ساعت 7 صبح شما خیلی بزرگه مشکل کجاس؟
تمام عملیات Maintenance Plan تو لاگ نوشته میشه(والبته تمام عملیات SQL Server به صورت write-ahead) و این باعث میشه لاگ فایل شما بزرگ بشه و چون حتی پس از لاگ بکاپ گرفتن این فضا کم نمیشه ازاینرو یکی از جاهای که میشه لاگ رو شرینک کرد(پراند) اینجاس.البته برای کم کردن اندازه لاگ بکاپ ساعت 7 فکر میکردم تغییر مدل Recovery به BULK_LOGGED جواب بده ولی نوچ!(باید بشتر مطالعه کنم)

در آخر شما Auto_Shrink رو تو SQL Server فعال میکیند؟

نظرات

ارسال یک نظر

پست‌های معروف از این وبلاگ

lnav ابزاری بسیار کاربردی برای پیمایش لاگ ها در لینوکس و البته مک

تصویر
خب گرمی هوا و تعطیلی فرصتی شد برای نوشتن درباره lnav   طبق تعریف رسمی lanv خودش رو یک نمایش دهنده لاگ فایل که UI اون بر پایه ncurses(رابط کاربری مبتنی بر متن مثل norton commander ) هست میدونه و اما قابلیت ها ادغام و نمایش چندین لاگ فایل در یک پنجره خیلی پیش میاد برای ریشه یابی یک مشکل مجبور باشیم چندین لاگ رو همزمان بررسی کنیم.وقتی چندین فایل رو با هم باز میکنیم براساس timestamp خطوط لاگ رو نمایش میده و به کمک رنگ های متفاوت هر خط رو متمایز میکنه lnav /var/log/messages /var/log/secure تشخیص خودکار فرمت لاگ به صورت داخلی و پیش فرض lanv از لیست بلند بالایی از فرمت ها پشتیبانی میکنه مثلا اکثر وب سرور ها مثل nginx اگرهم فرمت مدنظر شما داخل این لیست نیست امکان تعریف فرمت شخصی رو هم دارید. فیلترکردن لاگ های حجیم قبل از بازکردن معمولا پیش میاد که با یک فایل چند گیگ ی کارداریم و فقط میخواهیم مثلا سطح  WARN ها رو ببینیم . در مثال زیر اگر دقت کنید خروجی شامل کلی لاگ DEBUG هست ولی با کمک فیلتر رسیدیم به چندین خط و البته میتونیم چندین نوع فیلتر دیگه هم داشته باشیم مثلا regex و ... م...
Read more »

ساختن ایمیج های داکری به کمک BuildKit - بخش دوم

تصویر
 خب با یک فاصله طولانی از بخش اول میرسیم به بخش دوم ساختن ایمیج های داکری به کمک BuildKit در این قسمت قراره درباره امنیت و در واقع امن کردن داکرفایل یا ایمج هامون صحبت کنیم.وقتی که نیاز داریم مثلا به یک مخزن خصوصی وصل بشیم یا یک فایل رو از یک سایت خاص💪 مثلا sonaops.ir دانلود کنیم یا ... و مجبوریم یک سری اطلاعات شخصی (نام کاربری رمز عبور و...) رو وارد کنیم در صورت رعایت نکردن یکسری اصول امنیتی ایمیج ما مستعد خرابکاری میشه و...  تا قبل از BuildKit یک روش استفاده از ARG داخل داکر فایل و مقداردهی اون هنگام build به کمک build-arg بود (و هست) مشکل این روش اینه که از طریق خواندن تاریخچه ساخت یک ایمیج این اطلاعات درز میکنه و البته از اون بدتر اگه این اطلاعات رو به نوعی داخل ایمیج ذخیره کرده باشید به راحتی قابل دسترسی هست (حتی اگه تو یک مرحله اونو پاک کرده باشید) سرچ زیر تو گوگل احتمالا نتیجه های جالبی رو برگردونه inurl:Dockerfile site:github.com intext:"ARG password" OR intext:"ARG secret" OR intext:"ARG pass" و در ادامه در صورت دستیابی به ایمیج مربوطه docker h...
Read more »

ساختن ایمیج های داکری به کمک BuildKit - بخش اول

تصویر
خب چند سالی هست که داکر راه خوبان رو داره میره و با تعریف پروژه موبی قدم بزرگی تو پشرفت کانتینر سازی (که البته به اشتباه معمولا میگیم داکر سازی و چه اشتباه خوبی ) برداشته.     یکی از زیر پروژه های موبی که اتفاقا بحث اصلی این پست و پست های آتی هست BuildKit نام داره که در واقع ابزاری برای ساخت ایمیج هست که در ابتدا به صورت مجزا قابل استفاده بود(و البته هنوزم هست) و از داکر ورژن 18.09 به صورت داخلی به داکر اضافه شده.   برای استفاده از این بیلدر یا میتونیم متغییر محیطی بنام DOCKER_BUILDKIT رو مقدار دهی کنیم و یا daemon.json رو ویرایش کنیم  export DOCKER_BUILDKIT=1 OR  vi /etc/docker/daemon.json   { "features" : { "buildkit" : true } }  systemctl daemon-reload systemctl restart docker       بعد از تغییر بیلدر پیش فرض داکر خروجی بیلدر هنگام ساخت ایمیج به شکل زیر میشه   نکته : من برای راحتی برای دستور docker دگرنام( alias ) dcr رو انتخاب کردم. در این پست و پست های آتی به برسی قابلیت های مهم BuildKit میپردازیم   پردازش موازی شا...
Read more »