نگه‌داری Columnstore با ALTER INDEX REORGANIZE با ۱۰ مثال عملی در SQL Server

نگه‌داری Columnstore با ALTER INDEX REORGANIZE

توسط admin | گروه SQL Server | 1405/05/05

نظرات 0

نگه‌داری Columnstore با ALTER INDEX REORGANIZE

ALTER INDEX ... REORGANIZE برای Columnstore عملیاتی آنلاین و سبک‌تر از Rebuild است که Delta Rowgroupهای بسته را فشرده می‌کند و در نسخه‌های جدید می‌تواند Rowgroupهای فشرده کوچک یا دارای حذف زیاد را ادغام کند. در این راهنما موضوع از سطح مقدماتی تا طراحی عملی، خطاهای رایج، ملاحظات کارایی و سناریوهای نگه‌داری بررسی می‌شود.

مخاطب مقاله برنامه‌نویسان، مدیران پایگاه داده و تحلیل‌گرانی هستند که می‌خواهند Maintenance: ALTER INDEX ... REORGANIZE را بدون تصمیم‌های حدسی در Microsoft SQL Server به‌کار بگیرند. بازگشت به راهنمای جامع کارایی Columnstore در SQL Server

تعریف و جایگاه موضوع

ALTER INDEX ... REORGANIZE برای Columnstore عملیاتی آنلاین و سبک‌تر از Rebuild است که Delta Rowgroupهای بسته را فشرده می‌کند و در نسخه‌های جدید می‌تواند Rowgroupهای فشرده کوچک یا دارای حذف زیاد را ادغام کند.

این قابلیت را باید در کنار مفاهیم ALTER INDEX، REORGANIZE، Columnstore و Delta Rowgroup تحلیل کرد. تصمیم درست تنها با مشاهده یک Query سریع حاصل نمی‌شود؛ بلکه نرخ رشد داده، الگوی DML، نحوه بارگذاری، محدودیت منابع و زمان نگه‌داری نیز باید وارد مدل تصمیم شوند.

نکته نسخه: رفتار دقیق ادغام Rowgroup از SQL Server 2016 به بعد توسعه یافته و در نسخه‌های جدید نگه‌داری خودکار نیز فعال‌تر است.

چرا این موضوع مهم است؟

در جداول تحلیلی بزرگ، تفاوت میان طراحی درست و اجرای صرف یک دستور می‌تواند به اختلاف قابل‌توجه در IO، CPU و زمان پاسخ منجر شود. REORGANIZE ایندکس Columnstore وقتی ارزش واقعی ایجاد می‌کند که با هدف کسب‌وکار، الگوی Query و ظرفیت زیرساخت هماهنگ باشد.

  • فشرده‌سازی CLOSED
  • کاهش حذف منطقی
  • ادغام Rowgroup کوچک
  • نگه‌داری آنلاین
  • پس از ETL

به همین دلیل لازم است معیار موفقیت پیش از پیاده‌سازی تعریف شود. برای نمونه می‌توان زمان گزارش ماهانه، تعداد Rowgroupهای کم‌حجم، درصد ردیف‌های حذف‌شده، حجم Log یا تعداد Segmentهای خوانده‌شده را به‌عنوان شاخص پایه ثبت کرد.

نقشه مفهومی REORGANIZE ایندکس Columnstoreنمایش اجزای اصلی، رابطه Rowgroup و مسیر داده در موضوع Maintenance: ALTER INDEX ... REORGANIZEنقشه مفهومی REORGANIZE ایندکس ColumnstoreMaintenance: ALTER INDEX ... REORGANIZE1ALTER INDEXورودی2REORGANIZEساختار مرکزی3Columnstoreفراداده4Delta Rowgroupمرحله میانی5Online Maintenanceپردازش6Mergeخروجی

این نمودار اجزای کلیدی «REORGANIZE ایندکس Columnstore» و ارتباط میان ALTER INDEX، REORGANIZE و Columnstore را نشان می‌دهد.

نحو، اجزا و پارامترهای اصلی

نحو پایه زیر نقطه شروع است. نام شیء، Schema، پارتیشن و گزینه‌ها باید با محیط واقعی جایگزین شوند. در رشته‌های فارسی SQL از پیشوند N استفاده شده تا داده یونیکد درست ذخیره شود.

ALTER INDEX CCI_FactSales ON dbo.FactSales REORGANIZE;

اجزای کلیدی

مفهومنقش در موضوعنکته عملی
ALTER INDEXبخشی از معماری یا رفتار REORGANIZE ایندکس Columnstoreپیش و پس DMV بگیرید
REORGANIZEبخشی از معماری یا رفتار REORGANIZE ایندکس Columnstoreپارتیشن را هدف بگیرید
Columnstoreبخشی از معماری یا رفتار REORGANIZE ایندکس Columnstoreپنجره منابع تعریف کنید
Delta Rowgroupبخشی از معماری یا رفتار REORGANIZE ایندکس Columnstoreشرط آستانه داشته باشید
Online Maintenanceبخشی از معماری یا رفتار REORGANIZE ایندکس Columnstoreتوقف‌پذیری Job را طراحی کنید
Mergeبخشی از معماری یا رفتار REORGANIZE ایندکس Columnstoreپیش و پس DMV بگیرید

نوع خروجی بسته به موضوع ممکن است یک ساختار ایندکس، Plan اجرایی، مجموعه Rowgroup، شمارنده DMV یا مقدار عددی باشد. همیشه خروجی را با Metadata و Plan واقعی تأیید کنید؛ پیام موفقیت دستور به‌تنهایی نشان‌دهنده بهبود نیست.

فرایند تصمیم‌گیری و پیاده‌سازی

  1. Workload اصلی را مشخص کنید و Queryهای پرتکرار مرتبط با REORGANIZE ایندکس Columnstore را از Query Store یا مانیتورینگ استخراج کنید.
  2. وضعیت فعلی REORGANIZE و Columnstore را ثبت کنید تا خط پایه قابل مقایسه باشد.
  3. Syntax را در محیط آزمایشی اجرا کنید و اثر آن را روی مدت اجرا و Log Usage بسنجید.
  4. سناریوهای بارگذاری، حذف، به‌روزرسانی، گزارش‌گیری و بازیابی خطا را جداگانه آزمایش کنید.
  5. پس از تأیید، اجرای Production را با پنجره تغییر، Rollback Plan و گزارش کنترلی انجام دهید.

این روش مرحله‌ای مانع آن می‌شود که یک بهبود محلی، هزینه پنهان در ETL یا عملیات تراکنشی ایجاد کند. همچنین مستندسازی خروجی‌های قبل و بعد، تصمیم‌های نگه‌داری آینده را قابل دفاع می‌سازد.

جریان اجرای REORGANIZE ایندکس Columnstoreنمایش جریان ورودی تا خروجی و نقاط کنترلی مرتبط با Maintenance: ALTER INDEX ... REORGANIZEجریان اجرای REORGANIZE ایندکس ColumnstoreMaintenance: ALTER INDEX ... REORGANIZE1ALTER INDEXداده ورودی2REORGANIZEتشخیص3Columnstoreپردازش4Delta Rowgroupکنترل5Online Maintenanceنتیجه6Mergeپایش

در این جریان، داده از مرحله ورودی عبور می‌کند، در نقطه‌های کنترلی مرتبط با REORGANIZE و Delta Rowgroup ارزیابی می‌شود و سپس نتیجه قابل پایش تولید می‌گردد.

۱۰ مثال عملی از ساده تا حرفه‌ای

مثال 1: اجرای پایه عملیات

در این مثال، «REORGANIZE ایندکس Columnstore» در سناریوی اجرای پایه عملیات بررسی می‌شود. Query به‌گونه‌ای نوشته شده که در یک محیط آزمایشی SQL Server قابل اجرا باشد و نتیجه آن با DMV، خروجی تجمیعی یا Metadata کنترل شود.

USE tempdb;
    DROP TABLE IF EXISTS dbo.FactSalesDemo;
    CREATE TABLE dbo.FactSalesDemo
    (
        SaleID bigint NOT NULL,
        OrderDate date NOT NULL,
        CustomerID int NOT NULL,
        ProductID int NOT NULL,
        Quantity smallint NULL,
        Amount decimal(18,2) NULL
    );

    INSERT INTO dbo.FactSalesDemo
    (
        SaleID, OrderDate, CustomerID, ProductID, Quantity, Amount
    )
    SELECT TOP (25000)
        ROW_NUMBER() OVER (ORDER BY (SELECT NULL)),
        DATEADD(day, -ABS(CHECKSUM(NEWID())) % 730, CONVERT(date, '20260727')),
        1 + ABS(CHECKSUM(NEWID())) % 5000,
        1 + ABS(CHECKSUM(NEWID())) % 800,
        1 + ABS(CHECKSUM(NEWID())) % 12,
        CONVERT(decimal(18,2), 10 + ABS(CHECKSUM(NEWID())) % 50000 / 10.0)
    FROM sys.all_objects AS a
    CROSS JOIN sys.all_objects AS b;

    CREATE CLUSTERED COLUMNSTORE INDEX CCI_FactSalesDemo
    ON dbo.FactSalesDemo;

    ALTER INDEX CCI_FactSalesDemo ON dbo.FactSalesDemo REORGANIZE;
شاخصخروجی نمونهتفسیر
قبل از عملیاتOPEN / CLOSEDوجود Delta Rowgroup یا حذف منطقی
بعد از عملیاتCOMPRESSEDنتیجه مورد انتظار پس از اجرای موفق
نکتهوابسته به Workloadخروجی واقعی را با DMV کنترل کنید

نکته فنی: هنگام استفاده از Maintenance: ALTER INDEX ... REORGANIZE فقط به موفق‌بودن دستور اکتفا نکنید؛ مدت اجرا را قبل و بعد اندازه بگیرید و اثر آن را روی Workload واقعی ثبت کنید.

مثال 2: اجرای سطح پارتیشن

در این مثال، «REORGANIZE ایندکس Columnstore» در سناریوی اجرای سطح پارتیشن بررسی می‌شود. Query به‌گونه‌ای نوشته شده که در یک محیط آزمایشی SQL Server قابل اجرا باشد و نتیجه آن با DMV، خروجی تجمیعی یا Metadata کنترل شود.

USE tempdb;
    DROP TABLE IF EXISTS dbo.FactSalesDemo;
    CREATE TABLE dbo.FactSalesDemo
    (
        SaleID bigint NOT NULL,
        OrderDate date NOT NULL,
        CustomerID int NOT NULL,
        ProductID int NOT NULL,
        Quantity smallint NULL,
        Amount decimal(18,2) NULL
    );

    INSERT INTO dbo.FactSalesDemo
    (
        SaleID, OrderDate, CustomerID, ProductID, Quantity, Amount
    )
    SELECT TOP (25000)
        ROW_NUMBER() OVER (ORDER BY (SELECT NULL)),
        DATEADD(day, -ABS(CHECKSUM(NEWID())) % 730, CONVERT(date, '20260727')),
        1 + ABS(CHECKSUM(NEWID())) % 5000,
        1 + ABS(CHECKSUM(NEWID())) % 800,
        1 + ABS(CHECKSUM(NEWID())) % 12,
        CONVERT(decimal(18,2), 10 + ABS(CHECKSUM(NEWID())) % 50000 / 10.0)
    FROM sys.all_objects AS a
    CROSS JOIN sys.all_objects AS b;

    CREATE CLUSTERED COLUMNSTORE INDEX CCI_FactSalesDemo
    ON dbo.FactSalesDemo;

    ALTER INDEX CCI_FactSalesDemo ON dbo.FactSalesDemo REORGANIZE PARTITION = ALL;
شاخصخروجی نمونهتفسیر
قبل از عملیاتOPEN / CLOSEDوجود Delta Rowgroup یا حذف منطقی
بعد از عملیاتCOMPRESSEDنتیجه مورد انتظار پس از اجرای موفق
نکتهوابسته به Workloadخروجی واقعی را با DMV کنترل کنید

نکته فنی: هنگام استفاده از Maintenance: ALTER INDEX ... REORGANIZE فقط به موفق‌بودن دستور اکتفا نکنید؛ Log Usage را قبل و بعد اندازه بگیرید و اثر آن را روی Workload واقعی ثبت کنید.

مثال 3: سناریوی پس از تغییر داده

در این مثال، «REORGANIZE ایندکس Columnstore» در سناریوی سناریوی پس از تغییر داده بررسی می‌شود. Query به‌گونه‌ای نوشته شده که در یک محیط آزمایشی SQL Server قابل اجرا باشد و نتیجه آن با DMV، خروجی تجمیعی یا Metadata کنترل شود.

USE tempdb;
    DROP TABLE IF EXISTS dbo.FactSalesDemo;
    CREATE TABLE dbo.FactSalesDemo
    (
        SaleID bigint NOT NULL,
        OrderDate date NOT NULL,
        CustomerID int NOT NULL,
        ProductID int NOT NULL,
        Quantity smallint NULL,
        Amount decimal(18,2) NULL
    );

    INSERT INTO dbo.FactSalesDemo
    (
        SaleID, OrderDate, CustomerID, ProductID, Quantity, Amount
    )
    SELECT TOP (25000)
        ROW_NUMBER() OVER (ORDER BY (SELECT NULL)),
        DATEADD(day, -ABS(CHECKSUM(NEWID())) % 730, CONVERT(date, '20260727')),
        1 + ABS(CHECKSUM(NEWID())) % 5000,
        1 + ABS(CHECKSUM(NEWID())) % 800,
        1 + ABS(CHECKSUM(NEWID())) % 12,
        CONVERT(decimal(18,2), 10 + ABS(CHECKSUM(NEWID())) % 50000 / 10.0)
    FROM sys.all_objects AS a
    CROSS JOIN sys.all_objects AS b;

    CREATE CLUSTERED COLUMNSTORE INDEX CCI_FactSalesDemo
    ON dbo.FactSalesDemo;

    DELETE TOP (2500) FROM dbo.FactSalesDemo;
    ALTER INDEX CCI_FactSalesDemo ON dbo.FactSalesDemo REORGANIZE;
شاخصخروجی نمونهتفسیر
قبل از عملیاتOPEN / CLOSEDوجود Delta Rowgroup یا حذف منطقی
بعد از عملیاتCOMPRESSEDنتیجه مورد انتظار پس از اجرای موفق
نکتهوابسته به Workloadخروجی واقعی را با DMV کنترل کنید

نکته فنی: هنگام استفاده از Maintenance: ALTER INDEX ... REORGANIZE فقط به موفق‌بودن دستور اکتفا نکنید؛ تعداد Rowgroup را قبل و بعد اندازه بگیرید و اثر آن را روی Workload واقعی ثبت کنید.

مثال 4: کنترل وضعیت قبل از عملیات

در این مثال، «REORGANIZE ایندکس Columnstore» در سناریوی کنترل وضعیت قبل از عملیات بررسی می‌شود. Query به‌گونه‌ای نوشته شده که در یک محیط آزمایشی SQL Server قابل اجرا باشد و نتیجه آن با DMV، خروجی تجمیعی یا Metadata کنترل شود.

USE tempdb;
    DROP TABLE IF EXISTS dbo.FactSalesDemo;
    CREATE TABLE dbo.FactSalesDemo
    (
        SaleID bigint NOT NULL,
        OrderDate date NOT NULL,
        CustomerID int NOT NULL,
        ProductID int NOT NULL,
        Quantity smallint NULL,
        Amount decimal(18,2) NULL
    );

    INSERT INTO dbo.FactSalesDemo
    (
        SaleID, OrderDate, CustomerID, ProductID, Quantity, Amount
    )
    SELECT TOP (25000)
        ROW_NUMBER() OVER (ORDER BY (SELECT NULL)),
        DATEADD(day, -ABS(CHECKSUM(NEWID())) % 730, CONVERT(date, '20260727')),
        1 + ABS(CHECKSUM(NEWID())) % 5000,
        1 + ABS(CHECKSUM(NEWID())) % 800,
        1 + ABS(CHECKSUM(NEWID())) % 12,
        CONVERT(decimal(18,2), 10 + ABS(CHECKSUM(NEWID())) % 50000 / 10.0)
    FROM sys.all_objects AS a
    CROSS JOIN sys.all_objects AS b;

    CREATE CLUSTERED COLUMNSTORE INDEX CCI_FactSalesDemo
    ON dbo.FactSalesDemo;

    SELECT state_desc,total_rows,deleted_rows FROM sys.dm_db_column_store_row_group_physical_stats WHERE object_id=OBJECT_ID(N'dbo.FactSalesDemo');
    ALTER INDEX CCI_FactSalesDemo ON dbo.FactSalesDemo REORGANIZE;
شاخصخروجی نمونهتفسیر
قبل از عملیاتOPEN / CLOSEDوجود Delta Rowgroup یا حذف منطقی
بعد از عملیاتCOMPRESSEDنتیجه مورد انتظار پس از اجرای موفق
نکتهوابسته به Workloadخروجی واقعی را با DMV کنترل کنید

نکته فنی: هنگام استفاده از Maintenance: ALTER INDEX ... REORGANIZE فقط به موفق‌بودن دستور اکتفا نکنید؛ پارتیشن هدف را قبل و بعد اندازه بگیرید و اثر آن را روی Workload واقعی ثبت کنید.

مثال 5: اندازه‌گیری زمان اجرا

در این مثال، «REORGANIZE ایندکس Columnstore» در سناریوی اندازه‌گیری زمان اجرا بررسی می‌شود. Query به‌گونه‌ای نوشته شده که در یک محیط آزمایشی SQL Server قابل اجرا باشد و نتیجه آن با DMV، خروجی تجمیعی یا Metadata کنترل شود.

USE tempdb;
    DROP TABLE IF EXISTS dbo.FactSalesDemo;
    CREATE TABLE dbo.FactSalesDemo
    (
        SaleID bigint NOT NULL,
        OrderDate date NOT NULL,
        CustomerID int NOT NULL,
        ProductID int NOT NULL,
        Quantity smallint NULL,
        Amount decimal(18,2) NULL
    );

    INSERT INTO dbo.FactSalesDemo
    (
        SaleID, OrderDate, CustomerID, ProductID, Quantity, Amount
    )
    SELECT TOP (25000)
        ROW_NUMBER() OVER (ORDER BY (SELECT NULL)),
        DATEADD(day, -ABS(CHECKSUM(NEWID())) % 730, CONVERT(date, '20260727')),
        1 + ABS(CHECKSUM(NEWID())) % 5000,
        1 + ABS(CHECKSUM(NEWID())) % 800,
        1 + ABS(CHECKSUM(NEWID())) % 12,
        CONVERT(decimal(18,2), 10 + ABS(CHECKSUM(NEWID())) % 50000 / 10.0)
    FROM sys.all_objects AS a
    CROSS JOIN sys.all_objects AS b;

    CREATE CLUSTERED COLUMNSTORE INDEX CCI_FactSalesDemo
    ON dbo.FactSalesDemo;

    SET STATISTICS TIME ON;
    ALTER INDEX CCI_FactSalesDemo ON dbo.FactSalesDemo REORGANIZE;
    SET STATISTICS TIME OFF;
شاخصخروجی نمونهتفسیر
قبل از عملیاتOPEN / CLOSEDوجود Delta Rowgroup یا حذف منطقی
بعد از عملیاتCOMPRESSEDنتیجه مورد انتظار پس از اجرای موفق
نکتهوابسته به Workloadخروجی واقعی را با DMV کنترل کنید

نکته فنی: هنگام استفاده از Maintenance: ALTER INDEX ... REORGANIZE فقط به موفق‌بودن دستور اکتفا نکنید؛ رقابت منابع را قبل و بعد اندازه بگیرید و اثر آن را روی Workload واقعی ثبت کنید.

مثال 6: اجرای شرطی براساس DMV

در این مثال، «REORGANIZE ایندکس Columnstore» در سناریوی اجرای شرطی براساس DMV بررسی می‌شود. Query به‌گونه‌ای نوشته شده که در یک محیط آزمایشی SQL Server قابل اجرا باشد و نتیجه آن با DMV، خروجی تجمیعی یا Metadata کنترل شود.

USE tempdb;
    DROP TABLE IF EXISTS dbo.FactSalesDemo;
    CREATE TABLE dbo.FactSalesDemo
    (
        SaleID bigint NOT NULL,
        OrderDate date NOT NULL,
        CustomerID int NOT NULL,
        ProductID int NOT NULL,
        Quantity smallint NULL,
        Amount decimal(18,2) NULL
    );

    INSERT INTO dbo.FactSalesDemo
    (
        SaleID, OrderDate, CustomerID, ProductID, Quantity, Amount
    )
    SELECT TOP (25000)
        ROW_NUMBER() OVER (ORDER BY (SELECT NULL)),
        DATEADD(day, -ABS(CHECKSUM(NEWID())) % 730, CONVERT(date, '20260727')),
        1 + ABS(CHECKSUM(NEWID())) % 5000,
        1 + ABS(CHECKSUM(NEWID())) % 800,
        1 + ABS(CHECKSUM(NEWID())) % 12,
        CONVERT(decimal(18,2), 10 + ABS(CHECKSUM(NEWID())) % 50000 / 10.0)
    FROM sys.all_objects AS a
    CROSS JOIN sys.all_objects AS b;

    CREATE CLUSTERED COLUMNSTORE INDEX CCI_FactSalesDemo
    ON dbo.FactSalesDemo;

    IF EXISTS (SELECT 1 FROM sys.dm_db_column_store_row_group_physical_stats WHERE object_id=OBJECT_ID(N'dbo.FactSalesDemo') AND (state_desc=N'CLOSED' OR deleted_rows>1000)) ALTER INDEX CCI_FactSalesDemo ON dbo.FactSalesDemo REORGANIZE;
شاخصخروجی نمونهتفسیر
قبل از عملیاتOPEN / CLOSEDوجود Delta Rowgroup یا حذف منطقی
بعد از عملیاتCOMPRESSEDنتیجه مورد انتظار پس از اجرای موفق
نکتهوابسته به Workloadخروجی واقعی را با DMV کنترل کنید

نکته فنی: هنگام استفاده از Maintenance: ALTER INDEX ... REORGANIZE فقط به موفق‌بودن دستور اکتفا نکنید؛ مدت اجرا را قبل و بعد اندازه بگیرید و اثر آن را روی Workload واقعی ثبت کنید.

مثال 7: مدیریت خطا در Job

در این مثال، «REORGANIZE ایندکس Columnstore» در سناریوی مدیریت خطا در Job بررسی می‌شود. Query به‌گونه‌ای نوشته شده که در یک محیط آزمایشی SQL Server قابل اجرا باشد و نتیجه آن با DMV، خروجی تجمیعی یا Metadata کنترل شود.

USE tempdb;
    DROP TABLE IF EXISTS dbo.FactSalesDemo;
    CREATE TABLE dbo.FactSalesDemo
    (
        SaleID bigint NOT NULL,
        OrderDate date NOT NULL,
        CustomerID int NOT NULL,
        ProductID int NOT NULL,
        Quantity smallint NULL,
        Amount decimal(18,2) NULL
    );

    INSERT INTO dbo.FactSalesDemo
    (
        SaleID, OrderDate, CustomerID, ProductID, Quantity, Amount
    )
    SELECT TOP (25000)
        ROW_NUMBER() OVER (ORDER BY (SELECT NULL)),
        DATEADD(day, -ABS(CHECKSUM(NEWID())) % 730, CONVERT(date, '20260727')),
        1 + ABS(CHECKSUM(NEWID())) % 5000,
        1 + ABS(CHECKSUM(NEWID())) % 800,
        1 + ABS(CHECKSUM(NEWID())) % 12,
        CONVERT(decimal(18,2), 10 + ABS(CHECKSUM(NEWID())) % 50000 / 10.0)
    FROM sys.all_objects AS a
    CROSS JOIN sys.all_objects AS b;

    CREATE CLUSTERED COLUMNSTORE INDEX CCI_FactSalesDemo
    ON dbo.FactSalesDemo;

    BEGIN TRY
        ALTER INDEX CCI_FactSalesDemo ON dbo.FactSalesDemo REORGANIZE;
    END TRY
    BEGIN CATCH
        SELECT ERROR_NUMBER(),ERROR_MESSAGE();
    END CATCH;
شاخصخروجی نمونهتفسیر
قبل از عملیاتOPEN / CLOSEDوجود Delta Rowgroup یا حذف منطقی
بعد از عملیاتCOMPRESSEDنتیجه مورد انتظار پس از اجرای موفق
نکتهوابسته به Workloadخروجی واقعی را با DMV کنترل کنید

نکته فنی: هنگام استفاده از Maintenance: ALTER INDEX ... REORGANIZE فقط به موفق‌بودن دستور اکتفا نکنید؛ Log Usage را قبل و بعد اندازه بگیرید و اثر آن را روی Workload واقعی ثبت کنید.

مثال 8: اعتبارسنجی وضعیت پس از عملیات

در این مثال، «REORGANIZE ایندکس Columnstore» در سناریوی اعتبارسنجی وضعیت پس از عملیات بررسی می‌شود. Query به‌گونه‌ای نوشته شده که در یک محیط آزمایشی SQL Server قابل اجرا باشد و نتیجه آن با DMV، خروجی تجمیعی یا Metadata کنترل شود.

USE tempdb;
    DROP TABLE IF EXISTS dbo.FactSalesDemo;
    CREATE TABLE dbo.FactSalesDemo
    (
        SaleID bigint NOT NULL,
        OrderDate date NOT NULL,
        CustomerID int NOT NULL,
        ProductID int NOT NULL,
        Quantity smallint NULL,
        Amount decimal(18,2) NULL
    );

    INSERT INTO dbo.FactSalesDemo
    (
        SaleID, OrderDate, CustomerID, ProductID, Quantity, Amount
    )
    SELECT TOP (25000)
        ROW_NUMBER() OVER (ORDER BY (SELECT NULL)),
        DATEADD(day, -ABS(CHECKSUM(NEWID())) % 730, CONVERT(date, '20260727')),
        1 + ABS(CHECKSUM(NEWID())) % 5000,
        1 + ABS(CHECKSUM(NEWID())) % 800,
        1 + ABS(CHECKSUM(NEWID())) % 12,
        CONVERT(decimal(18,2), 10 + ABS(CHECKSUM(NEWID())) % 50000 / 10.0)
    FROM sys.all_objects AS a
    CROSS JOIN sys.all_objects AS b;

    CREATE CLUSTERED COLUMNSTORE INDEX CCI_FactSalesDemo
    ON dbo.FactSalesDemo;

    ALTER INDEX CCI_FactSalesDemo ON dbo.FactSalesDemo REORGANIZE;
    SELECT state_desc,COUNT(*) FROM sys.dm_db_column_store_row_group_physical_stats WHERE object_id=OBJECT_ID(N'dbo.FactSalesDemo') GROUP BY state_desc;
شاخصخروجی نمونهتفسیر
قبل از عملیاتOPEN / CLOSEDوجود Delta Rowgroup یا حذف منطقی
بعد از عملیاتCOMPRESSEDنتیجه مورد انتظار پس از اجرای موفق
نکتهوابسته به Workloadخروجی واقعی را با DMV کنترل کنید

نکته فنی: هنگام استفاده از Maintenance: ALTER INDEX ... REORGANIZE فقط به موفق‌بودن دستور اکتفا نکنید؛ تعداد Rowgroup را قبل و بعد اندازه بگیرید و اثر آن را روی Workload واقعی ثبت کنید.

مثال 9: مقایسه شاخص قبل و بعد

در این مثال، «REORGANIZE ایندکس Columnstore» در سناریوی مقایسه شاخص قبل و بعد بررسی می‌شود. Query به‌گونه‌ای نوشته شده که در یک محیط آزمایشی SQL Server قابل اجرا باشد و نتیجه آن با DMV، خروجی تجمیعی یا Metadata کنترل شود.

USE tempdb;
    DROP TABLE IF EXISTS dbo.FactSalesDemo;
    CREATE TABLE dbo.FactSalesDemo
    (
        SaleID bigint NOT NULL,
        OrderDate date NOT NULL,
        CustomerID int NOT NULL,
        ProductID int NOT NULL,
        Quantity smallint NULL,
        Amount decimal(18,2) NULL
    );

    INSERT INTO dbo.FactSalesDemo
    (
        SaleID, OrderDate, CustomerID, ProductID, Quantity, Amount
    )
    SELECT TOP (25000)
        ROW_NUMBER() OVER (ORDER BY (SELECT NULL)),
        DATEADD(day, -ABS(CHECKSUM(NEWID())) % 730, CONVERT(date, '20260727')),
        1 + ABS(CHECKSUM(NEWID())) % 5000,
        1 + ABS(CHECKSUM(NEWID())) % 800,
        1 + ABS(CHECKSUM(NEWID())) % 12,
        CONVERT(decimal(18,2), 10 + ABS(CHECKSUM(NEWID())) % 50000 / 10.0)
    FROM sys.all_objects AS a
    CROSS JOIN sys.all_objects AS b;

    CREATE CLUSTERED COLUMNSTORE INDEX CCI_FactSalesDemo
    ON dbo.FactSalesDemo;

    SELECT SUM(deleted_rows) AS deleted_before FROM sys.dm_db_column_store_row_group_physical_stats WHERE object_id=OBJECT_ID(N'dbo.FactSalesDemo');
    ALTER INDEX CCI_FactSalesDemo ON dbo.FactSalesDemo REORGANIZE;
شاخصخروجی نمونهتفسیر
قبل از عملیاتOPEN / CLOSEDوجود Delta Rowgroup یا حذف منطقی
بعد از عملیاتCOMPRESSEDنتیجه مورد انتظار پس از اجرای موفق
نکتهوابسته به Workloadخروجی واقعی را با DMV کنترل کنید

نکته فنی: هنگام استفاده از Maintenance: ALTER INDEX ... REORGANIZE فقط به موفق‌بودن دستور اکتفا نکنید؛ پارتیشن هدف را قبل و بعد اندازه بگیرید و اثر آن را روی Workload واقعی ثبت کنید.

مثال 10: گزارش نهایی مصرف و سلامت

در این مثال، «REORGANIZE ایندکس Columnstore» در سناریوی گزارش نهایی مصرف و سلامت بررسی می‌شود. Query به‌گونه‌ای نوشته شده که در یک محیط آزمایشی SQL Server قابل اجرا باشد و نتیجه آن با DMV، خروجی تجمیعی یا Metadata کنترل شود.

USE tempdb;
    DROP TABLE IF EXISTS dbo.FactSalesDemo;
    CREATE TABLE dbo.FactSalesDemo
    (
        SaleID bigint NOT NULL,
        OrderDate date NOT NULL,
        CustomerID int NOT NULL,
        ProductID int NOT NULL,
        Quantity smallint NULL,
        Amount decimal(18,2) NULL
    );

    INSERT INTO dbo.FactSalesDemo
    (
        SaleID, OrderDate, CustomerID, ProductID, Quantity, Amount
    )
    SELECT TOP (25000)
        ROW_NUMBER() OVER (ORDER BY (SELECT NULL)),
        DATEADD(day, -ABS(CHECKSUM(NEWID())) % 730, CONVERT(date, '20260727')),
        1 + ABS(CHECKSUM(NEWID())) % 5000,
        1 + ABS(CHECKSUM(NEWID())) % 800,
        1 + ABS(CHECKSUM(NEWID())) % 12,
        CONVERT(decimal(18,2), 10 + ABS(CHECKSUM(NEWID())) % 50000 / 10.0)
    FROM sys.all_objects AS a
    CROSS JOIN sys.all_objects AS b;

    CREATE CLUSTERED COLUMNSTORE INDEX CCI_FactSalesDemo
    ON dbo.FactSalesDemo;

    ALTER INDEX CCI_FactSalesDemo ON dbo.FactSalesDemo REORGANIZE;
    SELECT SUM(size_in_bytes) AS bytes_after FROM sys.dm_db_column_store_row_group_physical_stats WHERE object_id=OBJECT_ID(N'dbo.FactSalesDemo');
شاخصخروجی نمونهتفسیر
قبل از عملیاتOPEN / CLOSEDوجود Delta Rowgroup یا حذف منطقی
بعد از عملیاتCOMPRESSEDنتیجه مورد انتظار پس از اجرای موفق
نکتهوابسته به Workloadخروجی واقعی را با DMV کنترل کنید

نکته فنی: هنگام استفاده از Maintenance: ALTER INDEX ... REORGANIZE فقط به موفق‌بودن دستور اکتفا نکنید؛ رقابت منابع را قبل و بعد اندازه بگیرید و اثر آن را روی Workload واقعی ثبت کنید.

خطاهای رایج

خطاهای زیر در پروژه‌های واقعی مرتبط با Maintenance: ALTER INDEX ... REORGANIZE دیده می‌شوند. شدت هر خطا به حجم داده و نسخه SQL Server وابسته است، اما اصل کنترل برای همه محیط‌ها یکسان است.

  • زمان‌بندی روزانه بدون شرط
  • توقع Sort مجدد Ordered CCI
  • اجرای هم‌زمان روی همه پارتیشن‌ها
  • عدم پایش Log
  • استفاده به‌جای طراحی Load

مهم‌ترین هشدار: زمان‌بندی روزانه بدون شرط. پیش از هر تغییر گسترده، Backup/Restore آزمایشی، ظرفیت Log و امکان بازگشت را بررسی کنید.

ملاحظات کارایی و پایش

برای ارزیابی REORGANIZE ایندکس Columnstore حداقل پنج محور باید هم‌زمان دیده شود: مدت اجرا, Log Usage, تعداد Rowgroup, پارتیشن هدف, رقابت منابع. اندازه‌گیری تنها زمان اجرا ممکن است نتیجه گمراه‌کننده بدهد، زیرا Cache گرم، Parallelism، Memory Grant و بار هم‌زمان روی نتیجه اثر دارند.

معیارچرا مهم است؟روش پیشنهادی
مدت اجرااثر مستقیم بر کیفیت یا هزینه REORGANIZE ایندکس Columnstore داردپیش و پس DMV بگیرید
Log Usageاثر مستقیم بر کیفیت یا هزینه REORGANIZE ایندکس Columnstore داردپارتیشن را هدف بگیرید
تعداد Rowgroupاثر مستقیم بر کیفیت یا هزینه REORGANIZE ایندکس Columnstore داردپنجره منابع تعریف کنید
پارتیشن هدفاثر مستقیم بر کیفیت یا هزینه REORGANIZE ایندکس Columnstore داردشرط آستانه داشته باشید
رقابت منابعاثر مستقیم بر کیفیت یا هزینه REORGANIZE ایندکس Columnstore داردتوقف‌پذیری Job را طراحی کنید

یک Snapshot منفرد برای تصمیم بلندمدت کافی نیست. داده پایش را در چند بازه کاری، پس از ETL و در ساعات اوج جمع‌آوری کنید تا روند واقعی مشخص شود.

سناریوی عملی و بهینه‌سازی REORGANIZE ایندکس Columnstoreمقایسه روش نامناسب و بهترین روش برای کارایی و نگه‌داری Maintenance: ALTER INDEX ... REORGANIZEسناریوی عملی و بهینه‌سازی REORGANIZE ایندکس ColumnstoreMaintenance: ALTER INDEX ... REORGANIZE1ALTER INDEXروش ضعیف2REORGANIZEاثر3Columnstoreریسک4Delta Rowgroupبهترین روش5Online Maintenanceبهبود6Mergeکنترل

این سناریو تفاوت میان اجرای بدون پایش و اجرای مبتنی بر Best Practice را برای REORGANIZE ایندکس Columnstore مقایسه می‌کند؛ معیارهای اصلی شامل مدت اجرا و Log Usage هستند.

بهترین روش‌ها

  • پیش و پس DMV بگیرید
  • پارتیشن را هدف بگیرید
  • پنجره منابع تعریف کنید
  • شرط آستانه داشته باشید
  • توقف‌پذیری Job را طراحی کنید

Best Practice به‌معنای اجرای یک نسخه ثابت برای همه سرورها نیست. باید توصیه‌ها را با اندازه داده، Edition، Compatibility Level، معماری HA/DR و محدودیت پنجره نگه‌داری تطبیق داد.

پرسش‌های متداول

REORGANIZE ایندکس Columnstore دقیقاً چه مشکلی را حل می‌کند؟

ALTER INDEX ... REORGANIZE برای Columnstore عملیاتی آنلاین و سبک‌تر از Rebuild است که Delta Rowgroupهای بسته را فشرده می‌کند و در نسخه‌های جدید می‌تواند Rowgroupهای فشرده کوچک یا دارای حذف زیاد را ادغام کند. انتخاب آن باید براساس نوع بارکاری و معیارهای قابل اندازه‌گیری انجام شود.

برای شروع یادگیری Maintenance: ALTER INDEX ... REORGANIZE چه پیش‌نیازی لازم است؟

آشنایی با Execution Plan، ایندکس‌ها و دستورات پایه T-SQL کافی است. سپس باید مفاهیم REORGANIZE و Columnstore را روی یک پایگاه داده آزمایشی مشاهده کنید.

آیا REORGANIZE ایندکس Columnstore برای همه پروژه‌های تجاری مناسب است؟

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

هزینه پیاده‌سازی REORGANIZE ایندکس Columnstore چگونه برآورد می‌شود؟

برآورد باید شامل تحلیل Workload، طراحی آزمایش، زمان مهاجرت، پایش پس از اجرا و آموزش تیم باشد. اندازه جدول و حساسیت توقف سرویس نیز روی زمان انجام پروژه اثر مستقیم دارد.

تفاوت REORGANIZE ایندکس Columnstore با یک ایندکس یا روش عمومی چیست؟

روش عمومی معمولاً فقط ساختار یا دستور را می‌بیند، اما این موضوع روی ALTER INDEX، Delta Rowgroup و رفتار واقعی موتور تمرکز دارد. مقایسه باید با Plan، IO، CPU و مدت اجرا انجام شود.

چه زمانی برای اجرای پروژه یا دریافت خدمات مرتبط با Maintenance: ALTER INDEX ... REORGANIZE مناسب است؟

هنگامی که گزارش‌ها کند شده‌اند، رشد داده سریع است یا نگه‌داری فعلی نتیجه قابل پیش‌بینی ندارد، بررسی تخصصی ارزشمند است. بهتر است ابتدا Snapshot فنی و معیار موفقیت تعیین شود.

رایج‌ترین خطا در استفاده از REORGANIZE ایندکس Columnstore چیست؟

یکی از خطاهای پرتکرار «زمان‌بندی روزانه بدون شرط» است. خطای دیگر تصمیم‌گیری بدون مقایسه قبل و بعد و بدون توجه به نسخه SQL Server است.

REORGANIZE ایندکس Columnstore چه اثری بر Performance دارد؟

اثر اصلی از مسیر مدت اجرا، Log Usage و تعداد Rowgroup دیده می‌شود. نتیجه می‌تواند بسیار مثبت یا در Workload نامناسب منفی باشد، بنابراین تست کنترل‌شده ضروری است.

بهترین روش عملی برای REORGANIZE ایندکس Columnstore چیست؟

از یک محیط آزمایشی مشابه Production شروع کنید، پیش و پس DMV بگیرید و پارتیشن را هدف بگیرید را اجرا کنید و معیارها را در Query Store یا سامانه پایش ثبت نمایید.

سازگاری Maintenance: ALTER INDEX ... REORGANIZE با نسخه‌های SQL Server چگونه است؟

رفتار دقیق ادغام Rowgroup از SQL Server 2016 به بعد توسعه یافته و در نسخه‌های جدید نگه‌داری خودکار نیز فعال‌تر است. پیش از انتشار در Production، Syntax و گزینه‌های قابل پشتیبانی را روی همان Edition، Version و Compatibility Level بررسی کنید.

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

پاسخ مناسب به پرسش‌های زیر باید علاوه بر تعریف، شامل سناریو، Trade-off، معیار اندازه‌گیری و نمونه T-SQL باشد.

  1. تفاوت ALTER INDEX و REORGANIZE را با یک سناریوی واقعی توضیح دهید.
  2. برای سنجش اثر Maintenance: ALTER INDEX ... REORGANIZE چه شاخص‌هایی را قبل و بعد ثبت می‌کنید؟
  3. در چه شرایطی «زمان‌بندی روزانه بدون شرط» باعث افت کارایی می‌شود؟
  4. چگونه با استفاده از Columnstore و Delta Rowgroup مشکل را عیب‌یابی می‌کنید؟
  5. در طراحی یک Job سازمانی برای REORGANIZE ایندکس Columnstore چه کنترل خطا و Rollback در نظر می‌گیرید؟
  6. چرا توصیه «پیش و پس DMV بگیرید» برای محیط Production مهم است؟

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

  1. نسخه و Compatibility Level برای Maintenance: ALTER INDEX ... REORGANIZE کنترل شد.
  2. خط پایه IO، CPU، Duration و فضای مصرفی ثبت شد.
  3. Query و Syntax در محیط آزمایشی اجرا شد.
  4. اثرات DML و ETL جداگانه سنجیده شد.
  5. خروجی DMV یا Metadata پس از اجرا بررسی شد.
  6. Rollback Plan و ظرفیت Log مشخص شد.
  7. گزارش مقایسه قبل و بعد ذخیره شد.
  8. Job یا رویه نگه‌داری دارای شرط و کنترل خطا است.

جمع‌بندی

REORGANIZE ایندکس Columnstore زمانی مفید است که از حالت یک دستور منفرد خارج و به یک فرایند اندازه‌گیری‌شده تبدیل شود. ALTER INDEX ... REORGANIZE برای Columnstore عملیاتی آنلاین و سبک‌تر از Rebuild است که Delta Rowgroupهای بسته را فشرده می‌کند و در نسخه‌های جدید می‌تواند Rowgroupهای فشرده کوچک یا دارای حذف زیاد را ادغام کند. در عمل باید با نسخه SQL Server، شکل داده و هدف گزارش‌گیری سازگار شود.

برای مطالعه ارتباط این موضوع با سایر اجزای Columnstore، راهنمای جامع کارایی Columnstore در SQL Server را ببینید.

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

برنامه‌نویسی در اصفهان

قبول سفارش‌های برنامه‌نویسی و پایگاه داده: 09131253620

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

مجموعه‌ای معتبر با سابقه فعالیت حرفه‌ای از سال ۱۳۷۵ شمسی

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

برای سفارش پروژه‌های برنامه‌نویسی و پایگاه داده، سیستم‌های تحت وب، وب‌سایت و راهکارهای نرم‌افزاری جدید، با شماره تلفن همراه 09131253620 تماس حاصل فرمایید.

ایتا، واتساپ و تماس مستقیم: +989131253620

تماس با ما

 

0 نظر

نظر محترم شما در مورد مقاله های وب سایت برنامه نویسی و پایگاه داده

نظرات محترم شما در خدمات رسانی بهتر ما را یاری می نمایند. لطفا اگر مایل بودید یک نظر ما را مهمان فرمائید. آدرس ایمیل و وب سایت شما نمایش داده نخواهد شد.

حرف 500 حداکثر