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 1~10000
UserID 10001~
UserID 1~5000
UserID 5001~10000
UserID 10001~15000
UserID 15001~
UserID 1~1000
UserID 1001~2000
UserID 2001~3000
UserID 2001~2100
UserID 2101~2200
UserID 2201~2300
UserID
SQL Serverのインデックス
インデックスとディスクが 関係しています。
UserID 1~1000
UserID 1001~2000
UserID 2001~3000
UserID 2001~2100
UserID 2101~2200
UserID 2201~2300
インデックスの下に物理ディスクがあります。
SQL Serverのインデックス
で、断片化が進むと……。
UserID 2001~3000
UserID 2001~2100
UserID 2101~2200
UserID 2201~2300
ユーザID2001~2100を参照するのに あっちこちを見ないと、いけなくなる。
物理ディスクのデータ格納
データベースの中で、
断片化したデータを整理整頓するのが
インデックスの再構築です。
物理ディスク上に散らばっているデータを
整理整頓する作業です。
インデックスの再構築は
物理ディスク上に散らばっているデータを
物理的に整理整頓する作業です。
物理的に並べ替えているので、
途中でキャンセルすると、
元に戻します。 掃除をはじめて20分たったときに、 キャンセルすると 掃除をやめるのではなく、 掃除を始める前の状態にもどします。 キャンセルすると20分とは言いませんが、 案外時間かかることもあります。
テーブルが断片化すると?
• データを参照するのに、 CPU負荷が増えます。 Disk I/Oが増えます。 参照時間が増えます。
• データを更新するのに Diskスペースを確保し、 データを切り刻むので、 CPU負荷が増えます。 Disk I/Oが増えます。 更新時間が増えます。
データの断片化は……
• データの更新、削除をしていけば 必ず断片化します。
• データ量が増えれば、増えるほど、 断片化によるオーバヘッドが増えます。
インデックスの再構築は
• 断片化率が高いほど、再構築に時間が かかります。
• データ量が多いほど、再構築に時間が かかります。
ご利用は計画的に。
DB性能に問題が無い段階でも、 定期的に、 断片化率の高いテーブルのインデックスを
再構築しておくことで、
トータルでのメンテ時間は短縮できます。
IndexView
ツールの準備中。
再構築が必要なインデックスの選定、 再構築時の進捗確認
などが、
しやすいようにツールを作り始めてます。
http://sqlazure.jp/r/sql-server/260/