SQL Server2014CTP1でのパーティションレベルのオンラインインデックス操作の調査

SQL Server 2014 CTP1は、ダウンタイムをほとんどまたはまったく必要としない非常に大規模なデータベースをホストしている企業にとって朗報となるオンライン操作オプションの拡張機能を導入しています。

コンテキストを設定するために、オンラインインデックス管理およびインデックスパーティショニング機能にSQL Server 2012 Enterprise Editionを使用していて、パーティション化されたテーブルで次のインデックスの再構築を試みていると想像してください。

ALTER INDEX [PK_FactInternetSales_SalesOrderNumber_SalesOrderLineNumber]
ON [dbo].[FactInternetSales]
REBUILD PARTITION = ALL
WITH (ONLINE= ON);

SQL Server 2012でこれをテストすると、エラーなしですべてのパーティションをオンラインで再構築できます。しかし、すべてのパーティションではなく特定のパーティションを指定したい場合はどうなりますか？

ALTER INDEX [PK_FactInternetSales_SalesOrderNumber_SalesOrderLineNumber]
ON [dbo].[FactInternetSales]
REBUILD PARTITION = 1
WITH (ONLINE= ON);

SQL Server 2012以前でこれを実行しようとすると、次のエラーメッセージが表示されます。

ただし、SQL Server 2014（CTP1以降）以降、オンラインの単一パーティションインデックス操作がサポートされるようになりました。そして、これは確かに、非常に大規模なテーブルメンテナンスのシナリオでは大きな問題であり、実際には、一定期間にわたって全体的なメンテナンスをより小さな部分に分割する必要があります。また、実際にそれを必要とするパーティション（たとえば、特定の断片化レベルを実際に超えるパーティション）に対してのみパーティションレベルのメンテナンスを実行することもできます。

このSQLServer2014 CTP1機能をテストするために、61,847,552行を含み、ShipDate列でパーティション化されたバージョンのFactInternetSalesでAdventureWorksDW2012を使用しました。

PARTITION = ALLを使用して、テーブルのすべてのパーティションをオンラインで再構築します 私のテスト環境では、3分23秒かかりました。全体的な期間に関しては、私のテストはそれほど断片化されていないインデックスを対象としていたため、3分23秒の期間は、いくつかのテストの平均期間を表しています。また、その時点では競合するワークロードが実行されていなかったため、問題のインデックスに対して他の重要なワークロードと競合することなく、オンライン再構築が行われていることにも注意してください。

PARTITION = ALLを使用したオンラインインデックス再構築のクエリ実行プランの形状 次のとおりでした：

すべてのパーティションのオンライン再構築の実行プラン

コンスタントスキャン演算子を除いて、操作が並列対応になっていることに注意してください。クエリ実行プランでは、外部参照の定数スキャンに39行が表示されます。これらの行は、[ストリームの分散]オペレーターに渡され、ネストされたループを駆動しています。

39行の重要性は？次のクエリは、sys.dm_db_partition_statsからの最大パーティション数カウントを検証します 。私のテスト環境では、最大パーティション数の結果は39であり、ConstantScanの実際の行で見たものと一致します。

SELECT MAX([partition_number]) AS [max_partition_number]
FROM [sys].[dm_db_partition_stats]
WHERE [object_id] = OBJECT_ID('FactInternetSales');

これで、前のプランのオンラインインデックス挿入演算子にも気付くでしょう。 ONLINE = ONを削除する ALTER INDEX REBUILDのオプション （オフライン操作にします）、PARTITION = ALLを維持します オプションの場合、唯一の変更は、クエリ実行プランで「オンラインインデックス挿入」の代わりに「インデックス挿入」演算子を使用することでした。また、テストでオンラインと比較して1分9秒の実行期間が示されました。 3分23秒。

次に、代わりに5,678,080行を含む1つのパーティションのオンライン再構築をテストしました（テーブルの合計行数は61,847,552行であることを思い出してください）。このテストでは、全体の所要時間は正確に1分で、次のクエリ実行プランの形をしていました。

単一パーティションのオンライン再構築の実行プラン

最初の観察は、これが一連の計画であるということです。また、元の39から1つのパーティションを選択したと言ったことにも注意してください。ただし、その特定のパーティションは、テーブル全体の行の約9％を表しています。また、私が予想するように、コンスタントスキャンでは39行ではなく1行が表示されることに注意してください。

単一のパーティション、オフライン再構築の期間はどうですか？私のテスト環境では、これはオンライン再構築1分と比較して11秒かかりました。単一パーティションのオフライン再構築のクエリ実行プランの形状は次のとおりです。

単一パーティションのオフライン再構築の実行プラン

コンスタントスキャンまたは関連するネストされたループプロセスがないことに注意してください。また、両方が5,678,080行のクラスター化インデックススキャンを実行している場合でも、このプランには以前のシリアルプランと比較して並列演算子が含まれていることに注意してください。また、単一パーティションのオフライン並列インデックス操作のXMLプランテキストで「partition」のキーワード検索を実行しても、一致は得られませんでした。シリアルプランと比較して、Partitioned =“ true”のオンライン単一パーティションインデックス操作ClusteredIndexScanおよびOnlineIndexInsert物理演算子。

メインの探索に戻る…

1回の実行ですべてではありませんが、いくつかのパーティションを選択できますか？残念ながら違います。

ALTER INDEX およびALTER TABLE コマンドにはPARTITION = ALLがあります 引数を入力してから、PARTITION = <partition number> 引数ですが、1回の再構築操作で複数のパーティションを一覧表示する機能はありません。単一のパーティションをオンラインで再構築できることを嬉しく思い、再構築ごとに1回操作を実行することはそれほど複雑ではないため、これについてあまり大声で不満を言うことはありませんが、期間への累積的な影響は何かでしたさらに探求したかった。

PARTITION = ALLと比較して、39個のパーティションすべてを個別にオンラインで再構築するのにかかる時間 3分23秒の長さ？

オンライン再構築の利点は、インデックス操作中に関連するテーブルまたはインデックスに引き続きアクセスできることです。ただし、そのオンライン操作と引き換えに、オフライン再構築と比較して、再構築のパフォーマンスの優位性が失われます。次に知りたかったのは、PARTITION = ALLに対して1つずつパーティションをオンラインで再構築する方法です。 代替案。

39の個別の再構築操作（一意のパーティションごとに1つの再構築）を実行すると、PARTITION = ALLと比較して、合計実行時間は9分54秒でした。 これには3分23秒かかりました。したがって、断片的なアプローチは、1つのステートメントですべてのパーティションをオンラインで再構築するほど累積的に高速ではないことは明らかです。一度に1つのパーティションを作成できましたが、全体的な利点は、メンテナンスアクティビティを時間の経過とともに分解し、再構築中のオブジェクトにアクセスし続けることができることです。ただし、より短い再構築を探している場合はウィンドウでは、オフラインオプションが依然として最速で、PARTITION = ALLの場合はオンラインがそれに続きます そして最後に、一度に1つのパーティションを実行します。

次の表は、期間の比較を要約したものです。これらのテストは、SQL Server 2014 CTP1と、非常に特殊なテーブルサイズおよびVMゲスト構成に基づいているため、期間自体ではなく、テスト全体の相対的な期間に注意を払ってください。

現在、このテーマについて探求する他の側面もあります。操作がオンラインであるからといって、ターゲットオブジェクトに対してロックがまだ保持されている瞬間（またはそれ以上）がないことを意味するわけではありません。インデックス操作には、オンライン操作のロック動作が引き続きあります。SQLServer 2014には、このためのオプションも用意されています。これについては、別の投稿で説明します。