SAN環境でSQLインデックスを最適化することに利点はありますか？

SQLサーバーはSAN上にあります。多数のOLTPデータベースが含まれており、一部には1m以上のレコードを含むいくつかのテーブルがあります。

私たちは、実行されているオラHallengrenの索引メンテナンススクリプトを毎週、そしてそれは、数時間ごとに実行されます。断片化のしきい値に基づいて、スクリプトはインデックスを再編成または再インデックス化します。インデックスの再作成中にログファイルが膨大になり、ログ配布中に帯域幅が過剰に消費されることが確認されています。

次に、ブレント・オザールからの記事があります。彼はSQLインデックスについて心配するのをやめると言っています。

ハードドライブは、同時にドライブリクエストを行っている他のサーバーと共有されるため、ドライブは常にデータを取得するためにあらゆる場所でジャンプします。インデックスの最適化は、無意味な忙しい作業です。

この質問をググリングすると、さまざまな意見につながりますが、ほとんどが短すぎるか弱すぎると思われる議論でサポートされています。暫定的な計画では、メンテナンススクリプトの断片化のしきい値を調整して、インデックスの再作成よりもはるかに頻繁に再編成するようにします。

最終的な判定は何ですか？毎週のメンテナンスジョブの実行に伴う負担を考慮して、SANでSQLインデックスを最適化することは価値がありますか？

最適化戦略は、ディスクとの間のスキャン速度を向上させるのに役立ちます。

さまざまな意見は、環境の理想的な最適化戦略が多くの異なる要因に依存するためです。また、断片化の潜在的なレイヤーが複数存在します。

データベースがSANに保存されていると言うだけでは十分な情報ではありません。例えば：

• データベースファイルは個別の物理RAIDグループまたは同じRAIDグループに保存されていますか？同じデバイスでアクティブな他のプロセスは何ですか？バックアップファイルもそこにありますか？常に透過的ではないため、SAN管理者にこの情報を要求する必要がある場合があります。

• データベースのアクセスパターンは何ですか？OLTPは一般にランダムアクセスですが、アプリケーションがテーブルスキャンに対応していて、動作を変更できない場合もあります（ISVアプリ）。アプリケーションは、ほとんど読み取りますか、ほとんど書き込みますか、またはその中間ですか？

• 回復/フェールオーバー期間中にパフォーマンスSLAが使用されていますか？

Brentの投稿では、ストレージの巨大なプールが1つあり、すべてがそれを共有すると想定しています。つまり、物理ディスクがアイドル状態になることはほとんどないため、ほとんどのアクセスはランダムです。それがあなたの状況である場合、アドバイスが適用され、ほとんどの部分でそれに同意します。この種の戦略は管理がはるかに簡単ですが、必ずしも（a）環境にあるもの、または（b）環境に最適なソリューションであるとは限りません。

インデックスのメンテナンスが面倒な場合は、あまり積極的に行わないことを検討するか、1週間にわたってコストを償却します（つまり、週に1回の重いメンテナンスではなく、1日1回の軽いメンテナンスを実行します）。

SortInTempdbオプションをオンにして、ユーザーデータベースで発生するログの量を潜在的に減らすこともできます。

理想的には、注意が必要なインデックスのみを再編成/再インデックスする必要があります。そうしないと、リソースを浪費し、他の問題を引き起こす可能性があります。

パフォーマンスのベースラインを確立する必要があり、変更を加えるたびに、パフォーマンスの変化をベースラインと比較して、変更が実装する価値があるかどうかを判断します。

さて、質問はデータベースインデックスについてです。データベースインデックスは、ファイルまたはファイルのセットの構造です。上記の答えを読むと、ファイル内のインデックスではなく、ディスクレベルでの断片化について話していると信じるようになります。これらはまったく別の主題です。

ここでの近視的なアプローチは、インデックスをデフラグまたは再構築すると、内部のデータを取得するときのパフォーマンスが向上し、OLTPデータベースが向上します。答えはイエスです！ただし、ディスクの断片化も要因であることに注意することが重要です。

全体的に最も低い「コスト」ですか？データベースのメンテナンスを行います。2番目に低いコスト、データベースのデタッチ、別の場所への移動、ディスクの再フォーマット、ディスクパーティションの配置のベストプラクティスhttp://msdn.microsoft.com/en-us/library/dd758814.aspx。最後になりましたが、Diskkeeperのようなサードパーティの高度なデフラグツールを使用してください。

これはNTFSタイプのストレージ（Windows OSなど）にのみ推奨されるものであり、これはどの製品も推奨するものではなく、Condusiv Technologiesまたはその子会社と提携しているわけでもありません。