درباره نویسنده

مسعود طاهری

مسعود طاهری

عاشق علیرضا (پسرم) و همسرم. در ضمن SQL Server را هم دوست دارم.

16 دیدگاه

  1. داوود طاهرخانی

     خوب و جامع مانند همیشه مهندس

    پاسخ
  2. محمدرضا

     سلام

    عالی بود خسته نباشید
    پاسخ
  3. غلامحسین عبادی

     ممنون عالی بود . متشکرم

    پاسخ
  4. محمدرضا احمدی

    محمدرضا احمدی

    سلام خسته نباشید

    واقعا جامع و عالی بود 
    ممنون بابت اینکه این مطالب رو در اختیار کاربران قرار میدید
    پاسخ
  5. عادل تنهایی

    عادل تنهایی

        با تشکر از مطالب مفید 

    چند تا سوال داشتم 
    1- آیا بعد از shrink به صورت TruncateOnly فضای از دست رفته در صورت نیاز دوباره تخصیص داده می شود؟
    2- بهتر نیست زمانی که فضای اشغالی زیاد نیست همیشه shrink را بصورت NoTruncate انجام و سپس REbuild کنیم؟
    پاسخ
    1. مسعود طاهری

      مسعود طاهری

      سلام 

      پاسخ سوال 1 : این موضوع بستگی به تنظیمات Growing فایل شما دارد. در صورتیکه فایل نیاز به رشد داشته باشد رشد آن با توجه به این مقدار انجام می شود.
      پاسخ سوال 2 : خیر. هزینه اینکار بسیار زیاد است. Fragment شدن ایندکس ها (البته خود Rebuild کردن ایندکس هم هزینه بر است)
      تا جایی که امکان دارد سرغ Shrink نروید استفاده از آن در برخی موارد اجتناب ناپذیر بوده اما اگر مجبور به انجام آن شدید حتما ایندکس های خود را Rebuild کنید
      پاسخ
  6. احسان حسین پور

    احسان حسین پور

    جناب آقای طاهری
    ضمن تشکر از مطالب مفیدی و پرکاربردی که ارایه میدین.

    DBCC SHRINKDATABASE(DatabaseName) رو بدون NOTRUNCATE و  TRUNCATEONLY اجرا کنیم بصورت پیش فرض کدوم پارامتر در نظر گرفته می شود.

    امکانش هست راه های برخورد با Fragmentation رو توضیح بدین ، یا اگر لینکی در این زمینه وجود داره ارایه بدین.

    با تشکر

    پاسخ
  7. مسعود طاهری

    مسعود طاهری

        پاسخ سوال 1

    DBCC SHRINKDATABASE(YourDB) = DBCC SHRINKDATABASE(YourDB, 0)
    این دو حالت با هم برابر هستند و تاثیر بر روی دیتا فایل می باشد. عموما بعد از اینکار هم حجم لاگ افزایش پیدا می کند.و در ضمن بهتر است شما از دستور Dbcc ShrinkFile استفاده کنید و مشخص کنید که کدام فایل را می خواهید Shrink کنید. 

    پاسخ سوال 2 
    برای جلوگیری از Fragmentation بهتر است.
    1- Rebuild و Reorganize را فراموش نکنید این موضوع مشکلات Fragment شدن ایندکس ها را تا حد ممکن حل می کند
    2- تنظیم Fill-factor به ازای ایندکس ها

    در ضمن یکی از حالت هایی که باعث بوجود آمدن Fragmentation می شود در لینک زیر شرح داده شده است

    تمامی این موارد در دوره Performance (ارائه شده توسط وب سایت نیک آموز) به طور کامل شرح داده شده است.
    ضمنا تا جایی که امکان دارد از Shrink کردن دیتا فایل پرهیز کنید در صورتیکه مجبور شدید Rebuild کردن ایندکس ها فراموش نشود.
    پاسخ
  8. مصطفی عینی

    مصطفی عینی

       واقعا ممنون

    استفاده کردیم

    پاسخ
  9. جواد

       با سلام خدمت استاد و تشکر از شما
    موفق و سلامت باشید.

    پاسخ
  10. مینا نفری

        با سلام

    دلیل افزایش حجم logFile تقریبا به اندازه نصف حجم DataFile چه می تواند باشد ؟
    پاسخ
  11. مهران محمدیان

    سلام مهندس طاهری عزیز // یه سوال : ما یه دیتابیس داریم حدود 800 گیگ و بدلیل حذف اطلاعات یک جدول برای آزاد سازی فضای مورد نظر نیاز به Shirink داریم// که زمانی که ما خواستیم دیتابیس را شیرینک کنیم حدود 50 ساعت طول کشید آیا راه حلی برای افزایش سرعت شیرینک داریم؟

    پاسخ
    1. مسعود طاهری

      مسعود طاهری

      معمولا در زمان Shrink بهتر است Transaction طولانی باز نداشته باشید و کارهای سنگین روی دیتابیس انجام ندهید – اما واقعیت امر این است که این دستور زمان زیادی …
      باید حواستان باشد که Shrink هم باعث Blocking نشود ….
      این پروسه باید در حین اجرا مانیتور شود و مشکلات Blocking و… این رفع و رجوع شود
      در هر حالت در حجم بالا زمان طولانی است

      پاسخ
  12. محمدحسین فخرآوری

    بسار خوب

    پاسخ
  13. پدرام

    سلام مهندس و وقت شما بخیر و تشکر بابت مطلب مفید و کامل
    مهندس میخوام ببینم چه چیزهایی رو حجم فقط “لاگ” دیتابیس تاثیر داره ؟
    من خیلی وقت پیش ها با یه دیتابیس روبرو شدم که دیگه رشد حجم لاگ فایلش نرمال نبود و خیلی سریع رشد میکرد با اینکه تغییر آنچنانی رو سیستم و حجم کار ایجاد نشده بود.
    پیشاپیش ممنون بابت پاسختون .

    پاسخ
    1. جواد اسماعیلی

      جواد اسماعیلی

      با سلام
      رشد لاگ فایل به خیلی موارد بستگی دارد، به احتمال خیلی زیاد Recovery Model دیتابیس شما حتما روی حالت Full می‌باشد یکی از علت اصلی رشد لاگ فایل این مورد هست.
      مورد دوم شاید یک Begin Transaction باز گذاشتید مثلا چند هزار رکورد اطلاعات باید تغییر کند و همین موضوع دارد Commit هنوز انجام نگرفته این موضوع می‌تواند باعث رشد لاگ فایل شود.

      مورد سوم شاید Recovery Model بانک شما در حالت Simple قرار دادید اما دستوری که سمت SQL ارسال شده بیشتر از سایز لاگ فایل است در این حالت لاگ فایل مجبور است رشد کند.

      و سایر موارد که باید سناریو را دید تا تشخیص بهتری داد.

      پاسخ

ارسال یک نظر

نشانی ایمیل شما منتشر نخواهد شد.

تمامی حقوق مادی و معنوی این وب سایت متعلق به نیک آموز می باشد.
این سایت توسط تیم آموزش برنامه نویسی نیک آموز مدیریت می شود.

ثبت نام دوره آموزشی SQL Server ویژه برنامه نویسان به صورت اقساطی
ثبت نام در دوره
close-image