チューニングのこつ

大雑把すぎるかもしれませんが、
アプリケーションチューニング
パラメータチューニング
SQLチューニング

のポイントみたいなのがあれば、教えてください。
よろしくです。

それと、
作成したオブジェクトのシンプルな確認方法も知っておきたいと思います。
オブジェクト作成時に、エラーメッセージが返ってこなかったので「それでよし」ということではなく、

例えば、シノニムを作成したら、スキーマ指定なしで見れるとか、
シーケンスを作成したら、.....
パッケージを作成したら、.....
インデックスを作成したら、など、種類に応じて、妥当な確認方法があると思います。

No.5 回答者： t_nojiri 回答日時： 2006/12/06 00:14

>カーソル

作る時のSELECTの範囲や、データベースのカーソル存在中の参照ロックだろうなとは想像付くんですが、本当にトランザクション中にデータを書き換えられない様に保障しなくてはならないケースだと、カーソルの処理を止めろってアドバイスは無しでは？

#カースバイケースですよね？

No.4 回答者： sajikagen 回答日時： 2006/12/05 13:01

No3へのNo2の補足。

40～100万行くらいのテーブルを６年くらい扱っていて、アプリやSQLの性能には常に気を使う環境にいるのですが、経験的に速いです。

理屈はよくわかりません。
例えば、縦に品目、日付別にならんだ明細数量を、月ごとに横に加算していく処理などが速いです。
ダメSQLに書き直しても速くはなりませんが。

No.3 回答者： t_nojiri 回答日時： 2006/12/05 07:14

>＞アプリケーションチューニング

>ループやカーソルで処理しているところを極力SQL処理にする。

これが、何で効果があるのか補足願えますか？

#oo4oとかに書き換えるなら判りますが、SQLにしたら
逆にオーバーヘッド食うケースの方しか思い浮かばない。

No.2 回答者： sajikagen 回答日時： 2006/12/04 18:45

＞アプリケーションチューニング

ループやカーソルで処理しているところを極力SQL処理にする。
処理するレコードを極力少なくできるようにする。
ごむたいなupdate文を insert文に書き換える。

＞パラメータチューニング
ＤＢバッファ、ログバッファの大きさをでかくする。
（効果が大きいのはredoログ周りくらいなもん）

＞SQLチューニング
インデクスがひけてるか確認する。
（is null検索、OR検索などをやめる）
テーブルの結合順序で速度が変わるのでチェックする
SQLチューニングについていえば、これ以外にもたくさんあるけど、大雑把に言えばこんな感じ。

速度を向上する上で効果があるのは
アプリケーションチューニング　50%
SQLチューニング　45%
パラメータチューニング　5%
って感じ。

No.1 回答者： t_nojiri 回答日時： 2006/12/02 19:50

>大雑把すぎるかもしれませんが、

その通り。
資格が、シルバー、ゴールド、プラチナに分かれるくらいデータベースのチューニングは複雑で難しいです。
大体、どういうところにどういうパラメタ変えるかで、一時的には良くなっても運用していくうちに不都合起きるとかも有るし。