Я бы сначала посмотрел статистику Oracle, чего там сильно много....

Ну и "жрать огромные ресурсы по CPU" больше сильно смахивает на проблемы клиента. Не удивлюсь, если у автора банальная проблема, типа не используются bind-переменные и Clob'ы тут вообще не при чем.

IMHO & AFAIK

Вообще-то, Oracle сам умеет динамически выбирать метод хранения BLOB'ов. In row или в отдельном сегменте. Т.ч. пляска с "маленькими блобами" и RAW / VARCHAR2 выглядит, с точки зрения хранения на сервере - достаточно странно.

Раньше (до клиента 11.2), это могло иметь значение для передачи по сети (т.к. BLOB не поддерживали array fetch / bulk collect), но в клиенте 11.2 это уже появилось.

В общем, описанный andrey_arj велосипед, конечно имеет право на жизнь, но только в том случае, если проблема действительно проявляется и этот велосипед ее действительно лечит.

Сам разрабатывал подсистему хранения данных (изображений) в BLOB'ах на Oracle 8i (200 г.). Сотня гигабайт в продакшене - полет был нормальный. Сервера были уровня Celeron'ов 500 Mh, 512 MB ram (дев, продакшен помощьнее). Явных проблем c BLOB не видел.

2. Делать online redefenition таблиц с secureFiles пару раз в неделю (с блобами приходилось делать злобный shrink lob до 10 раз в день)

На мой взгляд, для Oracle это не нормально.

Что на Вашу проблему говорит Oracle Support, какие дает рекомендации ?

Если не обращались и радостно продолжаете делать "online redefenition таблиц с secureFiles пару раз в неделю (с блобами приходилось делать злобный shrink lob до 10 раз в день)" в продакшене с 1 млн. операций чтения\записи в день на табличке 50 гб - то здесь мне даже и сказать нечего. У каждого свои методы получения удовольствия.

Я наверное буду impolite. Не принимайте на свой счет. Просто у меня настроение такое.

andrey_arjЧто касается redefenition - а как жить по-другому?

Просто жить. Без мазахозма. Это, конечно, не доставляет столько эмоций и впечатлений, но можно и без этого.

Если Вам нравится делать DDL на продакшен базе данных раз в неделю и всем окружающих (заказчика, пользователей) это тоже нравится - то, вряд ли, в этом есть что-то плохое.

andrey_arjРазмер secureFiles растет медленно, но верно, производительность падает.

Если Вы вставляете данные и много - то, разумеется, база данных должна расти в соответствие с объемом данных, которые Вы туда вставили, а производительно __незначительно__ снижаться.

Если же база данных растет до бесконечности.... Ну бывает такое... Но только, обычно, Oracle тут не при чем, кто-то из "коллек" ему помог.

andrey_arjНе утверждаю, что мое решение лучшее, я утверждаю, что оно рабочее и какое-то время на анализ я потратил.

Я поэтому написал, что "велосипед, конечно имеет право на жизнь" т.к. сам сталкивался с ситуациями, когда похожие велосипеды были необходимы.

Я просто говорю, что то, что Вы описываете "нормальным" поведением базы данных назвать сложно. Если Вас все устраивает, то все нормально. Но вот я ТОЧНО уверен, что Oracle может и по другому ))) И BLOB'ы и/или SecureFiles тут явно не при чем.

andrey_arjПлюс задача несколько нестандартная. Обычно блобы записали и они лежат без изменений (как изображения в вашем случае, скорее всего), у меня же другой случай, идет постоянная перезапись и дозапись.

Не путайте СУБД ( БАЗУ ДАННЫХ ) и CD R (без буковки W в конце!). Это немного разные вещи.

Т.ч. Ваша задача, совершенно стандартная. А вот способ ее решения... немного не традиционен.

Вячеслав ЛюбомудровWait Events
Хорошо бы сначала wait events'ы или статистику сессии хоть бегло увидить + версию СУБД

А то гадание при отсутствия хрустального шара.

Напустили страху. Например описание проблемы andrey_arj, кроме как словами "так оно же не работает" ( C ) лично мне не выразит. Но по опыту работы с Oracle > 17 лет и переодической встречи с BLOB'ами, в том числе и очень плотной с ними работами (хранение изображение десятки-сотня(и) GB LOB, картография десятки Gb LOB, миграция базы > 200 Gb BLOB с PostgreSQL) Я уж ни говорю, что BLOB совершенно стандартная вешь и используется почти повсеместно, даже в OeBS.

В общем, мне в такие ужастики верится с трудом.

Конечно всякое может быть: баги, специфика предметной области/задачи (которые по описанию на форуме просто не понятна), настройка сервера - но обычно, это все же диагностируется более точно и лечится не настолько радикальными средствами.

Ну и Oracle СУБД в отличие от продуктов того же M$ допускает настройку хранения данных достаточно в широких приделах.

IMHO & AFAIK