Comments 12
А не проще будет двигать партиции на накопители, состоящие из дешевых не-SSD дисков, вместо того, чтобы платить за Advanced Compression лицензию и хранить сжатые партиции на тех же дорогих накопителях?
Да, есть и такая возможность. Мы её уже частично используем. Переносим данные на сервера аналитики и согласуем с бизнесом чистку данных на Процессингах старых кампаний.
Да можно даже и не переносить в другие базы. В той же базе создать один или более tablespaces, датафайлы которых будут находится на более дешевых накопителях. И потом двигать партиции в эти tablespaces, это Оракл умеет с версии 11, а в 12 даже с опцией ONLINE (хотя для вас оно, наверное, не очень важно).
Мы так храним некоторые базы : небольшой объем read-write данных на быстрых и "родных" Exadata storage cells, а исторические данные - на более дешевых ZFS appliances. Легким движением руки данные еженедельно или ежемесячно переносятся с одного накопителя на другой : alter table ... move partition ... tablespace <ZFS>, всё автоматизировано.
Причем, иногда данные в этих партициях на ZFS приходится обновлять, ну, типа, клиент решил воспользоватся законом "right to be forgotten" и его имя / адрес / размер противогаза приходится вымарывать отовсюду, включая исторические данные. Тоже работает, пусть и не быстро - но в таких делах никто быстроты не ожидает, важна скорость работы с оперативными данными, а не с историческими.
А зачем вы платите за опцию advanced compression если в итоге все равно в регламенте сжимаете отдельным процессом?! С этим и бесплатный basic compression справиться на ура. Плата за воздух по сути.
О каких проблемах с нарезанием секций до версии 12.2 вы говорите? Автоматическое секционирование существует лет 15 в оракл и лучше оно не стало. Автоматическое плохо тем, что использует свой паттерн именования, что не очень удобно. Простая процедура по генерации нарезки секций с отложенным созданием решает все проблемы в любой версии.
Ещё вопрос - зачем делать жёсткую проверку foreign key? В 12шке есть отложенная мягкая. В batch нагрузке с ней гораздо быстрее.
Это интересная мысль, но какие подводные камни с deferred есть? Долгий коммит? Если все-таки fk сработает нас ждет толстый откат?
Насколько я помню, реализовано как в Терадата - автоматический отброс в корзину-сателит ключей, которые не бьются.
В целом, если запись в таблицу управляется регламентными ЕТЛ процессами либо API, который спроектирован правильно и есть массивные batch операции, то проверка fk нужна только лишь для ручных изменений\удалений (как бы не удалить чего лишнего на что есть ссылка).
А какая у вас нагрузка rps? Какое максимальное кол-во клиентов можно оповестить за раз?
Как работает создание и управление маркетинговыми кампаниями Спортмастера и причём здесь Oracle