مقدمه و دامنه این مجموعه

این مقاله یک نقشه جامع برای «نقشه راه Data Compression و کاهش فضای SQL Server» ارائه می‌کند و تمام ابزارها، Viewها، Waitها، Commandها و Featureهای موجود در این خانواده را در یک مسیر منسجم قرار می‌دهد. هدف فقط معرفی نام‌ها نیست؛ بلکه خواننده باید بداند هر جزء چه پرسشی را پاسخ می‌دهد و در چه مرحله‌ای از عیب‌یابی یا بهینه‌سازی به کار می‌آید.

مخاطب این راهنما مدیر پایگاه داده، توسعه‌دهنده ارشد و مسئول نگهداری سامانه‌های تراکنشی است. پیش‌نیاز آن آشنایی پایه با T-SQL، تراکنش، فایل‌های داده و لاگ و توانایی اجرای Queryهای تشخیصی در محیط آزمایشی است.

در این خانواده 8 موضوع مستقل وجود دارد. برای هر موضوع یک مقاله کامل با مثال، خروجی، خطاهای رایج و Performance آماده شده و لینک مستقیم آن در بخش‌های زیر قرار دارد.

دسترسی سریع

1. نقشه و دسته‌بندی مجموعه
2. معرفی اعضا و لینک آموزش
3. جدول مقایسه
4. مثال‌های ترکیبی
5. Performance و Best Practices
6. جمع‌بندی و مسیر مطالعه

تعریف مجموعه و جایگاه آن در SQL Server

عنوان Data Compression یک حوزه عملیاتی را پوشش می‌دهد که در آن مشاهده‌پذیری، کنترل همزمانی، مدیریت فضا یا انتخاب تنظیم مناسب به هم متصل‌اند. ارزش مجموعه زمانی آشکار می‌شود که اجزا به‌صورت زنجیره‌ای استفاده شوند: ابتدا شاخص مشاهده می‌شود، سپس علت محتمل بررسی می‌گردد، بعد تغییر محدود انجام می‌شود و در پایان نتیجه با Baseline مقایسه می‌شود.

هر عضو این خانواده نقش متفاوتی دارد. بعضی فقط وضعیت را گزارش می‌کنند، بعضی امکان تغییر رفتار می‌دهند و بعضی برای برآورد هزینه یا ظرفیت استفاده می‌شوند. ادغام این نقش‌ها بدون تشخیص Scope، احتمال اقدام اشتباه را افزایش می‌دهد.

در طراحی Runbook، اعضا را بر اساس سؤال عملی دسته‌بندی کنید: «چه اتفاقی افتاده؟»، «چرا رخ داده؟»، «چه تغییری مجاز است؟» و «چگونه موفقیت را ثابت می‌کنیم؟». این دسته‌بندی از حفظ‌کردن فهرست نام‌ها کاربردی‌تر است.

دسته‌بندی اجزا و لینک آموزش کامل

جدول مقایسه موضوع‌ها

معماری تصمیم‌گیری در این خانواده

مثال‌های ترکیبی و قابل اجرا

EXEC sys.sp_estimate_data_compression_savings @schema_name=N'dbo',@object_name=N'FactSales',@index_id=NULL,@partition_number=NULL,@data_compression=N'PAGE';

SELECT object_id,index_id,data_compression_desc FROM sys.partitions WHERE object_id=OBJECT_ID(N'dbo.FactSales');

ALTER INDEX IX_FactSales_OrderDate ON dbo.FactSales REBUILD WITH (DATA_COMPRESSION=PAGE);

ALTER TABLE dbo.FactSales REBUILD PARTITION=ALL WITH (DATA_COMPRESSION=ROW);

SELECT SUM(reserved_page_count) AS Pages FROM sys.dm_db_partition_stats WHERE object_id=OBJECT_ID(N'dbo.FactSales');

SELECT OBJECT_NAME(object_id) AS ObjectName,data_compression_desc,COUNT(*) AS Partitions FROM sys.partitions GROUP BY object_id,data_compression_desc;

سناریوهای واقعی

در Incident کندی، ابتدا Queryهای فقط‌خواندنی این مجموعه اجرا می‌شوند تا وضعیت لحظه‌ای و روند کوتاه‌مدت ثبت شود. سپس موضوعی که بیشترین ارتباط را با اثر کاربر دارد انتخاب و مقاله فرزند آن برای تحلیل عمیق دنبال می‌شود.

در Capacity Planning، خروجی‌های فضا، لاگ، Version Store یا Compression به‌صورت دوره‌ای نگهداری می‌شوند. هدف پیش‌بینی زمان رسیدن به آستانه و برنامه‌ریزی تغییر پیش از ایجاد اختلال است.

در Change Management، Feature یا Command فقط پس از ثبت Baseline، تعریف معیار موفقیت و آماده‌سازی Rollback اجرا می‌شود. این مجموعه باید بخشی از Runbook رسمی تیم باشد، نه مجموعه‌ای از فرمان‌های موردی.

هشدار درباره اقدام‌های زنجیره‌ای

ترکیب چند تغییر در یک مرحله، تشخیص اثر هر تغییر را غیرممکن می‌کند. در محیط Production هر بار یک متغیر را تغییر دهید، اثر را اندازه‌گیری کنید و سپس به مرحله بعد بروید.

اشتباهات رایج

• انتخاب ابزار پیش از تعریف سؤال عیب‌یابی.
• مقایسه Snapshotهایی که Scope یا زمان اعتبار متفاوت دارند.
• اجرای تغییرات فایل، Isolation یا Rebuild بدون پنجره نگهداری.
• استفاده از یک آستانه ثابت برای همه سرورها.
• ذخیره خروجی بدون زمان، نام پایگاه و Context رخداد.
• نادیده گرفتن هزینه خودِ Query مانیتورینگ.

Performance Considerations

در سطح مجموعه، Performance فقط کاهش زمان یک Query نیست. باید اثر روی CPU، IO، لاگ، TempDB، Lock Duration، Recovery و زمان نگهداری هم‌زمان ارزیابی شود. بهبود محلی ممکن است هزینه را به لایه دیگری منتقل کند.

برای مقایسه معتبر، یک Workload نماینده و بازه زمانی همسان انتخاب کنید. تغییرات بزرگ را روی زیرمجموعه داده یا Partition آزمایش کنید و سپس با معیارهای عددی تصمیم به توسعه دامنه بگیرید.

1. Queryهای مشاهده‌ای را فیلتر و زمان‌بندی کنید.
2. Baseline عادی و پرترافیک داشته باشید.
3. تغییرات را تک‌به‌تک اجرا کنید.
4. محدودیت نسخه و Edition را پیش از فعال‌سازی بررسی کنید.
5. پس از تغییر، بازه کافی برای مشاهده اثر در نظر بگیرید.

Best Practices

1. برای هر موضوع Owner و Runbook مشخص تعریف کنید.
2. خروجی‌ها را با زمان و Scope استاندارد ذخیره کنید.
3. از Queryهای کم‌خطر برای مرحله اول Incident استفاده کنید.
4. Featureها و Database Optionها را با Rollback Plan فعال کنید.
5. آستانه‌ها را از Baseline همان محیط استخراج کنید.
6. تغییرات نگهداری را با ظرفیت لاگ و TempDB هماهنگ کنید.
7. نتیجه را به زبان اثر کسب‌وکار گزارش کنید.
8. مقالات فرزند را بر اساس مسئله واقعی، نه ترتیب فهرست، مطالعه کنید.

مزایا، محدودیت‌ها و زمان نامناسب استفاده

این مجموعه زمانی نباید به‌عنوان چک‌لیست مکانیکی استفاده شود که سؤال عیب‌یابی، Scope یا معیار موفقیت تعریف نشده است. ابتدا مسئله را دقیق کنید و سپس فقط ابزارهای مرتبط را اجرا نمایید.

سؤالات متداول

از کدام عضو مجموعه شروع کنیم؟

از عضوی که کم‌خطرترین مشاهده را برای سؤال فعلی فراهم می‌کند.

آیا باید همه Queryها را همیشه اجرا کرد؟

خیر؛ فقط Queryهای مرتبط با Scope و اثر کاربر را انتخاب کنید.

چند Snapshot لازم است؟

حداقل Baseline عادی و نمونه رخداد؛ برای روند معتبر نمونه‌های بیشتری لازم است.

چرا نتیجه دو سرور یکسان نیست؟

اندازه، بار، نسخه، سخت‌افزار و تنظیمات متفاوت‌اند.

آیا تغییرات را می‌توان هم‌زمان اجرا کرد؟

بهتر است تک‌به‌تک باشند تا اثر هر تغییر قابل انتساب بماند.

بهترین آستانه هشدار چیست؟

آستانه‌ای که از Baseline همان محیط و اثر واقعی سرویس استخراج شود.

چگونه خروجی‌ها را نگهداری کنیم؟

در جدول تاریخچه با زمان، Scope، نسخه و شناسه رخداد.

چه زمانی Rollback لازم است؟

وقتی معیار توقف یا Regression مشاهده شود.

آیا مانیتورینگ هزینه دارد؟

بله؛ تناوب و حجم خروجی باید کنترل شود.

چگونه مسیر مطالعه را ادامه دهیم؟

از جدول مقایسه، مقاله فرزند مرتبط با مسئله فعلی را انتخاب کنید.

سؤالات مصاحبه

چگونه از این خانواده یک Runbook می‌سازید؟

پاسخ باید شامل سؤال آغازین، Query کم‌خطر، معیار Escalation، اقدام محدود، Rollback و بازبینی باشد.

چرا Baseline از Threshold مهم‌تر است؟

زیرا Threshold عمومی تفاوت اندازه و بار سیستم‌ها را نادیده می‌گیرد، اما Baseline رفتار طبیعی همان محیط را نشان می‌دهد.

چگونه Root Cause را از Correlation جدا می‌کنید؟

با شواهد مستقل، تکرارپذیری و تغییر کنترل‌شده که اثر قابل اندازه‌گیری ایجاد کند.

چه زمانی تغییر را متوقف می‌کنید؟

وقتی معیار توقف فعال شود، اثر جانبی بیشتر از منفعت باشد یا داده کافی برای ادامه وجود نداشته باشد.

گزارش فنی خوب چه اجزایی دارد؟

زمان، Scope، اثر کاربر، شواهد، تصمیم، ریسک، نتیجه و اقدام بعدی.

چک‌لیست نهایی

1. مسئله و اثر کاربر تعریف شد.
2. Scope و زمان اعتبار داده مشخص است.
3. Baseline در دسترس است.
4. ابزار کم‌خطر آغازین انتخاب شد.
5. شواهد مستقل جمع‌آوری شد.
6. تغییر محدود و قابل بازگشت است.
7. معیار موفقیت و توقف تعریف شد.
8. بازبینی پس از تغییر انجام می‌شود.

جمع‌بندی

این مجموعه زمانی ارزشمند است که اعضای آن به‌صورت یک زنجیره تصمیم استفاده شوند: مشاهده، اعتبارسنجی، اقدام و بازبینی. برای ادامه مطالعه، مقاله‌های تخصصی این خانواده عبارت‌اند از: ROW Compression، PAGE Compression، COLUMNSTORE Compression، COLUMNSTORE_ARCHIVE Compression، XML_COMPRESSION، ALTER TABLE ... REBUILD WITH (DATA_COMPRESSION = ...)، ALTER INDEX ... REBUILD WITH (DATA_COMPRESSION = ...)، sp_estimate_data_compression_savings

خدمات برنامه‌نویسی و پایگاه داده

برای قبول سفارش‌های برنامه‌نویسی و پایگاه داده با شماره 09131253620 تماس بگیرید. این مجموعه در حوزه برنامه‌نویسی در اصفهان، انجام پروژه، آموزش برنامه‌نویسی و آموزش SQL Server فعالیت دارد و مجموعه‌ای معتبر با سابقه فعالیت حرفه‌ای از سال ۱۳۷۵ شمسی تاکنون است.

خدمات شامل انجام پروژه‌های برنامه‌نویسی، طراحی و بهینه‌سازی پایگاه داده، آموزش برنامه‌نویسی و آموزش پایگاه داده SQL Server است. برای سفارش پروژه از طریق ایتا، واتساپ و تماس مستقیم هماهنگ کنید.

• دانلود پروژه‌های رایگان C#
• دانلود پروژه‌های رایگان SQL Server
• دانلود پروژه‌های رایگان Microsoft Access
• دانلود پروژه‌های رایگان UML
• پروژه‌های ASP.NET Web Forms
• گزارش‌های کارآموزی
• طرح‌های توجیهی و کارآفرینی
• پروژه‌های Multimedia Builder

تماس مستقیم با 09131253620 | تماس با ما و ثبت سفارش پروژه