Oracle кластер умер, да здравствует кластеризация!

_{Здесь и далее имеется в виду cluster хранения данных, а не Oracle Real Application Custer}

Проблематика

Большим информационным системам свойственно постоянное поступление различной информации, которая накапливается, обсчитывается и архивируется. Мы рассмотрим вариант структурированных данных, хранящихся на сервере RDBMS Oracle и в качестве примера возьмём таблицу, содержащую CDR записи (т.е. записи о вызовах) для абонентов оператора связи.
Данные о звонках поступают хаотично, т.е. не упорядоченно, как вы понимаете, по атрибутам абонентов. Все данные имеют свой жизненный цикл — оперативные, актуальные и архивные. Со временем частота обращений и требования по скорости доступа к данным меняются (т.е. падают). Т.о. записи годичной давности вполне можно хранить на медленных дисках, активные — на дисках с высокой скоростью доступа и без претензий на производительность операций записи, а вот вновь поступающим данным свойственно требование к максимально высокой скорости записи и чтения.

Собственно, возник вопрос: а присутствуют ли всякие DBA_TAB_PARTITIONS и иные объекты словаря в SE One? Причина вопроса проста: код заточен на Oracle EE и использует эти представления. После установки обнаружилось, что данные объекты не только присутствуют, но и не пусты. Раз не пусты, то из этого вытекает, что создать сегментированные таблицы возможно, а раз так, то неплохо бы посмотреть, как это происходит.

Все справедливо считают, что конструкция ORDER BY расходует ресурсы на проведение сортировки результата и в итоге мы должны получить результат несколько позже. Всегда ли это так?..

Как многие знают в СУБД Oracle начиная с версии 11g появилась технология сохранения результата выполнения функции для заданного набора параметров в специально выделенном для этого cache по аналогии с buffer cache для блоков данных.
В данной статье я собираюсь рассмотреть вариант использования «побочного эффекта» данной технологии.