hck1вот я не уверен, что индексы идут на пользу именно в такой задачи. каждый показатель читает большую часть таблицы, вычитать таблицу фулсканом без индексов скорее всего эффективней . оракл не знает, что следующий показатель эту же таблицу будет читать и в кеше ее блоки после фулскана не оставляет, ходит по индексам, а потом снова вычитывает эту же таблицу для следующего показателя.

Выделенное жирным - это аццкий отжиг. Админа ораклового вам надо.

hck1и в кеше ее блоки после фулскана не оставляет

Как я понимаю оставляет до тех пор пока есть место и следующее чтение их не перетрет. Если вы хотите всю таблицу загнать в память то и памяти вам надо будет в размере "есть не сильно сложная бд на пару десятков ГБ".

По поводу того что индексы вредят и в таблице много лишних полей. Если в select выбираются только поля индекса, оракл в таблицу вообще не лезет, а берет все данные из индекса. Размер заголовка таблицы в этом случае пофиг.

hck1а потом снова вычитывает эту же таблицу для следующего показателя.

изменить алгоритм расчета. Чтобы два показателя считались за один проход. Как один из вариантов.
Вообще то мне кажется прежде чем переделывать на java большие вычисления нужно понять что именно тормозит и как это будет лучше обсчитать в java. Уже с прикидкой алгоритмов. Не просто перевод PL/SQL -> java один в один. Иначе есть шанс что к тому же приплывете

BlazkowiczИнтересно, можно ли в Oracle загнать какую-нибудь жирную выборку целиком в память и потом запустить алгоритм только по ней?
Выборку можно целиком загнать в таблицу в памяти. Есть там какие-то. Точно не скажу, я только правил чуть алгоритм расчета до меня написанный. Давно это было. Вот там работа шла по этим таблицам.

Ох, неохота спорить, да и не админ я,но 5 копеек вставлю ))

hck1почитайте что-нибудь о многоблочном чтении (scattered read). взрослые субд применяют почти всегда применяют фулскан если нужно более четверти блоков таблицы.


Есть хинты. Хотите без индексов ставьте соответствующий хинт, будет фуллскан. Хотя спорить с ораклом. Оптимизатор у него вууумный. И обычно если он выбирает нужный план, то считает его оптимальным. Статистика по таблицам влиять может. Но это опять вопрос к админу.

hck1не верно понимаете, взрослые субд при фулскане не вымывают кеш, он идет мимо и кеша файловой системы и мимо кеша субд.

Куда он идет то? :) Ну пусть он не называется кэш, но область то в памяти есть

sanBezизменить алгоритм расчета. Чтобы два показателя считались за один проход. Как один из вариантов.

hck1не уверен, что это хороший вариант. к этим показателям постоянно приходят изменения требований, вроде изначально простенький SQL начинает обрастать вложенностями, аналитическими функциями и т.п.. вобщем просто с точки зрения поддержки решено показатели не смешивать, т.к. никто не знает куда они потом разовьются.

Я разве предлагал смешивать показатели?

hck1тут понимание то есть, нет особо идей как с этим бороться имея 12гб RAM. нужно запускать расчет показателей одновременно в параллель, но в оракле из-за не самой оптимальной структуры блока просто выливается в конкуренцию за ио. а вот на объекте в памяти есть шанс, что конкуренции не будет. все ядра CPU будут заняты пробежками по объекту, о не ожиданиями ио

Да не, задача то конечно интересная. Но "есть шанс" смущает как то.

З.Ы.
Было как-то дело оптимизил расчет. Пытался отказаться от процедур на PL/SQL в пользу java. Выигрыша не получил. Обсчет то сам быстрее намного был, но насколько помню сам процесс преобразования "строка таблицы СУБД"->"объект java" + сетевой траффик (поднималорсь много коротких записей) привели к затратам несопоставимым с затратами на PL/SQL. И вернул назад чисто все на базу. Делалось давно, деталей не помню. Но с тех пор к фразе "на java явно будет быстрее" отношусь настороженно. :)

Удачи.