Мысли вслух.
Построена витрина, хранящая в себе числовые показатели несколько id - ссылки на справочники. Витрина - большая, сейчас порядка 12 млн записей, после внедрения будет быстро расти. Заказчик изначально просил витрину с текстовыми полями, моя инициатива хранить и создавать в виде звезды. Справочники маленькие, от 1000 записей до 30 000.
Решил создать view - связку. Играю с хинтами и пытаюсь убить несколько зайцев.
1) Хочется, чтоб первые две записи вернулись быстро.
2) Если витрину будут использовать для полного сканирования и подсчета агрегатов, хочется чтоб скорость не подкачала.
Обычный хинт first_rows решает первую задачу и делает доступ ко всем таблицам через nested loops. Сначала читается большая таблица, и для каждой прочитанной строчки nested loop по остальным таблицам. Где-то есть индексы, где-то нет. Соответственно, оракл старается их использовать. Мне кажется для полного сканирования такой доступ будет долгим.
Чего хотелось бы добиться, но никак не получается. Сервер читает все справочники в память, создав хеш функцию по связываемым полям. Затем читает фулом большую таблицу и по хешу находит строчки из всех справочников. Если таблицы две (большая и маленькая) - получается. Больше - никак.
Делитесь опытом. Реально ли это? И как вы поступаете в такой стандартной ситуации.
И еще. По инструменту Пользуюсь PL/SQL developer - есть вопросы по сканированию explain_plan работающего запроса. Мне кажется, работающий запрос не всегда идет по тому плану, который он предварительно показывает. Есть ли возможность просканировать план работающей сессии.

AmKadbhr,

Начать с анализа предикатов, рассмотрения вариантов партиционирования, индексирования, денормализации.
Я наверно неправильно описал проблему. Или читатели не предполагали, что ставится такая нелогичная задача.
Где и как будет использоваться вьюха - неизвестно. Основная витрина неимеет ни индексов ни партиций. Нужны они или нет - будет известно лишь, когда будут конкретные задачи на ней. для меня заказчик - черный ящик. попросил витрину, я сделал. что он с ней будет делать - пока не знаю. Возможно, просто заберет все данные в САС и будет там лопатить. Тем не менее. коль скоро я вместо витрины даю ему вьюху, хочется чтоб доступ к ней был "быстрым". тут то и возникает вопрос, что считать быстрым. просто селект из нее чтоб первые строки глянуть. Или селект всей таблицы, чтоб выгрузить куданить....
В принципе, пока формулировал впрос, ответ назрел. Нефиг ему с вьюхой лопатить, пусть понимает структуру данных и если нужно сделать суммирование всего с группировкой, пусть использует исходную таблицу или обращается ко мне.

feagorbhr,
как часто обновляются данные витрины? база OLAP или OLTP? Возможно имеет смысл делать материализацию
когда все будет протестировано, витрина будет инкрементно дозаполняться несколько раз в день.
пока все заполняется сразу - транкейт и заполнение с нуля.
возможно создам партиции по датам (по месяцам или дням).
Материализация? 5 полей varchar2(256) - 100 млн записей за год (ориентировочно).

AmKad,
думаю, Вы правы

IMNObhrНужны они или нет - будет известно лишь, когда будут конкретные задачи на ней.
Том Кайт в своей книге писал, что худшее, что вы можете сделать, это тестировать приложение в производственных условиях.
Если Вы не знаете нужны индексы или нет, то значит плохо проанализировали задачу. Значит стоит вопрос не как написать селект с хинтами, а как правильно спроектировать базу.
тестировать приложение в производственных условиях
В dwh жизнь размеренна и нетороплива. пользователей объектов - полторы штуки в день. ничего страшного не произойдет.
то значит плохо проанализировали задачу
Мир вообще несовершенен, я с этим смирился. Я тут работаю всего ничего. и начал с расчета, который несколько часов считался. довел до нескольких минут. Проектирование базы в мои обязанности не входило. Конечную задачу мне никто не ставил. возможно заказчики ее сами не знают, ибо анализ данных - процесс творческий. их бизнеслогика интересует, а не структурирование и хранение данных.
И их слово последнее - мы под них подстраиваемся, а не они под нас.
А так да. Ошибок много. и глобальная - не неправильное проектирование базы, а возможно рождение не в ту эпоху, не в той стране и не в том статусе.

казинактакшта, dbms_xplan - можно посмотреть план последнего выполнившегося запроса, ну и др возможности есть
спасибо, попробовал. Более того. нашел это в pl_sql developer. В окне сессий можно глянуть конкретную работающую сессию и в одной из нижних закладок (sql monitoring) - действующий план. Какой-то весь цветастый, непривычный. спасибо.