Oracle производительность CLOB
Попытайтесь изменить последний параметр "HTML" на "текст". Этот параметр определяет тип данных, которые будут возвращены.
3 ответа
Thanks for all the helpful suggestions. Despite being flagged as answer to the problem my answer is that there seems to be no good solution. I tried using parallel statements, different storage characteristics, presorted temp. tables and other things. The operation seems not to be bound to any characteristic visible through traces or explain plans. Even query parallelism seems to be sketchy when CLOBs are involved.
Undoubtedly there would be better options to deal with with large CLOBs (especially compression) in an 11g environment but atm. I am stuck with 10g.
I have opted now for an additional roundtrip to the database in which I'll preprocess the CLOBs into a size optimized binary RAW. In previous deployments this has always been a very fast option and will likely be worth the trouble of maintaining an offline computed cache. The cache will be invalided and update using a persistent process and AQ until someone comes up with a better idea.
Общий размер результирующего набора измеряется десятью тысячами - начальные затраты измеряются на протяжении всего извлечения
Есть ли в запросе порядок по? 10К строк - это довольно много, если их нужно отсортировать.
Кроме того, получение PK не является честным тестом по сравнению с получением всего CLOB. Oracle хранит строки таблицы, которых, вероятно, много в блоке, но каждый из CLOB (если они> 4K) будет храниться вне очереди, каждый в серии блоков. Таким образом, сканирование списка ПК будет быстрым. Кроме того, вероятно, есть индекс на PK, поэтому Oracle может просто быстро сканировать блоки индекса и даже не обращаться к таблице.
4 секунды кажутся немного высокими, но это 2 МБ, которые должны быть доступны для чтения с диска и переносится по сети в вашу программу Java. Сеть может быть проблемой.
Мой прошлый опыт использования данных типа Oracle LOB для хранения больших данных был неудачным. Это нормально, когда он меньше 4 КБ, поскольку он хранит его локально, как varchar2. Как только он превысит 4 КБ, вы начнете видеть снижение производительности. Возможно, что-то улучшилось с тех пор, как я последний раз пробовал это пару лет назад, но вот что я обнаружил в прошлом для вашей информации:
Поскольку клиентам необходимо получать большие объекты через сервер oracle, вы можете подумать о следующем интересном ситуация.
- большие данные будут конкурировать с ограниченным SGA кеш с другим типом данных, если оракул решаем кешировать это. Поскольку данные clob вообще большой, поэтому он может подтолкнуть других data
- данные lob плохо читаются с диска, если oracle решает не кэшировать его, и передавать данные клиенту.
- фрагментация, вероятно, что-то с которыми вы еще не сталкивались. Вы увидите, удаляют ли ваши приложения лоб, и oracle пытается повторно использовать лоб. Я не знаю, поддерживает ли oracle онлайн-дефрагментацию диска для lob (у них есть для индексов, но это занимает много времени, когда мы пробовали это ранее).
Вы упомянули 4s для 100 lobs в среднем 20k, так что это 40ms на lobs . Помните, что каждый lob должен быть получен через отдельный локатор Lob (по умолчанию он не входит в набор результатов). Я предполагаю, что это дополнительный круговой обход для каждой доли (я не уверен в этом на 100%, поскольку это было некоторое время назад). Если это так, я предполагаю, что это будет как минимум 5 мс дополнительного времени на поездку туда и обратно в последовательном порядке , право? Если это так, ваша производительность уже сначала ограничена последовательными выборками lob. Вы должны иметь возможность проверить это, отслеживая время, затраченное на выполнение sql и выборку содержимого lob.