web-dev-qa-db-ja.com

維持されているインデックスが多すぎるためにパフォーマンスが低下していることを確認または反論する方法

インデックスはselectステートメントを改善すると同時に、インデックスにはすべてのupdate/insert/deleteステートメントのメンテナンスコストがかかることがわかっています。

このコストを測定/評価する方法がわかりません。

いくつかのコンテキスト：2000万から8000万の行を持つ、いくつかの挿入/更新に関連する12のキーテーブルがあります。 1秒あたり平均1400トランザクション。

過去数か月の間に、システムのさまざまな部分のパフォーマンスを最適化するために、いくつかのインデックスが追加されました。これは正しく機能しましたが、システムの別の部分で何らかの劣化が見られます。

私はこの理論を持っていますが、それを検証または反論する方法がわかりません。

編集：私は他のいくつかの投稿を読みましたが、ほとんどはSQL Server指向であり、タグ付けされたようにSYBASE ASE 15.7で実行しています

sybasesybaseasesybase-ase-15.7
2
Horaciux

無効にする（Sybase ASEでは実行できない）または削除するインデックスを決定する前に、「システムの別の部分で何らかの劣化が発生する」とはどういう意味かを理解しておく必要があります。劣化の種類と程度についてもっと詳しく知りたいです。

説明のために、「劣化」とは、現在パフォーマンスが低いいくつかのクエリを指していると想定します。その場合、そのクエリを（再）調整するためにどのような作業が行われたかを確認します。使用されている「間違った」インデックスを示すクエリプランはありますか？クエリプランは「間違った」結合順序を示していますか？

はい、パフォーマンスの低下はインデックスの数の増加に関連している可能性がありますが、私が考えているのは、低下はインデックスの更新のオーバーヘッドとは何の関係もないということです（ここでも、「低下」が関連していると仮定します）クエリのパフォーマンスが低下している）ではなく、「不十分な」クエリプランの生成。

クエリを最適化するとき、Sybase ASEは、考えられるすべての列とインデックスで考えられるすべての統計を利用して、考えられるすべてのインデックスを利用して、考えられるすべての結合順序を評価しようとします。最終的な結果として、オプティマイザーには、多数のテーブル、インデックス、および列の統計を参照するクエリに対して実行する作業が[〜＃〜] lot [〜＃〜]あります。

技術的には、Sybase ASEオプティマイザーが大規模で危険なクエリを最適化しようとしているときに1時間オフになる可能性がありますが、オプティマイザーにはいくつかの「スマート」があり、結合/インデックスをすばやく削除できます組み合わせ...実際には、オプティマイザは「最適な」クエリプランを検索できる期間に（構成パラメータを介して）制限があり、（残念な）結果として、非常に大規模で複雑なクエリの場合、オプティマイザは以前にタイムアウトする可能性があります。 「最良の」クエリプランが見つかるため、「この時点までの最良の」（つまり、あまり効率的ではない）クエリプランが残ります。

劣化の問題が突然パフォーマンスが低下し始めた一部のクエリに関連していると仮定すると、インデックスを追加すると、オプティマイザのワークロードが増加し、最適なものが見つかる前にタイムアウトになる可能性があると思います。 'クエリプラン。

このシナリオでは、クエリを（再）調整するためのいくつかのオプションがあります...オプティマイザに「最良の」（または少なくとも「より良い」）クエリプランを見つけるためのより多くの時間を与えます...ヒント（たとえば、インデックスヒント）を提供します、抽象クエリプラン）オプティマイザが考慮しなければならない組み合わせを制限するには...クエリを書き直してオプティマイザのワークロードを簡素化します...

あなたが見ている劣化について他の説明があるかもしれませんが、最初のステップは劣化の種類と程度についての詳細を取得することです...このスレッドでは提供されていないもの...そして（残念ながら）この媒体で詳細に説明するには大きすぎる/複雑になる可能性が高いプロセス。

2
markp-fuso

Sybase ASEは、特定のサンプル期間に実行されたインデックスの更新を確認するために使用できるsp_sysmonを提供しますいくつ。これを制御された環境で使用して、インデックスを設定した場合と設定しない場合の両方で特定のコードセットを実行した場合の影響を確認できます。

例えば：

EXEC dbo.sp_sysmon 'begin_sample'; --start sampling
/*
   execute various pieces of code, client-side, to
   simulate the load you want to test
*/
EXEC dbo.sp_sysmon 'end_sample', indexmgmt;

出力は次のようになります。

================================================== ============================= 
 Sybase Adaptive ServerEnterpriseシステムパフォーマンスレポート
 ==== ================================================== ========================= 
 
サーバーバージョン：Adaptive Server Enterprise/15.7 
実行日：2017年4月19日
統計のクリア日：2017年4月19日09:16:02 
統計のサンプリング日：2017年4月19日09:16:32 
サンプル間隔：00 ：00：30 
サンプルモード：カウンターのリセット
サーバー名：myserver 
 ====================== ================================================== ======= 
 ====================================== ========================================= 
 
インデックス管理
 ---------------- 
 
非クラスター化メンテナンス/秒/ xactカウント合計の％
- ------------------------ ------------ ------------- -------- ---------- 
 Ins/Upd Requiring Maint 0.0 0.0 0 n/a 
 NC NdxMaintの数0.00.0 0 n/a 
 
 Requiring Maint 0.0 0.0 0 n/a 
 NC NdxMaintの数0.00.0 0 n/a 
 
 ClustSplitからのRIDUpd 0.0 0.0 0 n/a 
 NC NdxMaintの数0.00.0 0 n/a 
 
 Upd/Del DOL Req Maint 1.5 2.4 46 n/a 
＃of DOL Ndx Maint 1.9 3.1 58 n/a 
 Avg DOL Ndx Maint/Op n/an/a 1.26087 n/a 
 
ページ分割0.00.0 0 n/a 
 
ページ縮小0.00.0 0 n /a

インデックスS缶/秒/ xactカウント合計の％
 ------------------------- ----------- -------------- ---------- ---------- 
昇順スキャン0.10.2 4 1.1％
 DOL昇順スキャン11.618.3 347 96.7％
降順スキャン0.3 0.4 8 2.2％
 DOL降順スキャン0.00.0 0 0.0％
 ------------ ------------ ---------- 
合計スキャン数12.018.9 359

これにより、実行した作業中に発生したインデックス関連の操作の数を確認できます。信頼できる結果を得ることができるように、他の点では静かなシステムでこれを行うことが不可欠です。インデックスを有効にして、インデックスを削除して、テストを複数回繰り返します。参考までに、Sybase ASE15.7がインデックスの無効化と再有効化をサポートしているとは思いません。

うまくいけば、これはあなたにいくつかの実用的な詳細を得るはずです。

1
Max Vernon