1、コーディングされているSelect文を全て、Management Studio のクエリエディタに貼り付ける。
2、ツールバーの「データベース エンジン チューニング アドバイザでのクエリの分析」アイコンをクリックして、「データベース エンジン チューニング アドバイザ」画面を開く。
3、「データベース エンジン チューニング アドバイザ」画面では、クエリエディタに記入したSQLのチューニング設定が初期値として入力済みになっている。
4、必要であれば「チューニング オプション」の内容を変更。
5、ツールバーにある「分析の開始」アイコンをクリックして開始。
6、分析対象のデータベースサイズが小さ過ぎたり、大き過ぎたりすると、「ワークロードを使用しています」タスクでエラーになる。その場合は、「チューニング オプション ⇒ 詳細設定オプション ⇒ 推奨インデックス用の最大領域を定義する」にチェックを付け、実際のDBサイズを入力し、再度「分析の開始」アイコンをクリック。
7、分析結果として登録した方が良いインデックスが、「推奨インデックス」にリストアップされるので、全てのインデックスと統計情報を、クエリエディタ画面で実行する。
8、インデックスと統計情報を追加したら、その対象となったテーブルに、sp_recompile を実行する。
InsertやUpdateが遅くならないようにインデックスを張らない方が良いものはないか気になりますが、実験した結果では、推奨される全てのインデックスを張った場合、InsertやUpdateは少し遅くなりますが、Select文は圧倒的に速くなり、トランザクション全体の処理時間が改善するので、何も考えずに全て適用してしまうのが一番です。
ただ、テラバイトクラスのDBの場合は、1つのインデックスを追加しただけで、100GB消費することは有りますので、ディスク容量は考慮した方が良いです。
また、不要なインデックスが増えないように、6ヶ月以上使われていないインデックスを抽出するSQLを定期的に実施た方が良いです。
それと、インデックスと統計情報を追加しても、ストアドが古い実行プランをキャッシュしたままになっている事がありますので、SQLServerで、IISからのDB処理だけが遅い場合は、ストアドをリコンパイルする こともにも、注意が必要です。
【関連記事】
チューニングアドバイザーによる、インデックスと統計情報の抽出と追加
テーブルの統計情報を、週次で更新
ストアドとファンクションを、日次のジョブで毎朝リコンパイル
IISと関連サービスを、日次で毎朝再起動。
IISと関連サービスからのDB処理が、極端に遅くなるストアド、ファンクションは、使用するインデックスをヒント文で固定する
SQLServerで、IISからのDB処理だけが遅い場合は、ストアドをリコンパイルする
SQLServer 2005 インデックス チューニング ライフサイクル
6ヶ月以上使われていないインデックスを抽出するSQL
最後にコンタクトがあってから数年が経過し、今後もコンタクトは無いと判断された顧客、取引先のリスト。
個人情報保護、データ管理コストの面から、物理的に削除される事が多い。
ダイシン百貨店さんの取り組みの1つに、「年に1回か2回しか売れない商品であっても、顧客が望めば取り揃える」という経営方針があるそうです。
これだけが理由ではないでしょうか、昨今の百貨店不況にあって、地域密着型の百貨店として、とても上手く行っているそうです。
実店舗では面積が限られてしまうので、売れ筋商品に力を入れ、死に筋商品は入れ替えて行く、というのが20世紀後半のマーケティングで推奨されていましたが、それよりも重要なのは顧客満足度だという事を示す一例ではないでしょうか。
20世紀のマーケティングは、人対人のコミュニケーションであっても機械的に生産性を高めて行く事を推奨するものでしたが、それを実店舗に適用してしまった場合、実店舗の良さが無くなってしまうので、ネットショップに勝てる訳ないですね。
21世紀のマーケティングは、新しいテクノロジーを土台にして、人対人のより良いコミュニケーション、顧客満足度の向上を実現できるかどうかが、鍵を握るのではないでしょうか。
最近のコメント