本日も”しとしと”か”じとじと”かわかりませんが雨が続いています。皆さんいかがお過ごしでしょうか。先週は、データ登録時のインスタンス間のインデックスブロック競合を回避する方法として、node_noというインスタンスを特定するカラムをインデックスの先頭に追加することを検討しました。インサート時の同一ブロック競合は防げるはずです。索側の処理に影響を与えていないか確認する必要があります。その結果、それまでインデックス検索されていたテーブルが全件検索に変わっていることが判明しました。検索側の処理が遅くなっては、本末転倒なので、取り敢えずヒント句を追加してインデックス検索を行わせたところ、元通りとはいきませんでしたがテーブルの全件検索は回避できそうであることがわかりました。sysdate;6666行が選択されました。SCANが実行されていることがわかります。9iからインデックス・スキップ・スキャンと言う機能があります。ご存知の方も多いとおもいます。複合インデックスの先頭カラムをwhere句に記述していない場合でも、そのインデックスを使用できる機能です。これを試してみましょう。sysdate;6666行が選択されました。processedんーーーー。getsが幾分大きくなっています。TRACEを見てみましょう。7584)********************************************************************************おー。確かに取得ブロック数はインデックス・スキップ・スキャンを使ったときの方が多いようですが、むしろ処理時間はこちらの方が速いですね。由については、またの機会に調査するとして、少しでも早いほうを使ってみましょう。今回は、SQL文にヒント句を追加しましたが、ANALYZEを実行しておけばOPTIMIZERの判断で、インデックス・スキップ・スキャンを自動的に選択することもあります。今週はこの辺で、、、ではまた来週。夢見の悪い今日この頃。reserved.トップページ企業概要プライバシーポリシ。