و سپس «افزودن به صفحه اصلی» ضربه بزنید
و سپس «افزودن به صفحه اصلی» ضربه بزنید
در دنیای مدیریت پایگاه داده، آزادسازی فضای غیرقابل استفاده یکی از دغدغه‌های همیشگی مدیران سیستم و DBAهاست. دستور Shrink (شرینک) در SQL Server دقیقاً برای همین هدف طراحی شده است؛ اما استفاده نادرست از آن می‌تواند بیش از آنکه سودمند باشد، به ساختار داده‌ها آسیب بزند.
در این مقاله که بر اساس جدیدترین نسخه‌های SQL Server 2022 و SQL Server 2025 Preview نوشته شده، به‌صورت عمیق بررسی می‌کنیم که شرینک چیست، چطور کار می‌کند، چه زمانی باید از آن استفاده کرد، و چه زمانی نباید به آن نزدیک شد.
Shrink چیست و چرا وجود دارد؟
به‌صورت ساده، دستور شرینک (چه در سطح Database و چه File) وظیفه دارد فضای استفاده‌نشده در فایل‌های دیتابیس را آزاد کرده و به سیستم عامل بازگرداند.
این کار با جابجایی صفحات داده از انتهای فایل به بخش‌های خالی‌تر فایل انجام می‌شود. دو دستور اصلی وجود دارد:
- DBCC SHRINKDATABASE (DatabaseName)
- DBCC SHRINKFILE (FileName, TargetSize)
هدف هر دو یکسان است: کاهش حجم فیزیکی فایل‌های MDF و LDF، ولی روش اجرا و کنترل آن متفاوت است.
نحوه عملکرد Shrink در SQL Server
وقتی دستور شرینک اجرا می‌شود، SQL Server داده‌ها را از صفحات فیزیکی انتهای فایل به بخش‌های ابتدایی‌تر منتقل می‌کند. در این فرآیند:
- تمام صفحات داده (Data Pages) بررسی می‌شوند.
- صفحات استفاده‌نشده یا دارای فضای خالی شناسایی می‌گردند.
- داده‌ها جابجا شده و فضای انتهای فایل آزاد می‌شود.
- در نهایت اندازه فیزیکی فایل کاهش یافته و به سیستم عامل بازگردانده می‌شود.
این فرآیند به‌صورت Sequential I/O سنگین انجام می‌شود و ممکن است در بانک‌های اطلاعاتی بزرگ، بار شدیدی بر روی دیسک و CPU ایجاد کند.
انواع Shrink در SQL Server
۱. Shrink Database
کاهش کلی حجم پایگاه داده شامل همه فایل‌ها (MDF و LDF).
مثلاً:
DBCC SHRINKDATABASE (MyDatabase);
این دستور روی کل ساختار دیتابیس تأثیر می‌گذارد و اغلب برای محیط‌های کوچک یا دیتابیس‌های آرشیوی توصیه می‌شود.
۲. Shrink File
کنترل دقیق‌تر روی فایل خاص:
DBCC SHRINKFILE (MyDatabase_Data, 10240); -- Target size in MB
در این روش می‌توان حجم فایل داده یا لاگ را به مقدار مشخص کاهش داد.
۳. Shrink Log File
برای فایل‌های لاگ (LDF) زمانی کاربرد دارد که فضای اشغال‌شده زیاد شده ولی به‌صورت واقعی نیازی به آن نیست.
اما توجه کنید که ابتدا باید Log backup گرفته شود تا فضای قابل آزادسازی ایجاد شود:
BACKUP LOG MyDatabase TO DISK = 'C:\LogBackup.trn';
DBCC SHRINKFILE (MyDatabase_Log, 2048);
عوارض و پیامدهای اجرای Shrink
اجرای Shrink به ظاهر مفید است، ولی در عمل می‌تواند منجر به مشکلات زیر شود:
Fragmentation شدید
جابجایی صفحات داده باعث می‌شود ایندکس‌ها به‌شدت پراکنده شوند. نتیجه؟
- افت محسوس سرعت Queryها
- افزایش Logical Read
- افزایش هزینه CPU در عملیات JOIN و Scan
افزایش Log Usage
شرینک عملیاتی تراکنشی است؛ یعنی تمام مراحل در فایل لاگ ثبت می‌شوند.
در نتیجه ممکن است حجم LDF به‌صورت موقت بیشتر هم بشود!
بار سنگین روی I/O و CPU
فرآیند انتقال صفحات داده، باعث فشار لحظه‌ای بر منابع سرور می‌شود.
در محیط‌های Production، اجرای Shrink در ساعات پیک می‌تواند موجب Timeout و حتی Block شود.
تأثیر منفی بر روی Always On و Replication
در ساختارهای HA مثل Always On Availability Groups یا Log Shipping ،Shrink ممکن است سبب Lag در Synchronization شود.
مزایا و معایب Shrink
| مزایا | معایب |
|---|---|
| آزادسازی فضای دیسک | افزایش Fragmentation |
| کاهش حجم بکاپ‌ها (در کوتاه‌مدت) | افزایش CPU و I/O |
| مناسب برای دیتابیس‌های آرشیوی | افت Performance |
| قابل اجرای خودکار یا زمان‌بندی‌شده | تداخل با HA و Replication |
| کاربردی در محیط‌های Dev و Test | نیاز به بازسازی ایندکس‌ها پس از Shrink |
چرا Shrink یکی از بدترین گزینه‌های نگهداری (Maintenance) در SQL Server است؟
در نگاه اول، شرینک شبیه ابزاری مفید برای مرتب‌سازی و کاهش حجم دیتابیس به نظر می‌رسد، اما در واقع یکی از مخرب‌ترین و پرریسک‌ترین عملیات‌های نگهداری محسوب می‌شود. دلیلش این است که Shrink برخلاف اصول فیزیکی و منطقی عملکرد SQL Server عمل می‌کند.
۱. تخریب نظم فیزیکی داده‌ها
شرینک با جابجایی صفحات از انتهای فایل به ابتدای فایل، ساختار Page و ایندکس را به‌هم می‌ریزد و باعث Fragmentation شدید می‌شود. ایندکس‌های خوش‌ساخت پس از شرینک به حالت تصادفی در دیسک پراکنده می‌شوند و عملکرد Queryها به‌شدت افت می‌کند.
۲. رشد فوری دوباره‌ی فایل‌ها
در محیط‌های زنده، دیتابیس بعد از Shrink مجدداً رشد می‌کند چون SQL Server فضای آزاد نیاز دارد.
این چرخه‌ی Shrink → Grow → Shrink یکی از پرهزینه‌ترین الگوهای نگهداری است و باعث Fragmentation در سطح فایل سیستم می‌شود.
۳. افزایش غیرمنطقی حجم Log
شرینک عملیاتی تراکنشی است، یعنی هر حرکت داده ثبت می‌شود.
نتیجه؟ در بعضی مواقع Shrink باعث پر شدن Log File می‌شود و درست برعکسِ هدف اصلی، فضای بیشتری مصرف می‌کند!
۴. تداخل با عملیات هم‌زمان
Shrink قفل‌های انحصاری ایجاد می‌کند و می‌تواند باعث Blocking شود. در دیتابیس‌های پرتراکنش، این عملیات می‌تواند باعث توقف چند دقیقه تا چند ساعت فعالیت شود.
۵. ناسازگاری با معماری‌های HA
در ساختارهایی مانند Always On، Mirroring و Replication، Shrink می‌تواند Synchronization را مختل کرده و حتی باعث Failover ناگهانی یا Desync شود.
۶. بازدهی منفی در نگهداری
Shrinking برخلاف عملیات‌های مفید نگهداری (مثل Rebuild Index، Update Statistics و Integrity Check) باعث بهبود نمی‌شود، بلکه پایداری سیستم را کاهش می‌دهد.
مایکروسافت به‌صراحت اعلام کرده است:
“Do not schedule Shrink as part of regular maintenance.” — Microsoft Docs (SQL Server 2022)
به طور کلی، شرینک ابزاری اضطراری است، نه نگهداری. اگر بخواهیم آن را طبقه‌بندی کنیم:
- Rebuild Index = بهبود عملکرد
- Update Statistics = بهینه‌سازی Query Plan
- Backup / CheckDB = تضمین امنیت و سلامت
- Shrink = ابزار اضطراری برای شرایط خاص
به همین دلیل Shrink به‌درستی در جامعه‌ی DBAها به عنوان «بدترین گزینه نگهداری SQL Server» شناخته می‌شود.
روش‌های جایگزین Shrink
- Rebuild Indexes
بازسازی ایندکس‌ها باعث فشرده‌سازی داده‌ها و بهبود عملکرد می‌شود بدون ایجاد Fragmentation جدید:ALTER INDEX ALL ON TableName REBUILD; - Truncate Log با Backup Chain
بجای Shrink Log، از Backup Log Chain استفاده کنید تا فضای استفاده‌نشده به‌صورت طبیعی آزاد شود. - Partition Switching یا Archive Table
حذف داده‌های قدیمی با جداول آرشیوی یا پارتیشن‌بندی. - Filegroup Management
کنترل رشد فایل‌ها از طریق Filegroupهای جداگانه برای توازن بهتر بین دیسک‌ها. - Auto-Growth Control
تنظیم رشد منطقی فایل‌ها تا چرخه‌ی رشد و شرینک مکرر اتفاق نیفتد.
توصیه‌های DBA برای سال ۲۰۲۵
- شرینک را هرگز زمان‌بندی نکنید.
- پس از Shrink، حتماً ایندکس‌ها را Rebuild کنید.
- از Extended Events برای مانیتور کردن File Growth / Shrink استفاده کنید.
- در Always On، Shrink را فقط روی Replica ثانویه اجرا کنید.
مانیتورینگ فضای دیتابیس
برای بررسی فضای آزاد فعلی هر فایل، از Query زیر استفاده کنید:
SELECT
DB_NAME(database_id) AS [DatabaseName],
Name AS [LogicalName],
type_desc AS [FileType],
size/128.0 AS [CurrentSizeMB],
size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS [FreeSpaceMB]
FROM sys.database_files;
نتیجه‌گیری
شرینک ابزاری است که اگر با آگاهی و در شرایط درست استفاده شود، می‌تواند مفید باشد. اما در اغلب سناریوهای واقعی، آسیب‌هایش بیشتر از مزایایش است. DBAهای حرفه‌ای با کنترل رشد فایل‌ها و استفاده از مانیتورینگ هوشمند، معمولاً نیازی به شرینک ندارند.
در حقیقت، Shrink آخرین چاره است، نه بخشی از نگهداری منظم.
سوالات متداول (FAQ)
۱. آیا Shrink باعث حذف داده می‌شود؟
خیر، فقط فضای فیزیکی آزاد را از انتهای فایل حذف می‌کند.
۲. در چه زمان‌هایی Shrink منطقی است؟
بعد از حذف دائمی حجم زیادی از داده‌ها یا در محیط‌های آزمایشی.
۳. چرا پس از Shrink سرعت کم می‌شود؟
به دلیل Fragmentation بالا و از بین رفتن نظم صفحات داده.
۴. آیا Shrink در Always On مجاز است؟
خیر، فقط روی Replica ثانویه با دقت بالا انجام شود.
۵. بعد از Shrink چه کاری باید انجام داد؟
ایندکس‌ها را Rebuild و آمارها را Update کنید.
تماس و مشاوره خدمات مانیتورینگ و DBA با لاندا
اگر در سرورهای SQL خود با مشکلاتی مانند رشد بیش از حد فایل‌ها، افت سرعت Query یا خطاهای فضای ذخیره‌سازی مواجه هستید، تیم لاندا با خدمات تخصصی مانیتورینگ و DBA به شما کمک می‌کند تا SQL Server خود را بهینه، ایمن و پایدار نگه دارید.
همین امروز با کارشناسان لاندا تماس ✆ بگیرید و مشاوره رایگان خود را دریافت کنید.
نظری داده نشده