DBパフォーマンスチューニング

DBにかかわらずすべてのシステム速度・処理能力はおおよそ計算がつくはずだが、

その予測値にならず遅延や処理能力低下が出てくるのは資源バランスが悪いか、

または、環境ないしソースの作りこみの時に失策しているのを監査していない事に起因する

場合がほとんどで、各DB個々のチューニング技術その後である。

そこで最低限やって欲しいチューニングを紹介します、これらだけでほとんどは充足してきました、

最低コストの方法のみです。

最初に検討が必要な個所

1・システム用件に不要なテーブルや不足テーブルが無いか。

2・各テーブルにおける正規化とDBとシステム用件にあった正規化戻しは正しいか

3・OS、DB、HDD、ネットワーク、ミドル、クライアントなどの資源が

システム用件であるレスポンスと処理能力をクリアしているか

4・OS、DBのすべてのパラメータが正しいか

5・テーブルのパラメータが正しいか

6・索引設定とSQL検索文との整合性が取れているか、漏れや重複や無駄が発生していないか、

高負荷になっていないかなっていたらシステム用件を維持しつつ別の作り方で回避が完了しているか

7・SQL検索文に無駄が無いか、構造化されているか、DBの負荷回避しているか、ネットワーク負荷回避しているか

8・無用なSQL検索文が無いか、SQLを多発していないか、同一目的の検索で別の索引を指定していないか

9・サーバサイドでシステムリソースをいたずらに使い果たしていないか

10・面で処理できることをカラムで処理していないか

実際の現場で出会った一例を示します、印象が強くて記憶している分のみ。番号は上の番号と同一区分

3・LANがパンクっていてコリジョンランプが付く寸前

→サーバNICへスイッチを取り付け無用なパケットを遮断

3・DBキャッシュがインストール時の最小値付近で運用していた為

HDDランプの点滅が一日中止まらない、かつ、ミラーの一台がヘッドクラッシュして片肺(=磨耗寿命と推測)

→必要量を算出して物理メモリ増設とDBへの割り当てを量を正しく設定した

HDDランプが1分で一瞬付くか付かないか程度に改善したのでテープバックアップ運用に切り替え片肺のままにした

5・テーブル初期サイズを正しく設定していないためにフラグメンテーションが発生して、なおかつ、

DB側のテーブルサイズ増加回数制限値に達する直前に気が付いた

→全テーブルの初期サイズ、増加サイズのパラメータを正しく設定した

6・必要なテーブルに索引が無く、不要な索引が多数散乱していた

→全索引をテーブルと対にした

6・SQL検索文が最適な索引を使ったり使わなかったりの動作をしていた

→未使用索引を削除して、SQL検索文側を正しい索引が常に使われる指定をかけた

7・多段サブクエリにて内側で絞った後に外側で同一の絞りをしていた為に

DB側のリソースを食いレスポンスが低下していた

→外側で絞る時には内側で絞ったテンポラリテーブルで使えるものは再度絞らない。

(リソースが同一データ内容の別テンポラリテーブルで埋め尽くしてしまう、

コンピュータ言語系からの出身でDBエンジン側SQL文解析処理のマニュアルを読んで

理解していない人が絞り文をコピーして使う為に発生することが多く、多段の時には

使えない技であることに気が付かないで使っているので大変に滑稽だが笑っていられない

ツールを買ってきて正しくセットすれば最適化可能な場合もあるけど本末転倒な気がする)

10・詳細設計なりコーディング時にそのまま気にせず作る、完成前後にシステム用件である

レスポンスと処理能力を満たしていない。「DB使うとこんな程度ですよ」とユーザへ説明する

→a.作りこむ前に基本設計ないし詳細設計を再検討する機構を作り設計を修繕しつつ作り込む、

b.理解者がゼロなら2種類のプロトタイプを作り検討して確認して最善策で組み込む、

c.基本設計に問題があり版上げ時に対応が必要であることをユーザへ説明する

などの原因に起因した対策を立てる


追記:2012.02.08 21:01

テーブル設計が滅茶苦茶な場合も多いと聞きます

1.2次元の実表を作りましょう 2.それを、第5正規化までやらなくても良いのですが、軽めの第3正規化まで

3.データ表入力画面は、無視して良いのですが、データ表示画面・印字シートに合わせて、逆正規化をしましょう

(同一データを複数個所に配置して副問い合わせによる読み出し速度低下を予防)

4.テーブル名、項目名の命名で多く見かけるのは、予約語をそのまま使っている場合があります

リリース前までに、命名規約を作り、確認をすると、問い合わせ文の可読性が上がります

追記:

副問合わせ文、UNIONなどを使い、1画面または1帳票に対して、1問合わせ以内を死守

カーソルは利用しないで、配列の状態で扱いましょう

問合わせしてからループをしないで、SQL文をループで作る手法を考えてください→UNION,IN句の中身→ループよりも副問合わせの方が処理時間短縮や利用資源削減に効果がある事が多いです

存在するとき更新、存在しないとき追加のようなケースでは、表示する際などの読み込みのタイミングで存在しているかを副問合わせを使って状態を得ておくと便利です

追記:

問合わせ速度は索引にあります。40行より大きいなら索引必須。全問合わせに対して適切な索引が存在するか机上で確認が必要です

ヒープに収まらない大きい索引は駄目、サイズを下げるか、ヒープを広げるか、テーブルを分割しましょう

追記:

問合わせを使う場合、中間表のサイズ(列と行)が最小でないという状況は障害です。非最小状態を放置する行為は犯罪です→本来得られる利益を妨害しています


あるあるインターネット・ホームページへ戻る


Valid XHTML 1.1

正当なCSSです!