Shrink دیتابیس SQL Server فضای آزاد داخل یک فایل را، در شرایط مناسب، به سیستم‌عامل برمی‌گرداند. بزرگ‌بودن فایل لاگ نسبت به فایل داده به‌تنهایی دلیل Shrink نیست. معیار ثابت «۲۰ درصد بزرگ‌تر» معتبر نیست؛ اندازهٔ لازم به حجم تراکنش‌ها، برنامهٔ بکاپ و بار واقعی سامانه بستگی دارد.
پیش از Shrink دیتابیس SQL Server
ابتدا نام پایگاه و فایل هدف، حجم مصرف‌شده و علت رشد را مشخص کنید. فایل داده و فایل لاگ یکسان نیستند. از وجود بکاپ قابل‌بازیابی مطمئن شوید و عملیات را در زمان کم‌بار با مسئول دیتابیس هماهنگ کنید. روی هاست اشتراکی ممکن است دسترسی لازم فقط در اختیار میزبان باشد.
تشخیص علت رشد لاگ
در پنجرهٔ Query و در زمینهٔ پایگاه درست، پرس‌وجوهای زیر فقط اطلاعات را می‌خوانند. مجوز مشاهده به نسخه و نقش حساب بستگی دارد. مقدار log_reuse_wait_desc کمک می‌کند بفهمید چرا موتور هنوز فضای لاگ را قابل استفادهٔ مجدد نمی‌داند.
SELECT name, recovery_model_desc, log_reuse_wait_desc
FROM sys.databases WHERE database_id = DB_ID();
SELECT name, type_desc, size / 128.0 AS size_mb
FROM sys.database_files;
SELECT total_log_size_in_bytes, used_log_space_in_bytes,
used_log_space_in_percent
FROM sys.dm_db_log_space_usage;تراکنش طولانی، انتظار برای بکاپ لاگ یا عقب‌ماندن اجزای تکثیر می‌تواند مانع آزادشدن بخش‌های لاگ باشد. به‌جای قطع تصادفی نشست‌ها، علت گزارش‌شده را بررسی کنید. فایل LDF را از روی دیسک حذف نکنید.
Truncate با Shrink چه تفاوتی دارد؟
Truncation بخش غیرفعال لاگ را برای استفادهٔ دوباره آماده می‌کند، اما الزاماً اندازهٔ فایل روی دیسک را کم نمی‌کند. Shrink برای کاهش اندازهٔ فیزیکی است و نمی‌تواند هر بخش فعال را حذف کند. اگر بار عادی دوباره به همان فضا نیاز دارد، کوچک‌کردن مکرر فقط چرخهٔ رشد و هزینهٔ اضافی ایجاد می‌کند.
Recovery Model را برای رفع فوری عوض نکنید
تغییر FULL به SIMPLE روی زنجیرهٔ بکاپ لاگ و امکان بازیابی نقطه‌ای اثر دارد. این تغییر، پیش‌نیاز عمومی Shrink نیست. در مدل FULL ابتدا برنامهٔ بکاپ لاگ و علت توقف بازاستفاده را بررسی کنید. راهنمای مدل بازیابی Microsoft الزامات تغییر و شروع زنجیرهٔ جدید را توضیح می‌دهد.
اجرای کنترل‌شده در SSMS
فقط وقتی نیاز غیرتکراری و فضای آزاد واقعی دارید، روی پایگاه راست‌کلیک کنید و Tasks سپس Shrink و Files را باز کنید. برای لاگ، File type را Log و File name را دقیق انتخاب کنید. اندازهٔ هدف را برحسب مگابایت و با فضای کافی برای بار آینده تعیین کنید؛ مقدار ۱ مگابایت نسخهٔ همگانی نیست.
همین عملیات در T-SQL با DBCC SHRINKFILE و نام منطقی فایل انجام می‌شود؛ عدد target_size اندازهٔ هدف برحسب MB است، نه درصد. پیش از اجرای دستور، محدودیت‌های رسمی SHRINKFILE را برای نسخهٔ خود بررسی کنید.
کنترل بعد از عملیات
اندازه، فضای مصرف‌شده، رشد مجدد و سلامت بکاپ را پایش کنید. کوچک‌کردن فایل داده می‌تواند پراکندگی ایندکس ایجاد کند؛ نتیجهٔ عملکرد را بسنجید. اگر فایل دوباره رشد می‌کند، ظرفیت و برنامهٔ نگهداری را اصلاح کنید، نه اینکه Shrink را زمان‌بندی روزانه کنید. مستند مدیریت لاگ Microsoft نیز آن را نگهداری روتین نمی‌داند.
مطالعهٔ مرتبط
بازبینی فنی: ۲۷ مهر ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شده‌اند.
