どちらを信頼しますか？

ベンダーとの長期にわたる問題のトラブルシューティングを行っています。彼らのソフトウェアはフリーズして、週に1〜2回作業を停止する傾向があり、私たちの操作に大きな混乱を引き起こしています。多くのGBのログとDBのバックアップを送信しても、原因を特定できませんでした。最近、彼らは問題が私たちのメンテナンスに関するものであり、おそらくソフトウェアに関するものではないことを示唆し始めています（問題が発生したときに長時間実行されているクエリ、CPU / RAM / IOプレッシャー、またはデッドロックさえないにもかかわらず）。特に彼らは私たちのインデックスが問題であると言っています。

彼らが使用するのにお気に入りのツールはDBCC showcontigですが、これはMSによって廃止されると主張しています。彼らは特にスキャン密度と範囲の断片化にこだわっています。言い訳を取り除くために、<90％のスキャン密度または> 10％の断片化でインデックスを再構築する積極的な夜間メンテナンスを行いました。これにより、スキャン密度トレインからそれらをある程度放棄しましたが、エクステントの断片化に固定されたままです。DBCC showcontigは、数時間前に再構築されたインデックスでも、高度な断片化を示します。以下は、「可能性のある問題」として指摘されたテーブルのdbcc_showcontigおよびsys.dm_db_index_physical_statsの結果です。

DBCC SHOWCONTIG

• スキャンしたページ................................：1222108
• スキャンされた範囲..............................：152964
• エクステントスイッチ..............................：180904
• 平均 エクステントごとのページ..................................：8.0
• スキャン密度[ベストカウント：実際のカウント] .......：84.44％[152764：180905]
• 論理スキャンの断片化..................：3.24％
• エクステントスキャンの断片化...................：35.97％
• 平均 ページあたりの空きバイト..................................：692.5
• 平均 ページ密度（フル）.....................：91.44％

sys.dm_db_index_physical_stats

index_type_desc      alloc_unit_type_desc     Avg_fragmentation_in_percent  page_count

CLUSTERED INDEX       IN_ROW_DATA          3.236803129  1222070

NONCLUSTERED INDEX    IN_ROW_DATA          0.680074642  48230

NONCLUSTERED INDEX    IN_ROW_DATA          0.093237195  48264

NONCLUSTERED INDEX    IN_ROW_DATA          0.03315856   48253

NONCLUSTERED INDEX    IN_ROW_DATA          0.194653248  48291

NONCLUSTERED INDEX    IN_ROW_DATA          0.393480436  58961

NONCLUSTERED INDEX    IN_ROW_DATA          0.23622292   64346

NONCLUSTERED INDEX    IN_ROW_DATA          0.041445623  48256

NONCLUSTERED INDEX    IN_ROW_DATA          0.701172007  59044

NONCLUSTERED INDEX    IN_ROW_DATA          0.216397724  53605

インデックスを気にする必要がありますか？上記のものは非定型ではありません。推奨されるMS DMVはそれが問題ないことを示しているように見えますが、ベンダーはその35.97％のエクステントの断片化に行き詰まっています。これは彼らがソフトウェアの問題のせいにするために必死に何かを見つけようとしているだけだと思う​​が、私が実際の問題を抱えているなら、私はそれを試して修正したい。

彼らのソフトウェアはフリーズして、週に1〜2回作業を停止する傾向があり、私たちの操作に大きな混乱を引き起こしています。多くのGBのログとDBのバックアップを送信しても、原因を特定できませんでした。...特に、彼らは私たちのインデックスが問題であると言っています。

ああ、そうか、このジョークは聞いたことがあると思う。それは次のようなものではありませんか？

アヒルがバーに入る そして、「痛い！」 （冗談です;-)そしてバーテンダーは、「何がありますか？」

アヒルは、「最強のウォッカの3本の指をギミ」と言います。

バーテンダーは、まるで冗談を言っているかのように、「3羽のことを言っているのではないか」と言っています。

アヒルは言った、「ほら、あなたはもうエブリバディラブズレイモンドのヘッドライターではなくなってすみませんが、今日は辛い日だったので、友達になってウォッカで作れますか？」

バーテンダーは「確かに、相棒。ちょっと待って」と言います。

彼はしばらくして戻ってきて、去ったときより明らかに少し幸せではなく、アヒルに言った、「私たちは皆、良いものを使い果たしているようです。残っているのはSkyyだけです。それでうまくいきますか？」

アヒルはカウンターの上にジャンプし、バーテンダーを片方の翼で（どういうわけか）襟でつかんで、もう一方の翼のどこかからナイフを引き出します。 。カット。あなた。」

パニック状態のバーテンダーは、「ねえ、データベースです。遅いです。応答していません」と言います。

アヒル、彼がバーテンダーをただここで終わらせるべきかどうかについて少し混乱している-今ここで-「データベース？一体何について話しているの？」

バーテンダーはすすり泣き、ぼやけてしまいます。「わかりません...ブロックされているのですか？..それは私たちが言うことだけです...インデックスまたは何かを再構築してみてください。他に何を言ったらよいかわからない...サーバーにメモリを追加する必要があるかもしれません...助けになると思いますか？...アプリのコードが高速で、データベースがボトルネックであることを誰もが知っています。ねえ、私は<air-quotes> web-scale </ air-quotes>で通常はオープンソースであり、無料で、TwitterやGoogleなどのNoSQLデータベースについて聞いていました。リレーショナルデータベースはほぼ廃止されているため、Facebookはすべてこれを使用しています。」

そしてそれで、アヒルは彼の決心をした...........

うーん。まあ、私を信じてください、それは元のハンガリー語でとてもおかしいです。

しかし、それでも、システムが遅くなったときに、それがデータベースであると見なすために、なぜ多くの人々が最初に反応したのでしょうか。アプリのコードをひどく書くことができない、または単にいくつかのバグがあるのか​​？遅くなるのは確かにデータベースでしょう。しかし、単純にロック/フリーズしますか？これはデータベース固有の問題ではありません。

これは、外部リソース（ネットワークソケット、ファイルシステムハンドルなど）を適切に解放していないアプリコードの可能性があります。.NETアプリケーションについて話している場合、開発者は、Dispose()アンマネージリソースに関連付けられているオブジェクトを適切に削除することを忘れることがあります。例：SqlConnectionオブジェクトを開く。あなたはそれらの無限の量を取得しません。したがって、データベースを調べたい場合は問題ありません。ただし、次にシステムがフリーズしたときに、次のことを簡単に確認してください。

SELECT sdec.*, '---' AS [---], sdes.*
FROM sys.dm_exec_connections sdec
INNER JOIN sys.dm_exec_sessions sdes
        ON sdes.session_id = sdec.session_id

それらのコードが接続を解放していない場合は、接続が多すぎるかどうか、特にそれらの多くが長いアイドル時間を持っている場合は、かなり明白です。

そして、おそらくこれはすでにチェックされており、質問では明らかにされていません。しかし、それらがインデックスと断片化に非常に集中しているというのは、かなり奇妙な印象を受けます。確かに、パラメーターのスニッフィングの問題があり、ストアドプロシージャが1つ、またはいくつかのストアドプロシージャにかなりの時間を要しますが、アプリケーション全体がロックされますか？特に、実行中のクエリが表示されず、大量のリソースやロック、またはこれが発生したときに時間を費やしていない場合は、購入しません。

それで、「どちらを信頼するか」。確かにこのベンダーではありません;-)。

インデックスを再編成または再構築する必要があるかどうかを確認するには、次のクエリを使用します。

declare @strBD nvarchar(50)

set @strBD = N'Tu_BD';

select table = OBJECT_NAME(object_id, database_id)
    ,index = index_id
    ,Index_Type = index_type_desc
    ,Logic_Frag = avg_fragmentation_in_percent
    ,Action = case 
        when avg_fragmentation_in_percent < 30.0
            then 'ALTER INDEX REORGANIZE'
        else 'ALTER INDEX REBUILD WITH (ONLINE = ON)'
        end
from sys.dm_db_index_physical_stats(DB_ID(@strBD), null, null, null, 'LIMITED');

交換してください@strBDとyour database name。

結果に応じて、https：//msdn.microsoft.com/en-us/library/ms189858（v = sql.110）.aspxに記載されている手順に従ってください。このリンクはSQL Serverの2012バージョン用です。正しく続行するには、適切なバージョンを選択してください。

誰かがコメントしたように、「フラグメンテーションの問題」を超えて、レビューと修正をベンダーに伝える方が良いです。おそらく、SQLプロファイラキャプチャでいくつかのクエリと実行プランを識別します。