インデックスを再構成または再構築することでインデックス断片化を解決するResolve index fragmentation by reorganizing or rebuilding indexes

適用対象:Applies to: はいSQL ServerSQL Server (サポートされているすべてのバージョン) yesSQL ServerSQL Server (all supported versions) はいAzure SQL データベースAzure SQL DatabaseYesAzure SQL データベースAzure SQL Database はいAzure SQL Managed InstanceAzure SQL Managed InstanceYesAzure SQL Managed InstanceAzure SQL Managed Instance はいAzure Synapse AnalyticsAzure Synapse AnalyticsyesAzure Synapse AnalyticsAzure Synapse Analytics はいParallel Data WarehouseParallel Data WarehouseyesParallel Data WarehouseParallel Data Warehouse適用対象:Applies to: はいSQL ServerSQL Server (サポートされているすべてのバージョン) yesSQL ServerSQL Server (all supported versions) はいAzure SQL データベースAzure SQL DatabaseYesAzure SQL データベースAzure SQL Database はいAzure SQL Managed InstanceAzure SQL Managed InstanceYesAzure SQL Managed InstanceAzure SQL Managed Instance はいAzure Synapse AnalyticsAzure Synapse AnalyticsyesAzure Synapse AnalyticsAzure Synapse Analytics はいParallel Data WarehouseParallel Data WarehouseyesParallel Data WarehouseParallel Data Warehouse

この記事では、インデックス断片化が発生するしくみと、クエリのパフォーマンスにそれが与える影響について説明します。This article describes how index defragmentation occurs and discusses its impact on query performance. インデックスに存在する断片化の量を判断したら、自分で選択したツールで Transact-SQL コマンドを実行するか、SQL Server Management Studio を使用してインデックスを再構成するか、再構築することでインデックスをデフラグできます。Once you determine the amount of fragmentation that exists for an index, you can defragment an index by either reorganizing an index or rebuilding an index by running Transact-SQL commands in your tool of choice or by using SQL Server Management Studio.

インデックスの断片化の概要Index fragmentation overview

インデックスの断片化とはどういうことで、なぜ注意する必要があるのでしょうか。What is index fragmentation and why should I care about it:

  • インデックスに、インデックスのキー値に基づくインデックス内での論理的な順序と、インデックス ページの内部での物理的な順序が一致しないページが存在すると、断片化が発生します。Fragmentation exists when indexes have pages in which the logical ordering within the index, based on the key value of the index, does not match the physical ordering inside the index pages.
  • データベース エンジンDatabase Engine では、基になるデータに対して挿入、更新、または削除の各操作が行われるたびに、インデックスが自動的に変更されます。The データベース エンジンDatabase Engine automatically modifies indexes whenever insert, update, or delete operations are made to the underlying data. たとえば、テーブルに行が追加されると、行ストア インデックス内の既存のページが分割されて、新しいキー値を挿入するための領域が確保される場合があります。For example, the addition of rows in a table may cause existing pages in rowstore indexes to split to make room for the insertion of new key values. このような変更が長期にわたると、インデックス内の情報がデータベース内に散在 (断片化) することになります。Over time these modifications can cause the information in the index to become scattered in the database (fragmented). インデックスに、キー値に基づく論理順序とデータ ファイル内の物理順序が一致しないページが存在すると、断片化が発生します。Fragmentation exists when indexes have pages in which the logical ordering, based on the key value, does not match the physical ordering inside the data file.
  • インデックスの断片化が大きくなると、インデックスが指し示しているデータを特定するために必要な I/O が増加するため、クエリのパフォーマンスが低下する可能性があります。Heavily fragmented indexes can degrade query performance because additional I/O is required to locate data to which the index points. I/O が多くなると、アプリケーションの応答が遅くなります。スキャン操作が関係している場合は特にそうです。More I/O causes your application to respond slowly, especially when scan operations are involved.

断片化の量を検出するDetecting the amount of fragmentation

使用するインデックス最適化方法を決める最初のステップは、断片化の程度を判断するためにインデックスを分析することです。The first step in deciding which index defragmentation method to use is to analyze the index to determine the degree of fragmentation. 行ストア インデックスと列ストア インデックスの断片化を異なる方法で検出します。You detect fragmentation differently for rowstore indexes and columnstore indexes.

注意

大量のデータを削除した後は、インデックスまたはヒープの断片化を確認することが特に重要です。It's especially important to review index or heap fragmentation after large amounts of data are deleted. ヒープについては、更新が頻繁に行われる場合、転送レコードの急増を回避するために断片化を確認することが必要になる場合もあります。For heaps, if there are frequent updates, it may also be needed to review fragmentation to avoid proliferation of forwarding records. ヒープの詳細については、「ヒープ (クラスター化インデックスなしのテーブル)」を参照してください。For more information about heaps, see Heaps (Tables without Clustered Indexes).

行ストア インデックスの断片化を検出するDetecting fragmentation of rowstore indexes

sys.dm_db_index_physical_stats を使用して、特定のインデックス、テーブルやインデックス付きビュー上のすべてのインデックス、データベース内のすべてのインデックス、またはすべてのデータベース内のすべてのインデックスの断片化を検出できます。By using sys.dm_db_index_physical_stats, you can detect fragmentation in a specific index, all indexes on a table or indexed view, all indexes in a database, or all indexes in all databases. パーティション インデックスの場合は、 sys.dm_db_index_physical_stats でもパーティションごとの断片化情報が提供されます。For partitioned indexes, sys.dm_db_index_physical_stats also provides fragmentation information for each partition.

sys.dm_db_index_physical_stats から返される結果セットに含まれる列を次に示します。The result set returned by sys.dm_db_index_physical_stats includes the following columns:

Column 説明Description
avg_fragmentation_in_percentavg_fragmentation_in_percent 論理的な断片化 (インデックス内で順序が乱れたページ) の割合。The percent of logical fragmentation (out-of-order pages in the index).
fragment_countfragment_count インデックス内の断片化 (物理的に連続したリーフ ページ) の数。The number of fragments (physically consecutive leaf pages) in the index.
avg_fragment_size_in_pagesavg_fragment_size_in_pages インデックス内の 1 つの断片化内の平均ページ数。Average number of pages in one fragment in an index.

断片化の程度がわかったら、次の表を使用して、断片化をなくすための最適な方法を決定します。INDEX REORGANIZEINDEX です。After the degree of fragmentation is known, use the following table to determine the best method to remove the fragmentation: INDEX REORGANIZE or INDEX.

avg_fragmentation_in_percentavg_fragmentation_in_percent value 断片化解消ステートメントCorrective statement
5 から 30%1> 5% and < = 30% 1 ALTER INDEX REORGANIZEALTER INDEX REORGANIZE
> 30% 1> 30% 1 ALTER INDEX REBUILD WITH (ONLINE = ON) 2ALTER INDEX REBUILD WITH (ONLINE = ON) 2

1 これらの値は、ALTER INDEX REORGANIZEALTER INDEX REBUILD を切り替える必要があるタイミングを決定するための大まかなガイドラインを提供します。1 These values provide a rough guideline for determining the point at which you should switch between ALTER INDEX REORGANIZE and ALTER INDEX REBUILD. ただし、実際の値は状況によって変わります。However, the actual values may vary from case to case. それぞれの環境で実際に試して最適なしきい値を特定することが重要です。It is important that you experiment to determine the best threshold for your environment.

ヒント

たとえば、特定のインデックスが主にスキャン操作に使用されている場合、断片化を解消すると、これらの操作のパフォーマンスが向上します。For example, if a given index is used mainly for scan operations, removing fragmentation can improve performance of these operations. 主にシーク操作に使用されるインデックスについては、パフォーマンスのメリットがそれほど顕著ではない場合があります。The performance benefit may not be noticeable for indexes that are used primarily for seek operations.
同様に、ヒープ (クラスター化インデックスのないテーブル) 内の断片化の解消は、非クラスター化インデックスのスキャン操作では特に便利ですが、参照操作にはほとんど影響しません。Similarly, removing fragmentation in a heap (a table with no clustered index) is especially useful for nonclustered index scan operations, but has little effect in lookup operations.

2 インデックスの再構築はオンラインでもオフラインでも実行できます。2 Rebuilding an index can be executed online or offline. インデックスの再構成は、常にオンラインで実行されます。Reorganizing an index is always executed online. 再構成オプションと同様の可用性を実現するには、インデックスをオンラインで再構築してください。To achieve availability similar to the reorganize option, you should rebuild indexes online. 詳しくは、インデックスに関するページと「オンラインでのインデックス操作の実行」をご覧ください。For more information, see INDEX and Perform Index Operations Online.

インデックスの断片化が 5% 未満の場合は、デフラグする必要はありません。これは、インデックスの再構成または再構築で、このような少量の断片化を解消するのに見合わない CPU コストが通常かかるからです。Indexes with fragmentation of less than 5 percent do not need to be defragmented because the benefit from removing such a small amount of fragmentation is almost always vastly outweighed by the CPU cost incurred to reorganize or rebuild the index. また、少量の行ストア インデックスを再構築または再構成しても、一般的に実際断片化は解消されません。Also, rebuilding or reorganizing small rowstore indexes generally does not reduce actual fragmentation. SQL Server 2014 (12.x)SQL Server 2014 (12.x)までは、SQL Server データベース エンジンSQL Server Database Engineでは、混合エクステントを使用して領域が割り当てられます。Up to, and including, SQL Server 2014 (12.x)SQL Server 2014 (12.x), the SQL Server データベース エンジンSQL Server Database Engine allocates space using mixed extents. このため、小さいインデックスのページは、混合エクステントに格納される場合があります。Therefore, pages of small indexes are sometimes stored on mixed extents. 混合エクステントは最大 8 つのオブジェクトで共有されるため、小さなインデックスを再構成または再構築しても、その断片化は解消されない場合があります。Mixed extents are shared by up to eight objects, so the fragmentation in a small index might not be reduced after reorganizing or rebuilding it. 行ストア インデックスの再構築に固有の注意点」を参照してください。See also Considerations specific to rebuilding rowstore indexes. エクステントの詳細については、「ページとエクステントのアーキテクチャ ガイド」を参照してください。For more information about extents, see the Pages and Extents Architecture Guide.

列ストア インデックスの断片化を検出するDetecting fragmentation of columnstore indexes

sys.dm_db_column_store_row_group_physical_stats を使用することで、インデックスで削除された行の割合を確認できます。これは、列ストア インデックスの行グループの断片化に対する妥当なメジャーです。By using sys.dm_db_column_store_row_group_physical_stats, you can determine the percentage of deleted rows in an index, which is a reasonable measure for fragmentation in a rowgroup of a columnstore index. この情報を使用して、特定のインデックス、テーブルのすべてのインデックス、データベース内のすべてのインデックス、またはすべてのデータベース内のすべてのインデックスの断片化を計算します。Use this information to compute the fragmentation in a specific index, all indexes on a table, all indexes in a database, or all indexes in all databases.

sys.dm_db_column_store_row_group_physical_stats から返される結果セットに含まれる列を次に示します。The result set returned by sys.dm_db_column_store_row_group_physical_stats includes the following columns:

Column 説明Description
total_rowstotal_rows 行グループに物理的に格納されている行の数。Number of rows physical stored in the row group. 圧縮された行グループの場合は、削除済みとマークされた行が含まれます。For compressed row groups, this includes the rows that are marked as deleted.
deleted_rowsdeleted_rows 削除対象としてマークされている圧縮行グループに物理的に格納されている行の数。Number of rows physically stored in a compressed row group that are marked for deletion. デルタ ストア内の行グループの場合は 0 です。0 for row groups that are in the delta store.

次の式を使用して、インデックスの断片化を計算するために返されたこの情報を使用します。Use this information returned to compute index fragmentation using this formula:

100*(ISNULL(deleted_rows,0))/NULLIF(total_rows,0)

インデックスの断片化の程度がわかったら、次の表を使用して、断片化をなくすための最適な方法を決定します。INDEX REORGANIZEINDEX です。After the degree of index fragmentation is known, use the following table to determine the best method to remove the fragmentation: INDEX REORGANIZE or INDEX.

計算された断片化のパーセント値computed fragmentation in percent value 適用されるバージョンApplies to version 断片化解消ステートメントCorrective statement
> = 20%> = 20% SQL Server 2012 (11.x)SQL Server 2012 (11.x) および SQL Server 2014 (12.x)SQL Server 2014 (12.x)and SQL Server 2014 (12.x)SQL Server 2014 (12.x) ALTER INDEX REBUILDALTER INDEX REBUILD
> = 20%> = 20% SQL Server 2016 (13.x)SQL Server 2016 (13.x) 以降Starting with SQL Server 2016 (13.x)SQL Server 2016 (13.x) ALTER INDEX REORGANIZEALTER INDEX REORGANIZE

Transact-SQLTransact-SQL を利用して行ストア インデックスの断片化を確認するにはTo check the fragmentation of a rowstore index using Transact-SQLTransact-SQL

次の例では、AdventureWorks2016 データベースの HumanResources.Employee テーブルで、すべてのインデックスの断片化の平均パーセンテージを調べます。The following example finds the average fragmentation percentage of all indexes in the HumanResources.Employee table in the AdventureWorks2016 database.

SELECT a.object_id, object_name(a.object_id) AS TableName,
    a.index_id, name AS IndedxName, avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats
    (DB_ID (N'AdventureWorks2016_EXT')
        , OBJECT_ID(N'HumanResources.Employee')
        , NULL
        , NULL
        , NULL) AS a
INNER JOIN sys.indexes AS b
    ON a.object_id = b.object_id
    AND a.index_id = b.index_id;
GO

前のステートメントによって、次のような結果セットが返されます。The previous statement returns a result set similar to the following.

object_id   TableName    index_id    IndexName                                             avg_fragmentation_in_percent
----------- ------------ ----------- ----------------------------------------------------- ------------------------------
1557580587  Employee     1           PK_Employee_BusinessEntityID                          0
1557580587  Employee     2           IX_Employee_OrganizationalNode                        0
1557580587  Employee     3           IX_Employee_OrganizationalLevel_OrganizationalNode    0
1557580587  Employee     5           AK_Employee_LoginID                                   66.6666666666667
1557580587  Employee     6           AK_Employee_NationalIDNumber                          50
1557580587  Employee     7           AK_Employee_rowguid                                   0

(6 row(s) affected)

詳細については、sys.dm_db_index_physical_stats に関する記事をご覧ください。For more information, see sys.dm_db_index_physical_stats.

Transact-SQLTransact-SQL を利用して列ストア インデックスの断片化を確認するにはTo check the fragmentation of a columnstore index using Transact-SQLTransact-SQL

次の例では、AdventureWorksDW2016 データベースの dbo.FactResellerSalesXL_CCI テーブルで、すべてのインデックスの断片化の平均パーセンテージを調べます。The following example finds the average fragmentation percentage of all indexes in the dbo.FactResellerSalesXL_CCI table in the AdventureWorksDW2016 database.

SELECT i.object_id,
    object_name(i.object_id) AS TableName,
    i.index_id,
    i.name AS IndexName,
    100*(ISNULL(SUM(CSRowGroups.deleted_rows),0))/NULLIF(SUM(CSRowGroups.total_rows),0) AS 'Fragmentation'
FROM sys.indexes AS i  
INNER JOIN sys.dm_db_column_store_row_group_physical_stats AS CSRowGroups
    ON i.object_id = CSRowGroups.object_id
    AND i.index_id = CSRowGroups.index_id
WHERE object_name(i.object_id) = 'FactResellerSalesXL_CCI'
GROUP BY i.object_id, i.index_id, i.name
ORDER BY object_name(i.object_id), i.name;

前のステートメントによって、次のような結果セットが返されます。The previous statement returns a result set similar to the following.

object_id   TableName                   index_id    IndexName                       Fragmentation
----------- --------------------------- ----------- ------------------------------- ---------------
114099447   FactResellerSalesXL_CCI     1           IndFactResellerSalesXL_CCI      0

(1 row(s) affected)

SQL Server Management Studio を使用してインデックス断片化を確認するCheck index fragmentation using SQL Server Management Studio

注意

SQL Server の列ストア インデックスの断片化を計算するために、また、Azure SQL Database 内のインデックスの断片化を計算するために、Management StudioManagement Studio を使用することはできません。Management StudioManagement Studio cannot be used to compute fragmentation of columnstore indexes in SQL Server and cannot be used to compute fragmentation of any indexes in Azure SQL Database. これらのシナリオには前の Transact-SQLTransact-SQLを使用します。Use the preceding Transact-SQLTransact-SQL example for these scenarios.

  1. オブジェクト エクスプローラーで、インデックスの断片化を確認するテーブルが格納されているデータベースを展開します。In Object Explorer, Expand the database that contains the table on which you want to check an index's fragmentation.
  2. [テーブル] フォルダーを展開します。Expand the Tables folder.
  3. インデックスの断片化を確認するテーブルを展開します。Expand the table on which you want to check an index's fragmentation.
  4. [インデックス] フォルダーを展開します。Expand the Indexes folder.
  5. 断片化を確認するインデックスを右クリックし、 [プロパティ] を選択します。Right-click the index of which you want to check the fragmentation and select Properties.
  6. [ページの選択][断片化] を選択します。Under Select a page, select Fragmentation.

[断片化] ページでは、次の情報を取得できます。The following information is available on the Fragmentation page:

Value 説明Description
[ページのゆとり]Page fullness インデックス ページのゆとりの平均をパーセントで示します。Indicates average fullness of the index pages, as a percentage. 100% は、インデックス ページが完全にいっぱいであることを示します。100% means the index pages are completely full. 50% は、平均して各インデックス ページが半分埋まっていることを示します。50% means that, on average, each index page is half full.
[全体の断片化]Total fragmentation 論理的な断片化の割合です。The logical fragmentation percentage. この値は、順番に格納されないインデックス内のページ数を示します。This indicates the number of pages in an index that are not stored in order.
[行の平均サイズ]Average row size リーフ レベルの行の平均サイズです。The average size of a leaf-level row.
[奥行]Depth インデックス内のレベルの数 (リーフ レベルを含む) です。The number of levels in the index, including the leaf-level.
[転送されたレコード]Forwarded records 別のデータの場所への転送ポインターを持つ、ヒープ内の転送されたレコード数ですThe number of records in a heap that have forward pointers to another data location. (この状態は、更新中に、新しい行を格納できる十分なスペースが元の場所にない場合に発生します)。(This state occurs during an update, when there is not enough room to store the new row in the original location.)
[非実体行]Ghost rows 削除のマークが付けられている行の中で、まだ削除されていない行の数です。The number of rows that are marked as deleted but not yet removed. これらの行は、サーバーが使用中でないときにクリーンアップ スレッドによって削除されます。These rows will be removed by a clean-up thread, when the server is not busy. この値には、スナップショット分離トランザクションが未完了であるために保持される行は含まれません。This value does not include rows that are being retained due to an outstanding snapshot isolation transaction.
[インデックスの種類]Index type インデックスの種類です。The type of index. 指定できる値は、 [クラスター化][非クラスター化] 、および [プライマリ XML] です。Possible values are Clustered index, Nonclustered index, and Primary XML. テーブルは、ヒープ (インデックスなし) としても格納できますが、その場合は、この [インデックスのプロパティ] ページは開きません。Tables can also be stored as a heap (without indexes), but then this Index Properties page cannot be opened.
[リーフレベルの行]Leaf-level rows リール レベルの行の数です。The number of leaf-level rows.
[行の最大サイズ]Maximum row size リーフ レベルの最大行サイズです。The maximum leaf-level row size.
[行の最小サイズ]Minimum row size リーフ レベルの最小行サイズです。The minimum leaf-level row size.
ページPages データ ページ数の合計です。The total number of data pages.
パーティション IDPartition ID インデックスを含む B ツリーのパーティション ID です。The partition ID of the b-tree containing the index.
[バージョンの非実体行]Version ghost rows 未処理のスナップショット分離トランザクションが原因で保持されているゴースト レコードの数。The number of ghost records that are being retained due to an outstanding snapshot isolation transaction.

インデックスを再構築または再構成してインデックスをデフラグするDefragmenting indexes by rebuilding or reorganizing the index

次のいずれかの方法で断片化したインデックスをデフラグします。You defragment a fragmented index by using one of the following methods:

  • インデックスの再編成Index reorganization
  • インデックスの再構築Index rebuild

注意

パーティション構成に基づいて構築されたパーティション インデックスでは、完全なインデックスまたはインデックスの 1 つのパーティションに対して、次のいずれかの方法を使用できます。For partitioned indexes built on a partition scheme, you can use either of the following methods on a complete index or a single partition of an index.

インデックスを再構成するReorganize an index

インデックスの再構成では、最小のシステム リソースがオンライン操作で使用されます。Reorganizing an index uses minimal system resources and is an online operation. つまり、ALTER INDEX REORGANIZE トランザクション中は、長期にわたって他をブロックするテーブル ロックは保持されず、基になるテーブルへのクエリまたは更新を続行できます。This means long-term blocking table locks are not held and queries or updates to the underlying table can continue during the ALTER INDEX REORGANIZE transaction.

  • 行ストアの場合は、データベース エンジンDatabase Engine により、リーフ レベル ページをリーフ ノードの論理順序 (左から右) に合わせて物理的に並べ替えることにより、テーブルやビュー上にあるクラスター化および非クラスター化インデックスのリーフ レベルが最適化されます。For rowstore indexes, the データベース エンジンDatabase Engine defragments the leaf level of clustered and nonclustered indexes on tables and views by physically reordering the leaf-level pages to match the logical order of the leaf nodes (left to right). また、再構成を行うと、インデックスの FILL FACTOR の値に基づいて、インデックス ページが圧縮されます。Reorganizing also compacts the index pages based on the index's fill factor value. FILL FACTOR 設定を表示するには、sys.indexes を使用します。To view the fill factor setting, use sys.indexes. 構文の例については、行ストアの再構成の例に関する記事をご覧ください。For syntax examples, see Examples: Rowstore reorganize.

  • 列ストア インデックスを使用している場合は、時間が経つと、データの挿入、更新、削除の後で、差分ストアが複数の小さな行グループになることがあります。When using columnstore indexes, the delta store may end up with multiple small rowgroups after inserting, updating, and deleting data over time. 列ストア インデックスを再構成すると、すべての行グループが列ストアに強制的に移動された後、行グループが、より行数の多い少数の行グループに結合されます。Reorganizing a columnstore index forces all of the rowgroups into the columnstore, and then combines the rowgroups into fewer rowgroups with more rows. 再構成操作では、列ストアから削除された行も削除されます。The reorganize operation also removes rows that have been deleted from the columnstore. 再構成では、最初にデータを圧縮するために必要な CPU リソースが増加し、システムの全体的なパフォーマンスが遅くなる場合があります。Reorganizing initially requires additional CPU resources to compress the data, which may slow overall system performance. しかし、データが圧縮されるとすぐ、クエリのパフォーマンスは改善します。However, as soon as the data is compressed, query performance improves. 構文の例については、列ストアの再構成の例に関する記事をご覧ください。For syntax examples, see Examples: ColumnStore reorganize.

インデックスを再構築するRebuild an index

インデックスの再構築では、インデックスを削除し再作成します。Rebuilding an index drops and re-creates the index. インデックスの種類と データベース エンジンDatabase Engine のバージョンによっては、再構築操作をオンラインまたはオフラインで実行できます。Depending on the type of index and データベース エンジンDatabase Engine version, a rebuild operation can be done online or offline. T-SQL の構文については、ALTER INDEX REBUILD に関する記事を参照してくださいFor the T-SQL syntax, see ALTER INDEX REBUILD

  • 行ストア インデックスの場合、再構築では、断片化が解消され、指定または既存の FILL FACTOR の設定に基づいてページが圧縮されることによりディスク領域が解放された後、インデックス行が連続するページに再び並べ替えられます。For rowstore indexes, rebuilding removes fragmentation, reclaims disk space by compacting the pages based on the specified or existing fill factor setting, and reorders the index rows in contiguous pages. ALL を指定した場合、テーブル上のすべてのインデックスが、1 回のトランザクションで削除され再構築されます。When ALL is specified, all indexes on the table are dropped and rebuilt in a single transaction. 外部キー制約は、前もって削除しておく必要はありません。Foreign key constraints do not have to be dropped in advance. 128 以上のエクステントがあるインデックスを再構築すると、データベース エンジンDatabase Engineでは、トランザクションがコミットされるまで実際のページの割り当て解除とそれに関連するロックが延期されます。When indexes with 128 extents or more are rebuilt, the データベース エンジンDatabase Engine defers the actual page deallocations, and their associated locks, until after the transaction commits. 構文の例については、行ストアの再構成の例に関する記事をご覧ください。For syntax examples, see Examples: Rowstore reorganize.

  • 列ストア インデックスでは、再構築によって断片化が解消され、すべての行が列ストアに移動されて、テーブルから論理的に削除された行を物理的に削除することによってディスク領域が解放されます。For columnstore indexes, rebuilding removes fragmentation, moves all rows into the columnstore, and reclaims disk space by physically deleting rows that have been logically deleted from the table.

    ヒント

    SQL Server 2016 (13.x)SQL Server 2016 (13.x) 以降では、REORGANIZE によってオンライン操作としてバックグラウンドで基本的な再構築が実行されるため、通常、列ストア インデックスの再構築は必要ありません。Starting with SQL Server 2016 (13.x)SQL Server 2016 (13.x), rebuilding the columnstore index is usually not needed since REORGANIZE performs the essentials of a rebuild in the background as an online operation.

    構文の例については、列ストアのリビルドに関するページを参照してください。For syntax examples, see Examples: ColumnStore rebuild.

PermissionsPermissions

テーブルまたはビューに対する ALTER 権限が必要です。Requires ALTER permission on the table or view. ユーザーは次のロールの少なくとも 1 つのメンバーである必要があります。User must be a member of at least one of the following roles:

  • db_ddladmin データベース ロール 1db_ddladmin database role 1
  • db_owner データベース ロールdb_owner database role
  • sysadmin サーバー ロールsysadmin server role

1db_ddladmin データベース ロールには 最も低い特権レベルが設定されています。1db_ddladmin database role is the least privileged.

SQL Server Management StudioSQL Server Management Studio を利用して断片化を取り除くRemove fragmentation using SQL Server Management StudioSQL Server Management Studio

インデックスを再構成または再構築するにはTo reorganize or rebuild an index

  1. オブジェクト エクスプローラーで、インデックスを再構成するテーブルが格納されているデータベースを展開します。In Object Explorer, Expand the database that contains the table on which you want to reorganize an index.
  2. [テーブル] フォルダーを展開します。Expand the Tables folder.
  3. インデックスを再構成するテーブルを展開します。Expand the table on which you want to reorganize an index.
  4. [インデックス] フォルダーを展開します。Expand the Indexes folder.
  5. 再構成するインデックスを右クリックし、 [再構成] を選択します。Right-click the index you want to reorganize and select Reorganize.
  6. [インデックスの再構成] ダイアログ ボックスで、 [再構成するインデックス] グリッドに目的のインデックスが表示されていることを確認し、 [OK] をクリックします。In the Reorganize Indexes dialog box, verify that the correct index is in the Indexes to be reorganized grid and click OK.
  7. [ラージ オブジェクトの列データを圧縮する] チェック ボックスをオンにして、ラージ オブジェクト (LOB) データを含むページもすべて圧縮することを指定します。Select the Compact large object column data check box to specify that all pages that contain large object (LOB) data are also compacted.
  8. [OK] をクリックします。Click OK.

テーブルのすべてのインデックスを再構成するにはTo reorganize all indexes in a table

  1. オブジェクト エクスプローラーで、インデックスを再構成するテーブルが格納されているデータベースを展開します。In Object Explorer, Expand the database that contains the table on which you want to reorganize the indexes.
  2. [テーブル] フォルダーを展開します。Expand the Tables folder.
  3. インデックスを再構成するテーブルを展開します。Expand the table on which you want to reorganize the indexes.
  4. [インデックス] フォルダーを右クリックし、 [すべて再構成] を選択します。Right-click the Indexes folder and select Reorganize All.
  5. [インデックスの再構成] ダイアログ ボックスで、 [再構成するインデックス] に目的のインデックスが表示されていることを確認します。In the Reorganize Indexes dialog box, verify that the correct indexes are in the Indexes to be reorganized. [再構成するインデックス] グリッドからインデックスを削除するには、インデックスを選択し、Del キーを押します。To remove an index from the Indexes to be reorganized grid, select the index and then press the Delete key.
  6. [ラージ オブジェクトの列データを圧縮する] チェック ボックスをオンにして、ラージ オブジェクト (LOB) データを含むページもすべて圧縮することを指定します。Select the Compact large object column data check box to specify that all pages that contain large object (LOB) data are also compacted.
  7. [OK] をクリックします。Click OK.

インデックスを再構築するにはTo rebuild an index

  1. オブジェクト エクスプローラーで、インデックスを再構成するテーブルが格納されているデータベースを展開します。In Object Explorer, Expand the database that contains the table on which you want to reorganize an index.
  2. [テーブル] フォルダーを展開します。Expand the Tables folder.
  3. インデックスを再構成するテーブルを展開します。Expand the table on which you want to reorganize an index.
  4. [インデックス] フォルダーを展開します。Expand the Indexes folder.
  5. 再構成するインデックスを右クリックし、 [再構築] を選択します。Right-click the index you want to reorganize and select Rebuild.
  6. [インデックスの再構築] ダイアログ ボックスで、 [再構築するインデックス] グリッドに目的のインデックスが表示されていることを確認し、 [OK] をクリックします。In the Rebuild Indexes dialog box, verify that the correct index is in the Indexes to be rebuilt grid and click OK.
  7. [ラージ オブジェクトの列データを圧縮する] チェック ボックスをオンにして、ラージ オブジェクト (LOB) データを含むページもすべて圧縮することを指定します。Select the Compact large object column data check box to specify that all pages that contain large object (LOB) data are also compacted.
  8. [OK] をクリックします。Click OK.

Transact-SQLTransact-SQL を利用して断片化を取り除くRemove fragmentation using Transact-SQLTransact-SQL

注意

Transact-SQLTransact-SQL を使ってインデックスを再構築または再構成する他の例については、ALTER INDEX の例: 列ストア インデックスに関するページおよび ALTER INDEX の例: 行ストア インデックスに関するページをご覧ください。For more examples about using Transact-SQLTransact-SQL to rebuild or reorganize indexes, see ALTER INDEX Examples: Columnstore Indexes and ALTER INDEX Examples: Rowstore Indexes.

断片化されたインデックスを再構成するにはTo reorganize a fragmented index

次の例では、AdventureWorks2016 データベースの HumanResources.Employee テーブルの IX_Employee_OrganizationalLevel_OrganizationalNode インデックスが再構成されます。The following example reorganizes the IX_Employee_OrganizationalLevel_OrganizationalNode index on the HumanResources.Employee table in the AdventureWorks2016 database.

ALTER INDEX IX_Employee_OrganizationalLevel_OrganizationalNode
    ON HumanResources.Employee
    REORGANIZE;

次の例では、AdventureWorksDW2016 データベースの dbo.FactResellerSalesXL_CCI テーブルの IndFactResellerSalesXL_CCI 列ストア インデックスが再構成されます。The following example reorganizes the IndFactResellerSalesXL_CCI columnstore index on the dbo.FactResellerSalesXL_CCI table in the AdventureWorksDW2016 database.

-- This command will force all CLOSED and OPEN rowgroups into the columnstore.
ALTER INDEX IndFactResellerSalesXL_CCI
    ON FactResellerSalesXL_CCI
    REORGANIZE WITH (COMPRESS_ALL_ROW_GROUPS = ON);

テーブルのすべてのインデックスを再構成するにはTo reorganize all indexes in a table

次の例では、AdventureWorks2016 データベースの HumanResources.Employee テーブルのすべてのインデックスが再構成されます。The following example reorganizes all indexes on the HumanResources.Employee table in the AdventureWorks2016 database.

ALTER INDEX ALL ON HumanResources.Employee
   REORGANIZE;

断片化されたインデックスを再構築するにはTo rebuild a fragmented index

次の例では、AdventureWorks2016 データベースにある Employee テーブルで単一のインデックスを再構築します。The following example rebuilds a single index on the Employee table in the AdventureWorks2016 database.

ALTER INDEX PK_Employee_BusinessEntityID ON HumanResources.Employee
REBUILD
;

テーブルのすべてのインデックスを再構築するにはTo rebuild all indexes in a table

次の例では、ALL キーワードを使って、AdventureWorks2016 データベース内のテーブルに関連付けられたすべてのインデックスが再構築されます。The following example rebuilds all indexes associated with the table in the AdventureWorks2016 database using the ALL keyword. 3 つのオプションが指定されます。Three options are specified.

ALTER INDEX ALL ON Production.Product
REBUILD WITH (FILLFACTOR = 80, SORT_IN_TEMPDB = ON,
              STATISTICS_NORECOMPUTE = ON)
;

詳細については、「ALTER INDEX (Transact-SQL)」を参照してください。For more information, see ALTER INDEX (Transact-SQL).

インデックスと統計の自動管理Automatic index and statistics management

Adaptive Index Defrag のようなソリューションを活用し、1 つまたは複数のデータベースに対するインデックスの最適化と統計更新を自動管理します。Leverage solutions such as Adaptive Index Defrag to automatically manage index defragmentation and statistics updates for one or more databases. このプロシージャでは、断片化レベルやその他のパラメーターに基づいてインデックスを再構築または再構成するか、線形しきい値で統計を更新するかが自動的に選択されます。This procedure automatically chooses whether to rebuild or reorganize an index according to its fragmentation level, amongst other parameters, and update statistics with a linear threshold.

行ストア インデックスの再構築に固有の注意点Considerations specific to rebuilding rowstore indexes

非クラスター化インデックス レコードに含まれる物理識別子または論理識別子を変更する必要がある場合に、クラスター化インデックスを再構築すると、クラスター化キーを参照する非クラスター化インデックスが自動的に再構築されます。Rebuilding a clustered index automatically rebuilds any nonclustered index that reference the clustering key, if the physical or logical identifiers contained in the nonclustered index records need to change.

以下のシナリオでは、テーブル上のすべての行ストア非クラスター化インデックスを、強制的に自動再構築します。The following scenarios force all rowstore nonclustered indexes on a table to be automatically rebuilt:

  • テーブルに対するクラスター化インデックスの作成Creating a clustered index on a table
  • テーブルがヒープとして格納される原因となる、クラスター化インデックスの削除Removing a clustered index, which causes the table to be stored as a heap
  • クラスター化キーの変更による列の挿入または除外Changing the clustering key to include or exclude columns

以下のシナリオでは、すべての行ストア非クラスター化インデックスをテーブル上で自動的に再構築する必要はありません。The following scenarios do not require all rowstore nonclustered indexes to be automatically rebuilt on a table:

  • 一意のクラスター化インデックスの再構築Rebuilding a unique clustered index
  • 一意でないクラスター化インデックスの再構築Rebuilding a non-unique clustered index
  • クラスター化インデックスへのパーティション構成の適用、クラスター化インデックスの別のファイルグループへの移動など、インデックス スキーマの変更Changing the index schema, such as applying a partitioning scheme to a clustered index or moving the clustered index to a different filegroup

重要

インデックスのあるファイル グループがオフラインであるか、または読み取り専用に設定されている場合、インデックスを再構成または再構築することはできません。An index cannot be reorganized or rebuilt if the filegroup in which it is located is offline or set to read-only. キーワード ALL を指定した場合で、1 つ以上のインデックスがオフラインまたは読み取り専用のファイル グループにある場合、ステートメントは失敗します。When the keyword ALL is specified and one or more indexes are in an offline or read-only filegroup, the statement fails.

インデックスの再構築が行われている間、物理メディアにはインデックスのコピーを 2 つ格納するのに十分な領域が必要です。While an index rebuild occurs, the physical media must have enough space to store two copies of the index. 再構築が完了すると、データベース エンジンDatabase Engine によって元のインデックスが削除されます。When the rebuild is finished, the データベース エンジンDatabase Engine deletes the original index.

ALTER INDEX ステートメントで ALL を指定すると、テーブル上のクラスター化と非クラスター化の両方のリレーショナル インデックスと XML インデックスが再構成されます。When ALL is specified with the ALTER INDEX statement, relational indexes, both clustered and nonclustered, and XML indexes on the table are reorganized.

列ストア インデックスの再構築に固有の注意点Considerations specific to rebuilding a columnstore index

列ストアインデックスを再構築するときは、データベース エンジンDatabase Engine によって元の列ストア インデックスから、デルタ ストアを含むすべてのデータが読み取られます。When rebuilding a columnstore index, the データベース エンジンDatabase Engine reads all data from the original columnstore index, including the delta store. データを新しい行グループに結合し、行グループを列ストアに圧縮します。It combines the data into new rowgroups, and compresses the rowgroups into the columnstore. データベース エンジンDatabase Engine では、テーブルから論理的に削除された行を物理的に削除することで、列ストアがデフラグされます。The データベース エンジンDatabase Engine defragments the columnstore by physically deleting rows that have been logically deleted from the table. 削除されたバイトはディスクで再利用されます。The deleted bytes are reclaimed on the disk.

注意

Management StudioManagement Studio を使用して列ストア インデックスを再構成すると、COMPRESSED 行グループが結合されますが、すべての行グループが列ストアに強制的に圧縮されることはありません。Reorganizing a columnstore index using Management StudioManagement Studio will combine COMPRESSED rowgroups together, but does not force all rowgroups to be compressed into the columnstore. CLOSED の行グループは圧縮されますが、OPEN の行グループは列ストアに圧縮されません。CLOSED rowgroups will be compressed but OPEN rowgroups will not be compressed into the columnstore. すべての行グループを強制的に圧縮するには、以下Transact-SQLTransact-SQL の例を使用してください。To forcibly compress all rowgroups, use the Transact-SQLTransact-SQL example below.

注意

SQL Server 2019 (15.x)SQL Server 2019 (15.x) 以降、組ムーバーは、内部しきい値によってしばらくの間存在していると判断された小さな OPEN デルタ行グループを自動的に圧縮するか、多数の行が削除されている COMPRESSED 行グループをマージするバックグラウンド マージ タスクによってサポートされています。Starting with SQL Server 2019 (15.x)SQL Server 2019 (15.x), the tuple-mover is helped by a background merge task that automatically compresses smaller OPEN delta rowgroups that have existed for some time as determined by an internal threshold, or merges COMPRESSED rowgroups from where a large number of rows has been deleted. これにより、時間の経過とともに、列ストア インデックスの品質が向上します。This improves the columnstore index quality over time.
列ストアの用語と概念の詳細については、「列ストア インデックス: 概要) の下のステートメントを右クリックします。For more information about columnstore terms and concepts, see Columnstore indexes: Overview.

テーブル全体ではなくパーティションを再構築するRebuild a partition instead of the entire table

  • インデックスが大きいとテーブル全体の再構築には時間がかかり、再構築中にインデックスの追加コピーを格納するために十分なディスク領域が必要です。Rebuilding the entire table takes a long time if the index is large, and it requires enough disk space to store an additional copy of the index during the rebuild. 通常は、最近使用されたパーティションを再構築するだけで済みます。Usually it is only necessary to rebuild the most recently used partition.
  • パーティション テーブルでは、columnstore インデックス全体を再構築する必要はありません。断片化は最近変更されたパーティションのみで起きる可能性が高いためです。For partitioned tables, you do not need to rebuild the entire columnstore index because fragmentation is likely to occur in only the partitions that have been modified recently. ファクト テーブルや大きなディメンション テーブルは通常、テーブルのチャンク上でバックアップおよび管理を行うためにパーティション分割されます。Fact tables and large dimension tables are usually partitioned in order to perform backup and management operations on chunks of the table.

負荷の高い DML 操作後にパーティションを再構築するRebuild a partition after heavy DML operations

パーティションを再構築すると、パーティションの断片化が解消され、ディスク ストレージが減少します。Rebuilding a partition defragments the partition and reduces disk storage. 再構築すると、削除のマークが付けられた列ストアからすべての行が削除され、すべての行グループがデルタ ストアから列ストアに移動されます。Rebuilding deletes all rows from the columnstore that are marked for deletion and moves all rowgroups from the delta store into the columnstore. デルタ ストアには、100 万行未満の複数の行グループが存在する場合があります。There can be multiple rowgroups in the delta store that have less than one million rows.

データを読み込んだ後に、パーティションを再構築するRebuild a partition after loading data

データを読み込んだ後でパーティションを再構築すると、すべてのデータが列ストアに格納されます。Rebuilding a partition after loading date ensures all data is stored in the columnstore. 同時実行のプロセスでそれぞれ 100,000 未満の行が同じパーティションに同時に読み込まれた場合、パーティションに複数のデルタストアが含まれることがあります。When concurrent processes each load less than 100,000 rows into the same partition at the same time, the partition can end up with multiple delta stores. 再構築すると、すべてのデルタ ストア行が列ストアに移動されます。Rebuilding moves all delta store rows into the columnstore.

列ストア インデックスの再構成に固有の注意点Considerations specific to reorganizing a columnstore index

列ストア インデックスを再構成すると、データベース エンジンDatabase Engine によって、CLOSED の各デルタ行グループが、圧縮された行グループとして列ストアに圧縮されます。When reorganizing a columnstore index, the データベース エンジンDatabase Engine compresses each CLOSED delta rowgroup into the columnstore as a compressed rowgroup. SQL Server 2016 (13.x)SQL Server 2016 (13.x) 以降および Azure SQL データベースAzure SQL DatabaseREORGANIZE コマンドでは、次の追加のデフラグ最適化がオンラインで実行されます。Starting with SQL Server 2016 (13.x)SQL Server 2016 (13.x) and in Azure SQL データベースAzure SQL Database, the REORGANIZE command performs the following additional defragmentation optimizations online:

  • 行の 10% 以上が論理的に削除されたとき、行グループから行を物理的に削除します。Physically removes rows from a rowgroup when 10% or more of the rows have been logically deleted. 削除されたバイトは、物理メディア上で解放されます。The deleted bytes are reclaimed on the physical media. たとえば、100 万行から成る圧縮された行グループで 10 万行が論理的に削除された場合、SQL ServerSQL Server は、削除された行を物理的に削除し、90 万行を含む行グループを圧縮し直します。For example, if a compressed row group of 1 million rows has 100K rows deleted, SQL ServerSQL Server will remove the deleted rows and recompress the rowgroup with 900k rows. 削除された行を解放することで、記憶域が節約されます。It saves on the storage by removing deleted rows.

  • 1 つまたは複数の圧縮された行グループを結合して、行グループあたりの行数を最大で 1,048,576 行まで増やすことができます。Combines one or more compressed rowgroups to increase rows per rowgroup up to the maximum of 1,048,576 rows. たとえば、102,400 行のバッチを 5 つ一括でインポートした場合は、5 つの圧縮された行グループが得られます。For example, if you bulk import 5 batches of 102,400 rows you will get 5 compressed rowgroups. REORGANIZE を実行すると、これらの行グループは圧縮された 1 つの行グループにマージされ、そのサイズは 512,000 行となります。If you run REORGANIZE, these rowgroups will get merged into 1 compressed rowgroup of size 512,000 rows. この処理は、ディクショナリ サイズまたはメモリに関する制限が存在していないことを前提としています。This assumes there were no dictionary size or memory limitations.

  • 行グループの 10% 以上の行が論理的に削除された場合、データベース エンジンDatabase Engine ではこのような行グループを 1 つまたは複数の行グループと結合することが試みられます。For rowgroups in which 10% or more of the rows have been logically deleted, the データベース エンジンDatabase Engine tries to combine this rowgroup with one or more rowgroups. たとえば、行グループ 1 は 500,000 行の圧縮された行グループであり、行グループ 21 は最大 1,048, 576 行の圧縮された行グループであるとします。For example, rowgroup 1 is compressed with 500,000 rows and rowgroup 21 is compressed with the maximum of 1,048,576 rows. 行グループ 21 は行の 60% が削除され、残りが 409,830 行になっています。Rowgroup 21 has 60% of the rows deleted which leaves 409,830 rows. データベース エンジンDatabase Engine では、優先的にこの 2 つの行グループが結合されて、909,830 行の新しい行グループが圧縮されます。The データベース エンジンDatabase Engine favors combining these two rowgroups to compress a new rowgroup that has 909,830 rows.

データの読み込みが実行された後、デルタ ストアには複数の小さな行グループが含まれることがあります。After performing data loads, you can have multiple small rowgroups in the delta store. ALTER INDEX REORGANIZE を使用して、すべての行グループを列ストアに強制的に移動し、これらの行グループを、より行数の多い少数の行グループへと結合することができます。You can use ALTER INDEX REORGANIZE to force all of the rowgroups into the columnstore, and then to combine the rowgroups into fewer rowgroups with more rows. 再構成操作では、列ストアから削除された行も削除されます。The reorganize operation will also remove rows that have been deleted from the columnstore.

制限事項と制約事項Limitations and restrictions

128 エクステントを超える行ストア インデックスは、論理フェーズと物理フェーズの 2 つの独立したフェーズで再構築されます。Rowstore indexes with more than 128 extents are rebuilt in two separate phases: logical and physical. 論理フェーズでは、インデックスによって使用されている既存のアロケーション ユニットが、割り当て解除に設定されます。その後、データ行がコピーされ、並べ替えられてから、再構築されたインデックスを格納するために作成された新しいアロケーション ユニットに移動されます。In the logical phase, the existing allocation units used by the index are marked for deallocation, the data rows are copied and sorted, then moved to new allocation units created to store the rebuilt index. 物理フェーズでは、バックグラウンドで行われる短いトランザクションで、以前に割り当て解除に設定されたアロケーション ユニットが物理的に削除され、ロックの必要はあまり多くありません。In the physical phase, the allocation units previously marked for deallocation are physically dropped in short transactions that happen in the background, and do not require many locks. エクステントの詳細については、「ページとエクステントのアーキテクチャ ガイド」を参照してください。For more information about extents, see Pages and Extents Architecture Guide.

この操作では、ファイル グループ内の他のファイルではなく、同じファイル上に一時的な作業ページを割り当てなければならないため、ALTER INDEX REORGANIZE ステートメントには、使用可能な領域があるインデックスを含むデータ ファイルが必要です。The ALTER INDEX REORGANIZE statement requires the data file containing the index to have space available, because the operation can only allocate temporary work pages on the same file, not in another file within the filegroup. そのため、ファイル グループに空き容量があるとしても、エラー 1105 が発生することがあります。Could not allocate space for object '###' in database '###' because the '###' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.So although the filegroup might have free pages available, the user can still encounter error 1105: Could not allocate space for object '###' in database '###' because the '###' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.

警告

固定されていないインデックスをパーティションが 1, 000 個以上あるテーブルに作成または再構築することは可能ですが、サポートされていません。Creating and rebuilding nonaligned indexes on a table with more than 1,000 partitions is possible, but is not supported. このような操作を行うと、操作中にパフォーマンスが低下したりメモリが過度に消費される可能性があります。Doing so may cause degraded performance or excessive memory consumption during these operations. パーティションの数が 1,000 個を超えた場合は、固定されたインデックスのみを使用することをお勧めします。Microsoft recommends using only aligned indexes when the number of partitions exceed 1,000.

インデックスのあるファイル グループが オフライン であるか、または 読み取り専用 に設定されている場合、インデックスを再構成または再構築することはできません。An index cannot be reorganized or rebuilt if the filegroup in which it is located is offline or set to read-only. キーワード ALL を指定した場合で、1 つ以上のインデックスがオフラインまたは読み取り専用のファイル グループにある場合、ステートメントは失敗します。When the keyword ALL is specified and one or more indexes are in an offline or read-only filegroup, the statement fails.

[統計] :Statistics:

  • インデックスが 作成 または 再構築 されるとき、テーブル内のすべての行がスキャンされて、統計が作成または更新されます。When an index is created or rebuilt, statistics are created or updated by scanning all the rows in the table. ただし、SQL Server 2012 (11.x)SQL Server 2012 (11.x) 以降では、パーティション インデックスが作成または再構築されたとき、テーブル内のすべての行をスキャンして統計が作成または更新されることはありません。However, starting with SQL Server 2012 (11.x)SQL Server 2012 (11.x), statistics are not created or updated by scanning all the rows in the table when a partitioned index is created or rebuilt. 代わりに、クエリ オプティマイザーによって既定のサンプリング アルゴリズムを使用してこれらの統計が生成されます。Instead, the Query Optimizer uses the default sampling algorithm to generate these statistics. テーブル内のすべての行をスキャンしてパーティション インデックスの統計を作成するには、FULLSCAN 句で CREATE STATISTICS または UPDATE STATISTICS を使用します。To obtain statistics on partitioned indexes by scanning all the rows in the table, use CREATE STATISTICS or UPDATE STATISTICS with the FULLSCAN clause.

  • インデックスが 再構成 されるとき、統計は更新されません。When an index is reorganized, statistics are not updated.

ALLOW_PAGE_LOCKS を OFF に設定した場合、インデックスを再構成することはできません。An index cannot be reorganized when ALLOW_PAGE_LOCKS is set to OFF.

SQL Server 2017 (14.x)SQL Server 2017 (14.x) までは、クラスター化列ストア インデックスの再構築はオフライン操作です。Up to SQL Server 2017 (14.x)SQL Server 2017 (14.x), rebuilding a clustered columnstore index is an offline operation. データベース エンジンでは、再構築が行われている間、テーブルまたはパーティションを排他的にロックする必要があります。The database engine has to acquire an exclusive lock on the table or partition while the rebuild occurs. NOLOCK、READ COMMITTED スナップショット分離 (RCSI)、またはスナップショット分離を使用しているときでも、再構築の間は、データはオフラインになり使用できません。The data is offline and unavailable during the rebuild even when using NOLOCK, Read-committed Snapshot Isolation (RCSI), or Snapshot Isolation. SQL Server 2019 (15.x)SQL Server 2019 (15.x) 以降では、ONLINE = ON オプションを使用してクラスター化列ストア インデックスを再構築できます。Starting with SQL Server 2019 (15.x)SQL Server 2019 (15.x), a clustered columnstore index can be rebuilt using the ONLINE = ON option.

順序付けされたクラスター化列ストア インデックスを使用する Azure Synapse Analytics (旧称 Azure Synapse Analytics (SQL Data Warehouse)Azure Synapse Analytics (SQL Data Warehouse)) テーブルの場合、ALTER INDEX REBUILD では TempDB を使用してデータが再度並べ替えられます。For an Azure Synapse Analytics (formerly Azure Synapse Analytics (SQL Data Warehouse)Azure Synapse Analytics (SQL Data Warehouse)) table with an ordered clustered columnstore index, ALTER INDEX REBUILD will re-sort the data using TempDB. 再構築操作中に TempDB を監視します。Monitor TempDB during rebuild operations. TempDB 領域がさらに必要な場合は、データ ウェアハウスをスケールアップします。If you need more TempDB space, scale up the data warehouse. インデックスの再構築が完了したら、スケール ダウンで戻します。Scale back down once the index rebuild is complete.

順序付けされたクラスター化列ストア インデックスを使用する Azure Synapse Analytics (旧称 Azure Synapse Analytics (SQL Data Warehouse)Azure Synapse Analytics (SQL Data Warehouse)) テーブルの場合、ALTER INDEX REORGANIZE によってデータが再度並べ替えられることはありません。For an Azure Synapse Analytics (formerly Azure Synapse Analytics (SQL Data Warehouse)Azure Synapse Analytics (SQL Data Warehouse)) table with an ordered clustered columnstore index, ALTER INDEX REORGANIZE does not re-sort the data. データを再度並べ替えるには ALTER INDEX REBUILD を使用します。To resort the data use ALTER INDEX REBUILD.

INDEX REBUILD を使用してハードウェア障害から復旧するUsing INDEX REBUILD to recover from hardware failures

以前のバージョンの SQL ServerSQL Server では、行ストアの非クラスター化インデックスを再構築することで、ハードウェア障害により発生した不一致を修正できる場合がありました。In earlier versions of SQL ServerSQL Server, you could sometimes rebuild a rowstore nonclustered index to correct inconsistencies caused by hardware failures. SQL Server 2008SQL Server 2008 以降でも、非クラスター化インデックスをオフラインで再構築することで、インデックスとクラスター化インデックス間の不一致を修正できます。Starting with SQL Server 2008SQL Server 2008, you may still be able to repair such inconsistencies between the index and the clustered index by rebuilding a nonclustered index offline. オンラインでインデックスを再構築する場合、既存の非クラスター化インデックスを基に再構築が行われるので、不一致を維持してしまい非クラスター化インデックスの不一致を修復できません。However, you cannot repair nonclustered index inconsistencies by rebuilding the index online, because the online rebuild mechanism uses the existing nonclustered index as the basis for the rebuild and thus persist the inconsistency. オフラインでインデックスを再構築すると、強制的にクラスター化インデックス (ヒープ) のスキャンがなされ、不一致が解消されることがあります。Rebuilding the index offline can sometimes force a scan of the clustered index (or heap) and so remove the inconsistency. クラスター化インデックスからの再構築を保証するため、非クラスター化インデックスを削除および再作成します。To assure a rebuild from the clustered index, drop and recreate the nonclustered index. 不一致を解消する場合、以前のバージョンと同様に影響を受けたデータをバックアップから復元することをお勧めします。ただし、非クラスター化インデックスをオフラインで再構築しても、インデックスの不一致を修復できます。As with earlier versions, we recommend recovering from inconsistencies by restoring the affected data from a backup; however, you may be able to repair the index inconsistencies by rebuilding the nonclustered index offline. 詳細については、「DBCC CHECKDB (Transact-SQL)」を参照してください。For more information, see DBCC CHECKDB (Transact-SQL).

関連項目See also