Rphoenixkdv,

так в основном списке поступивших больных более 300000 записей (там все хранится с начала 2000). Используется Firebird+Delphi.
процедуры на выборку из этой таблицы выполняются где-то минуту (ну смотря еще как написано, конечно).
Вот я испрашиваю более знающих, лучше делить по годам, либо перенести на новую платформу.
Есть желание изучать Java+OracleSQL, либо хоть базу перекинуть на ORACLE, т.к. она более мощная.
Что посоветуете?
Послушайте старого базовика. Учитывая всё вышесказанное.

Простое "перекидывание" на Oracle не решит вашу проблему. Это было бы профанацией.
Oracle силён тогда когда его обслуживают специалисты которые
используют фичи такие как partitioning, DBMS_MVIEWS, OLAP, text search
и прочее. Которые знают как тюнить план выполнения и как анализировать
данные AWR.

Что у вас есть? У вас есть уже готовая система которая работает под Firebird-Delphi.
У вас есть проблемы с перформансом. И их надо идентифицировать. И понять
как можно убрать.

Для большинства систем где уже "всё плохо" и запущено. Проблемы накапливались
годами как следствие экстенсивного роста самих данных. Самый популярный антипаттерн
в базах - низкий КПД отчотов. Обусловлен тем что одни и теже данные сто раз
фул-сканируются и из них формируются views которые можно повторно переюзать
вместо того чтобы извлекать их снова. И здесь под отчотом я имею в виду не
только отчот но и вообще любой дата-сет или любой курсор или view

Тот-же самый кейс когда OLTP-шный запрос который раньше извлекал 5-10 строк
сегодня извлекает во много раз больше просто никому нет дела до избыточного
овер-селекта.

Еще раз. Поверьте. Просто миграция данных на Oracle вам ничего не даст. Или может
дать как перформанс так и просадку в некоторых местах. И хуже что вы если в
FireBird что-то знали - в новой СУБД (более сложной) будете сильно фейлить
из за нехватки знаний (а их надо много уверяю). И тем более не верьте
тем безответственным которые просто считают что смена СУБД что-то решает.
90% СУБД на одинаковом железе работают одинаково и нет никаких оснований
говорить что Oracle XE вдруг внезапно будет лучше чем Firebird. Чтобы доказать -
что лучше - нужен макет и иммитация нагрузки. Нужен более stong justification
чем просто чье-то мнение или мысли вслух.

Не верьте проходимцам. Собирайте информацию о медленных запросах. Рисуйте
схему БД. Определяйте горячий сет таблис и строк. Ищите закономерности
в самой задаче (они есть). Самые лучшие улучшения в БД я делал просто
выбрасывая из бизнес задач ненужные шаги или материализируя горячие данные.

Тот-же partitioning - не однозначен. Это пасьянс который дает буст к одному
типу выборок а для другого может дать проигрыш. И как правильно сейчас
вам разложить ваши данные по партишенам никто не скажет. А сказать можно
только зная вашу предметную область.

Ну и конечно идите в форум Firebird с планом выполнения и спрашивайте
спецов что и как можно улучшить.

Dimitry SibiryakovmaytonНу и конечно идите в форум Firebird с планом выполнения и спрашивайте спецов что и как
можно улучшить.

Там он уже был. Чисто из любопытства можешь посмотреть его свежие топики.

С вашего позволения я пока не буду.

Блобы кладут не в таблицы а рядышком.
Грубо говоря блоб должен быть доступен приуказании его id но не должен своим толстым
туловищем засорять сегмент таблицы или
индекса. Особенно это касается таблиц по
Которым идут интенсивные поиски.

Partisan MНе надо говорить грубо. Это я мягко выразился. Куда кладут BLOB-ы - зависит от СУБД. В Oracle для крупных BLOB-ов делается отдельный сегмент (область диска), в PostgreSQL такого нет, но PostgreSQL тоже разрабатывали не дураки, и авторы позаботились о том, чтобы BLOB-ы не портили индексацию и поиск. ID-ы там есть (только называются OID).
В Oracle есть варианты. Классика жанра. Вы создаете сегмент таблицы и блобов отдельно (disable storage in row).
Ради экономии места и оптимизации текстового поиска вы можете короткие блобы хранить внутри табличных
блоков (enable storage). Это удобно для кластеризации искомых данных и прочих табличных атрибутов которые
участвуют в поиске. Начиная с 11-12 моделей БД вводится еще целый пакет фич под названием Secured File
(раньше было Basic) которые дают архивацию дедупликацию и много других фич для блобов "из коробки".