港的
「IT　人には聞けない、チョット良い話」

SQLのチューニング をする際に、チェックする観点を掲載します。 最低限 、これだけは チェックして欲しい 内容です。 これらをチェックするには、 人・工数・決断 を必要とします。 開発メンバーの士気は下がり、場合によってはプライドすらも 傷つけます。 時間が無いのに、新たな作業を言い渡される訳ですから・・・ だ・か・ら、納期ギリギリでは「つらい」のです。 ※しかし、港は無表情で作業の依頼を指示します。 　（まぁ、殴られたり、刺されたりした事は無いので・・・） どうぞ参考にして下さい。 【チェック内容】 01.サブクエリを引数に取る場合、IN述語よりもEXISTS述語を 　　使っているか 　　SELECT name 　　FROM Personnel 　　WHERE birthday IN (SELECT birthday FROM Celebrities); 　　　　　　　　▼ 　　SELECT P.name 　　FROM Personnel AS P 　　WHERE EXISTS 　　　　(SELECT * FROM Clelebrities AS C 　　　　　　　　　　　WHERE P.birthday = C.birthday); 02.IN述語やCASEの引数リストの順序を考慮しているか？ 　　（最もありそうなキーを左から記述） 　　SELECT * FROM 住所 WHERE prefecture 　　　　　　　　　　　　　　 IN ('東京', '大阪', '鳥取', '徳島'); 　　※IN は、左から右へ引数を評価し、見つかった時点で 　　　true を返しそれより後の引数は見ない 03.EXISTS述語のサブクエリ内では、SELECT * を使っているか？ 　　SELECT …. WHERE EXISTS (SELECT * FROM …) 　　※オプティマイザにどの列を使うのか選択を委ねる 04.3つ以上のテーブルを結合させる時は冗長な結合条件を 　　記述しているか 　　SELECT * 　　FROM Table1 a, Table2 b, Table3 c 　　WHERE a.common = b.common 　

インデックスをはった後は必ず統計情報を確認しましょう。 近頃のOracleのオプティマイザはとても賢くなったし、 最適化してくれるツールもあって、港の出番も減ってきています。 しかし、オプティマイザでも意図する実行計画を立案してくれる 訳ではないので、 統計情報を取得して内容をキチンと確認 する事。 インデックスも種類によっては使い過ぎちゃダメなものもあります。 例えば、ビットマップインデックス！！ このインデックスは、0,1の値をもつカラムにはると効果てき面です。 ※簡単に効果が出るので、安心して使えます。（NULLにも効果あり） でも、頻繁に更新処理がなされる場合は、要注意です。 理由は、ロックする単位がビットマップセグメント単位になるからです。 なので 、処理によってインデックスを検討する事も大切 なのです。 ここで、仕様がわからないからチューニングできない！って声が 聞こえますが、そんな声は、無視しましょう。 （わかろうとしないからできないのです。） とにかく、闇雲にインデックスをはらないこと。 とにかく、データの分布を確認し、有効なインデックスを利用する。 とにかく、インデックスに頼らないDB設計をする！！ インデックスは管理者がきちんとチェックし管理する。 これでいいのだ。

オブジェクト・チューニングとは、 表やインデックスをチューニングする事です。 パフォーマンスチューニングは得てして開発の終盤に 依頼されるされる事が多いので、港はあまり表に対して チューニングする事は控えてます。 ※そもそも、この段階で表に手を入れるのは リスク が多いので・・・ インデックス・チューニングを行う前に、 「インデックスの種類と特性を知っておく」 ことが必要です。 ※結構知らない人が多い。 とりあえず種類を・・・ Bツリーインデックス ビットマップインデックス 逆キーインデックス ファンクションインデックス それぞれ、 特性が異なる ので用途も違います。 参考書等やネット上にも情報があるので、 理解しておくことが大事です。 それと、もっともっと大事な事があります。 「インデックスをはりすぎてませんか？」 という事です。 やたらにインデックスをはっているシステムに出くわします。 Aさん：　「インデックスをはってるんですが、遅いんですよねぇ」 港：　　　「インデックスの定義を見るね」 港：　　　（オペレーションで確認）「・・・・（はりすぎ・・・）」 Aさん：　「どうです？」 港：　　　「インデックスを全部はがします。」 Aさん：　「まじっすか！？」 港：　　　「Drop ・・・・」 Aさん：　「やめて下さい！！」 港：　　　「ぽちっとな。（うるさい。黙ってろ・・・）」 　　　　　「さぁ、インデックスをはりかえましょう」 Aさん：　「・・・（ぶん殴ってやる！）」 てな、感じです。（極端な例ですが・・・） とにかく、インデックスをはれば速いって事で、 無造作にはっているケースに出くわします。 まず、インデックスを見直す前に・・・ 各表のデータ量を把握する 各表のプライマリ毎のデータの分布を把握する。 各表の用途を把握する。 結構地味な作業ですが、この準備をするしないで 後のインデックスを考える作業に役立ちます。

SGAで比較的簡単にチューニングできる事は・・・ １．SGAをメモリに常駐させる ２．思い切って、SGAの自動管理を止める ３．データベース・バッファ・キャッシュ 　・データベース・バッファ・ヒット率 ４．共有プール 　・ライブラリ・キャッシュ・ヒット率 　・ディクショナリ・キャッシュ・ヒット率 ５．SORT_AREA_SIZE、HASH_AREA_SIZEを拡張する。 ６．db_files_multiblock_countを大きくとる。 これくらいからは、簡単にできるのでチャレンジして見て下さい。 結構、効果がでます。 ただし、以下の事に注意！！ 　・SGAを常駐させる場合、実装されているメモリの大きさにかなり左右される。 　・SGAを常駐させる場合、REDO領域の書き込み周期を考慮する。 　・Windows Serverの場合、ラージページをサポートしているが、安易に拡張しない。 　　（Serverダウンの原因になります。） SGAのチューニングは、意外と楽にパフォーマンスが向上しますので、 チャレンジする価値はあります。