多かれ少なかれ次のように見える約100.000行のテーブルがあります。
id varchar(20),
omg varchar(10),
ponies varchar(3000)
国際文字のサポートを追加する際、ponies
3000 (マルチバイト) 文字は nvarchar には大きすぎるため、列を nclob に再定義する必要がありました。
id varchar(20),
omg varchar(10),
ponies nclob
Java で準備済みステートメントを使用してテーブルから読み取ります。
select omg, ponies from tbl where id = ?
「ponies」列が NCLOB に変更され、他のいくつかのテーブルが nchar 列を使用するように変更された後、Oracle 11g はid
列のインデックスを使用する代わりに完全なテーブル スキャンを実行することを決定したため、アプリケーションが停止しました。
クエリにヒントを追加すると、インデックスが使用され、すべてが「問題なく」、または列が varchar の場合よりも少しだけ遅くなります。
次の接続プロパティを定義しました。
oracle.jdbc.convertNcharLiterals="true"
defaultNChar=true
ところで、データベース統計が更新されます。
すべてのクエリを調べる時間がなかったので、他のインデックスが無視されているかどうかはわかりませんが、id が nchar ではないため、defaultNChar 設定がオプティマイザーを混乱させているのではないかと心配する必要はありますか? 事実上すべてのクエリにヒントを振りかけるか、すべてのキーを再定義するのはかなり厄介です。
または、「大きな」nclobがロードされるため、完全なテーブルスキャンは重要ではないと見なされます-その仮定は3桁ずれているようで、Oracleはそれよりも賢いと信じたいです。
それとも運が悪いだけ?または、他の何か?ヒントなしで修正できますか?