web-dev-qa-db-ja.com

インデックスを自動的に再構築するようにAzure SQLを設定する方法は？

オンプレミスのSQLデータベースでは、あまり使用されていないときに、インデックスを時々再構築するためのメンテナンスプランが用意されています。

Azure SQL DBで設定するにはどうすればよいですか？

P.S：以前に試しましたが、そのためのオプションが見つからなかったので、 この投稿 を読んで試してみるまで、彼らはそれを自動的にやっていると思いました：

SELECT
 DB_NAME() AS DBName
 ,OBJECT_NAME(ps.object_id) AS TableName
 ,i.name AS IndexName
 ,ips.index_type_desc
 ,ips.avg_fragmentation_in_percent
 FROM sys.dm_db_partition_stats ps
 INNER JOIN sys.indexes i
 ON ps.object_id = i.object_id
 AND ps.index_id = i.index_id
 CROSS APPLY sys.dm_db_index_physical_stats(DB_ID(), ps.object_id, ps.index_id, null, 'LIMITED') ips
 ORDER BY ps.object_id, ps.index_id

そして、メンテナンスが必要なインデックスがあることがわかりました （enter image description here

sql-serverazureazure-sql-databaseazure-sql-server
10
Ashkan Sirous

ほとんどの人は、SQL Azureでインデックスを再構築することをまったく考慮する必要がないことを指摘します。はい、B +ツリーインデックスは断片化される可能性があります。また、これにより、完全にチューニングされたインデックスと比較して、スペースのオーバーヘッドとCPUのオーバーヘッドが発生する可能性があります。そのため、お客様と協力してインデックスを再構築するシナリオがいくつかあります。 （主なシナリオは、現在のアーキテクチャによりディスク領域がSQL Azureである程度制限されているため、現在顧客が領域を使い果たす可能性がある場合です）。したがって、データベースを管理するためにSQL Serverモデルを使用することは「間違った」ことではありませんが、努力する価値がある場合とそうでない場合があることを検討してください。

（インデックスの再構築が必要になった場合は、他の投稿者がここに投稿したモデルを使用することを歓迎します。これらは通常、タスクをスクリプト化するのに適したモデルです。SQLAzureマネージドインスタンスは、必要に応じて、メンテナンス操作をスクリプト化するジョブを作成します）。

インデックスの再構築の候補者になる可能性があるかどうかを判断するのに役立ついくつかの詳細を次に示します。

  • 参照したリンクは2013年の投稿からのものです。SQLAzureのアーキテクチャは、その投稿後に完全にやり直されました。具体的には、ハードウェアアーキテクチャは、ローカルの回転ディスクに基づいたモデルから、ローカルSSDに基づいたモデルに移行しました（ほとんどの場合）。そのため、元の投稿のガイダンスは古くなっています。
  • 現在のアーキテクチャでは、断片化されたインデックスでスペースが不足する可能性があります。インデックスを再構築するか、より大きなディスク容量の割り当てをサポートするしばらくの間、より大きな予約サイズに移動する（より多くの費用がかかる）オプションがあります。 [マシン上のローカルSSDスペースは限られているため、予約サイズはおおよそマシンの割合にリンクされています。より大きな/より多くのドライブを備えた新しいハードウェアを入手すると、より多くのスケールアップオプションがあります。
  • ランダムなIOのコストはシーケンシャルなものよりも高くないため、回転ディスクと比較してSSDの断片化の影響は比較的小さいです。B+ツリーの中間ページをさらに歩くCPUオーバーヘッドは控えめです。 。私は通常、平均的なケースでおそらく最大5-20％のオーバーヘッドを見ました（これは、再構築時にワークロードに大きな影響を与える定期的な再構築を正当化する場合もしない場合もあります）
  • クエリストア（SQL Azureで既定で有効になっている）を使用している場合、特定のインデックスの再構築がパフォーマンスを目に見える形で助けているかどうかを評価できます。これは、インデックスの再構築操作を自分で構築して管理するのに時間をかける前に、ワークロードが改善するかどうかを確認するテストとして実行できます。
  • 現在、ユーザーワークロードに対するSQL Azure内のデータベース内リソースガバナンスはありません。そのため、インデックスの再構築を開始すると、大量のリソースを消費し、メインのワークロードに影響を与える可能性があります。もちろん、時間外に行うように時間を調整することもできますが、世界中の多くの顧客がいるアプリケーションでは、これは不可能な場合があります。
  • さらに、多くの顧客が「統計を更新したい」ためにインデックス再構築ジョブを持っていることに注意します。統計を再構築するためだけにインデックスを再構築する必要はありません。最近のSQL ServerとSQL Azureでは、統計更新のアルゴリズムがより大きなテーブルでより積極的になり、顧客が最近挿入されたデータをクエリする場合のカーディナリティーを推定するモデル（最後の統計更新以降）が後の互換性で変更されましたレベル。そのため、多くの場合、顧客は手動で統計情報を更新する必要さえありません。
  • 最後に、統計が古くなっていることの影響は、歴史的にはプラン選択の回帰が発生することでした。繰り返されるクエリの場合、クエリストアに対する自動チューニング機能の導入により、この影響の多くが軽減されました（以前の計画と比較してクエリパフォーマンスの大幅な低下に気付いた場合、以前の計画を強制します）。

私が顧客に提供する公式の推奨事項は、実際のニーズを実証しているティア1アプリ（費用を上回るメリット）またはSaaS弾性プールまたはマルチテナントデータベース設計の多くのデータベース/顧客のワークロードを調整しようとしているISVで、非常に大きなデータベースでCOGSを削減したり、ディスク領域の不足（前述）を回避したりできるようにします。プラットフォーム上で最大の顧客である場合、時々顧客と手動でインデックス操作を行うことで価値が見られますが、この種の操作を「ちょうど」行う通常の仕事を必要としないことがよくあります。 SQLチームの意図は、これを気にする必要はまったくなく、代わりにアプリに集中できることです。もちろん、自動メカニズムに追加または改善できるものは常にあります。個々の顧客データベースに旧姓がある可能性を完全に許容しますこのようなアクションの場合。私が言及した事例を超えて自分自身を見たことはありませんし、それらでさえ問題になることはめったにありません。

これにより、プラットフォームでこれがまだ行われていない理由を理解するためのコンテキストが得られることを願っています。他の差し迫ったニーズと比較して、今日のサービスにある顧客データベースの大部分にとっては問題ではありませんでした。もちろん、各計画サイクルを構築するために必要なもののリストを再検討し、定期的にこのような機会を検討しています。

幸運-ここであなたの結果が何であれ、これがあなたが正しい選択をするのに役立つことを願っています。

よろしくお願いいたします。ConorCunningham Architect、SQL

14
Conor Cunningham MSFT

ここで説明するように、Azure Automationを使用してインデックスメンテナンスタスクをスケジュールできます。 Azure Automationを使用したSQLデータベースインデックスの再構築

以下の手順：

1） https://portal.Azure.com に移動し、[新規]> [管理]> [自動化アカウント]を選択して、自動化アカウントを用意します

enter image description here

2）Automationアカウントを作成した後、詳細を開き、Runbooks> Browse Galleryをクリックします

enter image description here

検索ボックスに「インデックス」という単語とRunbook「Azureデータベースのフラグメンテーションが多い場合のインデックステーブル」を入力します。

enter image description here

4）Runbookの作成者は、SC Microsoftの自動化製品チームです。[インポート]をクリックします。

enter image description here

5）Runbookのインポート後、データベースの資格情報をアセットに追加しましょう。 [資産]> [認証情報]をクリックし、[認証情報を追加…]ボタンをクリックします。 enter image description here

6）資格情報名（Runbookで後で使用される）、データベースユーザー名、およびパスワードを設定します。

enter image description here

7）Runbookを再度クリックし、リストから「Update-SQLIndexRunbook」を選択して、「編集…」ボタンをクリックします。実行されるPowerShellスクリプトを確認できます。

enter image description here

8）スクリプトをテストする場合は、[テストペイン]ボタンをクリックするだけで、テストウィンドウが開きます。必要なパラメーターを導入し、[開始]をクリックしてインデックスの再構築を実行します。エラーが発生した場合、エラーは結果ウィンドウに記録されます。データベースと他のパラメータによっては、完了するまでに時間がかかる場合があることに注意してください。

enter image description here

9）エディターに戻り、「発行」ボタンをクリックしてRunbookを有効にします。 「開始」をクリックすると、パラメータを要求するウィンドウが表示されます。しかし、このタスクをスケジュールしたいので、代わりに「スケジュール」ボタンをクリックします。

enter image description here

10）[スケジュール]リンクをクリックして、Runbookの新しいスケジュールを作成します。週に1回指定しましたが、それはワークロードとインデックスが時間の経過とともに断片化をどのように増やすかによって異なります。ニーズに基づいて、実行の間に最初のクエリを実行して、スケジュールを調整する必要があります。

enter image description here

11）次に、パラメーターと実行設定を紹介します。

enter image description here

注：異なる設定で異なるスケジュール、つまり特定のテーブルに特定のスケジュールを設定して遊ぶことができます。

これで完了です。必要に応じてロギング設定を忘れずに変更してください。

enter image description here

10
Alberto Morillo

Azure Automationは優れており、価格もごくわずかです。

enter image description here

あなたが持っているいくつかの他のオプションは次のとおりです

1.SQL実行タスクを作成し、SQLエージェントを介してスケジュールします。SQL実行タスクには、統計再構築とともにインデックス再構築コードが含まれている必要があります。

2.SQLAZUREへのリンクサーバーを作成し、SQLエージェントジョブを作成することもできます。Azureへのリンクサーバーを作成するには、このSO link： 追加する必要がありますMS Azure SQL Serverへのリンクサーバー

1
TheGameiswar

@ TheGamiswar が推奨されているように、 リンクサーバー を追加してから、次のようなストアドプロシージャを作成します。

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE PROCEDURE [LinkedServerName].[RemoteDB].[dbo].[sp_RebuildReorganizIndexes]   
AS  
BEGIN  
    ALTER INDEX PK_MyTable ON MyTable REBUILD WITH (STATISTICS_NORECOMPUTE = ON, ONLINE=ON);
    ALTER INDEX IX_MyTable ON MyTable REBUILD WITH (STATISTICS_NORECOMPUTE = ON, ONLINE=ON); --Nonclustered index

    ALTER INDEX PK_MyTable ON MyTable REORGANIZE;
    ALTER INDEX IX_MyTable ON MyTable REORGANIZE;
END

次に、リンクサーバーで「SQL Serverエージェント」を使用して、新しいジョブとスケジュールを作成します。

enter image description here

詳細については、 https://docs.Microsoft.com/en-us/sql/ssms/agent/create-a-job?view=sql-server-2017 を参照してください

0
user8128167