DBパフォーマンスチューニング
DBにかかわらずすべてのシステム速度・処理能力はおおよそ計算がつくはずだが、
その予測値にならず遅延や処理能力低下が出てくるのは資源バランスが悪いか、
または、環境ないしソースの作りこみの時に失策しているのを監査していない事に起因する
場合がほとんどで、各ＤＢ個々のチューニング技術その後である。
そこで最低限やって欲しいチューニングを紹介します、これらだけでほとんどは充足してきました、
最低コストの方法のみです。
最初に検討が必要な個所
１・システム用件に不要なテーブルや不足テーブルが無いか。
２・各テーブルにおける正規化とDBとシステム用件にあった正規化戻しは正しいか
３・OS、DB、HDD、ネットワーク、ミドル、クライアントなどの資源が
システム用件であるレスポンスと処理能力をクリアしているか
４・OS、DBのすべてのパラメータが正しいか
５・テーブルのパラメータが正しいか
６・索引設定とＳＱＬ検索文との整合性が取れているか、漏れや重複や無駄が発生していないか、
高負荷になっていないかなっていたらシステム用件を維持しつつ別の作り方で回避が完了しているか
７・SQL検索文に無駄が無いか、構造化されているか、ＤＢの負荷回避しているか、ネットワーク負荷回避しているか
８・無用なＳＱＬ検索文が無いか、ＳＱＬを多発していないか、同一目的の検索で別の索引を指定していないか
９・サーバサイドでシステムリソースをいたずらに使い果たしていないか
１０・面で処理できることをカラムで処理していないか
実際の現場で出会った一例を示します、印象が強くて記憶している分のみ。番号は上の番号と同一区分
３・LANがパンクっていてコリジョンランプが付く寸前
→サーバＮＩＣへスイッチを取り付け無用なパケットを遮断
３・DBキャッシュがインストール時の最小値付近で運用していた為
HDDランプの点滅が一日中止まらない、かつ、ミラーの一台がヘッドクラッシュして片肺(＝磨耗寿命と推測)
→必要量を算出して物理メモリ増設とDBへの割り当てを量を正しく設定した
HDDランプが１分で一瞬付くか付かないか程度に改善したのでテープバックアップ運用に切り替え片肺のままにした
５・テーブル初期サイズを正しく設定していないためにフラグメンテーションが発生して、なおかつ、
ＤＢ側のテーブルサイズ増加回数制限値に達する直前に気が付いた
→全テーブルの初期サイズ、増加サイズのパラメータを正しく設定した
６・必要なテーブルに索引が無く、不要な索引が多数散乱していた
→全索引をテーブルと対にした
６・ＳＱＬ検索文が最適な索引を使ったり使わなかったりの動作をしていた
→未使用索引を削除して、ＳＱＬ検索文側を正しい索引が常に使われる指定をかけた
７・多段サブクエリにて内側で絞った後に外側で同一の絞りをしていた為に
ＤＢ側のリソースを食いレスポンスが低下していた
→外側で絞る時には内側で絞ったテンポラリテーブルで使えるものは再度絞らない。
(リソースが同一データ内容の別テンポラリテーブルで埋め尽くしてしまう、
コンピュータ言語系からの出身でＤＢエンジン側ＳＱＬ文解析処理のマニュアルを読んで
理解していない人が絞り文をコピーして使う為に発生することが多く、多段の時には
使えない技であることに気が付かないで使っているので大変に滑稽だが笑っていられない
ツールを買ってきて正しくセットすれば最適化可能な場合もあるけど本末転倒な気がする)
１０・詳細設計なりコーディング時にそのまま気にせず作る、完成前後にシステム用件である
レスポンスと処理能力を満たしていない。「ＤＢ使うとこんな程度ですよ」とユーザへ説明する
→ａ．作りこむ前に基本設計ないし詳細設計を再検討する機構を作り設計を修繕しつつ作り込む、
ｂ．理解者がゼロなら２種類のプロトタイプを作り検討して確認して最善策で組み込む、
ｃ．基本設計に問題があり版上げ時に対応が必要であることをユーザへ説明する
などの原因に起因した対策を立てる