ちょっと技術的な話。oracle分かる人にしか分からないかも。
最近取引先のシステムを見る機会が何度かあったのだが、昨日すんごいとこ見た。
DBが重くて業務にならないというから、ちょっと中を覗かせてもらったらもうエラいこっちゃ。
・業務ロジックの殆どをファンクション・プロシージャで構成している。なのに、キャッシュヒット率が妙に低い。
・調べてみようと思ったら一回もstatspackが取得されていない。(担当者には、「statspack?syslogならとってあるんですが…」と言われた)
・各テーブルのindexがどういう訳か全列に貼られている。ちなみにindexは全テーブル例外なくその一個だけ(プライマリキーを除けばだが)。
・と思ったら、PKが文字列だったりするテーブルがあちらこちらにある。
・試しにファンクションを一つ二つ見てみたら、なんか普通にクロス結合されまくっていてちょっとくらっとする。
・というか、どう見ても求める列と何の関係もないテーブルがあちこちでjoinされまくっていて更にくらっとする。
・どうもjoin句以下をコピペしてあちこちのファンクションで使いまわしているらしい。違うから！！そこ共通化するべき場所じゃないから！！
・試しにselect部分を引っ張り出してexplainしてみたら、当然の様にTABLE FULL SCANの嵐。レコード数30万とかあるんですけど。
・イヤな予感がして更新系のプロシージャを検索してみたら、for update(nowait)句が一箇所もない。大丈夫なのかコレ。
・当たり前だが、ヒント句などという軟弱なものは一切使われていない。
Rockだ。Rock過ぎる。DBろけんろーる。統計情報の自動更新が止められていた為、最後の統計取得履歴は半年以上前になっていたが、もうそんなことは枝葉の問題として切り捨ててしまいたくなるくらいのRockっぷりである。
その他色々ごたごたと、なんかテーブルも細かく見てみるとまともな正規化がされてなさそうだったが、怖くて見る気が起きなかった。サービスで検証するべきレベルを越えている。速くして欲しかったら金払え。
他にも結構ひどいところ(基幹DBがPostgreSQLで構築されているのに、稼動以来一回もvacuumしてなくてストレージの3分の1がDB構造体とか)見たけど、ここまでのは久々だなあ。
最近思うことなのだが、もしかすると世間には想像以上にトチ狂ったDBが溢れているのかも知れない。世のDBエンジニアの皆様、チャンスかもですよ。
-----------------------------------------------------
(追記 01/20 12:20)
書き忘れた、というか多分言葉が足りなかった。
indexは、全て全列の複合indexでした。
なんでそういうことになったのかは私にも分かりません。
------------------------------------------------------
(追記2 01/20 18:47)
もう一個思い出した。
「○○連番」という見るからに通し連番の列があるのに、何故かそこはプライマリキーになっておらず、「○○名」というvarcharカラムがPKになっているテーブルがあったという点は、世界びっくりDBにノミネートする為に敢えて特筆するべきだと思う。
2009年01月20日
この記事へのトラックバック
[コ] びっくりDB
Excerpt: 「○○連番」という見るからに通し連番の列があるのに、何故かそこはプライマリキーになっておらず、「○○名」というvarcharカラムがPKになっているテーブルがあった 不倒城: どうも世間では、思った..
Weblog: リーマン空間::派遣社員のblog
Tracked: 2009-01-21 09:01
つくらせるからそうなる
なんとなく複数アプリが参照するDBサーバーよりアプリケーションサーバー側に演算させた方が良いような気がするんですが、確証がもてません。
便乗質問ですみません。
個人的にはロジックを全てプロシージャ8000個に詰め込んで動かなくなったプロジェクトを見たことがあります。
もしくは、Oracle10gからのコストベースにお任せ、という話の延長でそういう事態が起きているんですかね？
しんざきさんがあげられたような話はもっと基本的な次元のお話のような気はしますが。
どうなんでしょーか。外注のシステムらしいんですが、外注先の話は聞きませんでした。
>sekiさん
>本文中にあるいようなれビジネスロジックをほとんどストアドプロシージャ（ファンクションプロシージャ）に入れてる例ってよく見るんですが、DBエンジニアの方から見るとどうなんでしょうか？
これに関してはメリットもないことはないんで、一概に言うのは難しいと思います。
ぱっと思いつくメリットは、
・ボトルネックの特定・対応がし易い
・ロジックの更新にシステムの再起動を必要としない
ってことでしょうか。
デメリットは勿論、
・DBの仕事が増えるので、単純にパフォーマンス劣化が早まる
・DBのパフォーマンス劣化がシステム全体の速度低下に直結する
・システムのスケールアウトが難しくなる(DBはサーバ台数の増加によるパフォーマンスアップがやりにくい)
って辺りですよね。
基本的にはデメリットの方が大きいと思いますが、まあこの辺勘案して、後は開発チームの人員構成とかシステムの用途次第ではないかと。前、3人でWebシステム構築することになって、アプリ担当がView部分作るので手一杯だった時、私もビジネスロジックをPLSQLで組みまくったことがあります。
>hidden犬さん
>しんざきさんがあげられたような話はもっと基本的な次元のお話のような気はしますが。
おっしゃる通りだと思います。もうちょっとまともな「ひどいDB」のエントリーを先に書くべきでした。
DBエンジニアというか、エンジニア自体が不足しているのかも。。。
そこまでではないですが、耳が痛いです。
ある程度コードは書けても、DB回りはぼんやりした感じかも･･･もう少しきちんと勉強しないといけないとは思うんですが、なんとなく先延ばしの日々です。
基本的なSQLなんかだけ覚えればあとはなんとなくデータ置き場としては使えてしまうので、『DBエンジニア』がいなくても、ちゃんとできてる"ように"見えるためじゃないかなぁと思います。もちろん必要なんですけど。
うちのPRJ場合、SPに修正が入ると、APサーバのミドルウェア再起動が必要です。
Weblogicです。
アプリの再起動時に、新しいSPを認識してくれるようです。（SPの名称が前後で変わって無くても。）
他のJ2EEコンテナでは違うんですかね？
>PostgreSQLでVACUUMしていないと16億トランザクションぐらいで更新できなくなるので、更新数が少なくってよかったですね(違)
あ、まだそうなんですか。auto vacuumって今ちゃんと動くんでしょうか。
>mizincogrammerさん
>『DBエンジニア』がいなくても、ちゃんとできてる"ように"見えるためじゃないかなぁと思います。
それは確かにそうですよねー。DBは特に、負荷が軽い内はどんなトンデモ設計しても普通に動いてる様に見えるので。
負荷テストの重要性を改めて感じたりもしました。
>hidden犬さん
>うちのPRJ場合、SPに修正が入ると、APサーバのミドルウェア再起動が必要です。
あーどうなんでしょ、多分実装方法か呼び出し方によって変わってくるんですかね。
私の方はTomcat + Apacheなんですが、SPに更新が入っても特にAPサーバを再起動する必要はありませんでした。
WeblogicってtomcatとDBコネクションの取得方法が違うんでしたっけ？