sql serverインデックスの断片化と再構築の必要性について
TRANSCRIPT
SQL Server インデックスの仕組みと 断片化、 再構築の必要性について
2012/02/14
インフラグループ 大和屋貴仁
データベースのデータは、
FusionIOなどの物理ディスク
に書き込んで、保存します。
細かいお話の前に……
Chapter. 1 物理ディスクのデータ格納のおさらい
ざっくりとした説明をします。 概念レベルなので、 詳しい人にしたら、間違ってる箇所も。。。
物理ディスクのデータ格納
物理ディスクにデータを格納する時は、
最初に部屋を確保します。
どーんと、広いフロアから人を探すの
大変ですよね？
● Aさん→
↓まず、部屋を確保
●
↑Aさん専用の部屋
物理ディスクのデータ格納
どーんと、広いフロアに部屋を
たくさん作っていきます。
←こんな感じで、新しいデータをいれる度に部屋を確保します。
●
物理ディスクのデータ格納
Aさんが太って、
部屋におさまらない場合は？
● ←はみ出しちゃう！！でも、はみ出したら迷惑。
物理ディスクのデータ格納
Aさんの部屋を
大きくしてあげたら良いよね！
● ↑Aさんの部屋を大きくしてあげれば良い。
物理ディスクのデータ格納
部屋を並べ替えたら、
Aさんの部屋も収納できるけど……
● ←部屋を並べ替えてあげれば、 Aさんの部屋を確保できるけど…… Aさんだけの為に、わざわざ部屋並べ替えるの 手間だよね。
物理ディスクのデータ格納
Aさんを切り刻め！！
物理ディスクのデータ格納
切り刻んだAさんを
あっちこっちにあるAさんの部屋に格納。
物理ディスクのデータ格納
え！？
Aさんが必要！？まじか……。
Aさん切り刻んでるから、まず集めなきゃ。
あっちこちにちらばっているAさんの部屋から Aさんだった残骸を集めて！
物理ディスクのデータ格納
集めたAさんを
くっつけて、Aさん復活！。
●
物理ディスクのデータ格納
ちなみに、
もっとAさんがでっかくなったり、
タイミングによっては……
Aさんの部屋が増えて、 あっちこっちに散らばって、 集めるのが大変！！
物理ディスクのデータ格納
どれぐらい散らばっているかを示すのが
断片化率
と言います。
物理ディスクのデータ格納
デフラグ
って聞いたことありません？
こんな画面でやったデフラグ→
物理ディスクのデータ格納
デフラグって、
切り刻んだAさんをくっつけて、
1個の部屋を用意してあげること。
● そう！ 面倒だから、やらなかった 部屋の並べ替えですね。
Chapter. 2 SQL Serverのインデックスの再構築
ざっくりとした説明をします。 概念レベルなので、 詳しい人にしたら、間違ってる箇所も。。。
データベースのデータは、
FusionIOなどの物理ディスク
に書き込んで、保存します。
もう一度言います
物理ディスクのデータ格納
データはディスクに書き込むんだから、
断片化とは無縁ではありません。
SQL Serverのインデックス
B-Tree式です。
UserID １～１００００
UserID １０００１～
UserID １～５０００
UserID ５００１～１００００
UserID １０００１～１５０００
UserID １５００１～
UserID １～１０００
UserID １００１～２０００
UserID ２００１～３０００
UserID ２００１～２１００
UserID ２１０１～２２００
UserID ２２０１～２３００
UserID
SQL Serverのインデックス
インデックスとディスクが 関係しています。
UserID １～１０００
UserID １００１～２０００
UserID ２００１～３０００
UserID ２００１～２１００
UserID ２１０１～２２００
UserID ２２０１～２３００
インデックスの下に物理ディスクがあります。
SQL Serverのインデックス
で、断片化が進むと……。
UserID ２００１～３０００
UserID ２００１～２１００
UserID ２１０１～２２００
UserID ２２０１～２３００
ユーザID2001～2100を参照するのに あっちこちを見ないと、いけなくなる。
物理ディスクのデータ格納
データベースの中で、
断片化したデータを整理整頓するのが
インデックスの再構築です。
物理ディスク上に散らばっているデータを
整理整頓する作業です。
インデックスの再構築は
物理ディスク上に散らばっているデータを
物理的に整理整頓する作業です。
物理的に並べ替えているので、
途中でキャンセルすると、
元に戻します。 掃除をはじめて20分たったときに、 キャンセルすると 掃除をやめるのではなく、 掃除を始める前の状態にもどします。 キャンセルすると20分とは言いませんが、 案外時間かかることもあります。
テーブルが断片化すると？
• データを参照するのに、 CPU負荷が増えます。 Disk I/Oが増えます。 参照時間が増えます。
• データを更新するのに Diskスペースを確保し、 データを切り刻むので、 CPU負荷が増えます。 Disk I/Oが増えます。 更新時間が増えます。
データの断片化は……
• データの更新、削除をしていけば 必ず断片化します。
• データ量が増えれば、増えるほど、 断片化によるオーバヘッドが増えます。
インデックスの再構築は
• 断片化率が高いほど、再構築に時間が かかります。
• データ量が多いほど、再構築に時間が かかります。
ご利用は計画的に。
DB性能に問題が無い段階でも、 定期的に、 断片化率の高いテーブルのインデックスを
再構築しておくことで、
トータルでのメンテ時間は短縮できます。
IndexView
ツールの準備中。
再構築が必要なインデックスの選定、 再構築時の進捗確認
などが、
しやすいようにツールを作り始めてます。
http://sqlazure.jp/r/sql-server/260/