Comments 18
>> Сжатие на уровне блоков
А какой у вас размер блока ?
А глобальные индексы для чего используются?
Для поиска по всей таблице, а не отдельным секциям. Что не ясно?
Различия между глобальными и локальными идексами выражаются в их отношениях с таблицей.
Для глобальных индексов - один раздел индекса соотносится со многими разделами таблицы.
Для локальных - один раздел индекса - один раздел таблицы.
Глобальные индексы секционируются независимо от базовых таблиц. Например, каждый раздел индекса может содержать ключи, которые относятся к разным разделам или подразделам таблицы.
По идее, так как при компрессии мы трогаем только субпартицию, то ожидается что и перестраивать нужно только индекс для этого раздела.
Но нет. В нашем случае, для оптимальной работы Оракл требует пересобрать индекс всей таблицы.
"Проводились активности по удалению" - это какой-то новый канцелярит?
Для HCC нужна exadata, не всем подойдет
Было 0.6х12=7.2Tb в год, стало 0.38*12=4.56Тб в год.
Каким образом это могло спасти от первого выхода "закидывать в базы, как «в топку», бесконечное количество дисков" пока не очень понятно.. Стало нужно всего лишь в полтора раза меньше дисков. Но это же даже не кратное улучшение
Вариант закидывать старые партиции с холодными данными на hdd не подходил? Я правда, никогда не пробовал оракл в гетерогенной среде, может и чушь спорол..
Для архивных партий как раз отлично подойдёт большой дисковый массив из более дешёвых (не-SSD) дисков, на котором можно создать один или более read-only tablespace и переносить архивные сжатые партиции туда. Заодно и бэкап оптимизируется, Rman не будет каждый раз бэкапить read-only датафайлы.
Если включить оптимизацию бекапа он и так не будет копировать файлы, которые не поменялись. Ридонли только чтоб предотвратить изменения, где и когда они не нужны
У read/write датафайлов всегда меняется header - туда пишется последний scn. Даже если не было никаких изменений данных в этих датафайлах. И такие датафайлы будут бэкапиться при level 0 бэкапе, увы. Или вы про BCT (block change tracking), когда при level 1 бэкапе будут бэкапиться будут лишь измененные блоки?
Не соглашусь, тут разница принципиальна) Стало нужно аж в полтора раза меньше дисков.
При выборе варианта между "нужно много денег на СХД" и "нужно в полтора раза меньше денег на СХД" - бизнес обычно выбирает второй вариант.
В целом, вы конечно правы. Описанный способ не избавит от необходимости хранить данные и не сожмёт 40 тб. в сингулярность. С другой стороны разрастание данных - логичное следствие штатной работы системы.
Вариант закидывать старые партиции с холодными данными на hdd тоже рассматривали. Идея правда хорошая, тем более разные партиции можно вынести на отдельные табличные пространства для размещения на отдельных дисках. Но в нашем случае компании пришлось бы дополнительно закупать отдельно медленные HDD. Мне сказали, что есть быстрые и классные SSD - работайте на них.
tldr: включили сжатие на уровне бд и уменьшили размер данных в 1.5 раза
Уточните в статье, что HCC возможно только на EXADATA.
Какой объем данных за год вы пережимаете?
2 часа это слишком быстро и оптимистично даже с параллельностью 8. По-моему опыту за 2 часа удавалось пережать не так много таблиц. Реализовывали логику на Informatica PowerCenter для еженедельного пережатия данных
Зависит от типа данных. Но статья больше похожа на рекламную, это да.
Благодарю за дополнение про exadata.
За год обрабатывается примерно 4.7 тб. данных.
Ежемесячно обрабатываем 1400 партиций (140 таблиц), 400-500 гб. Мне не кажутся эти значения аномально большими. БД за час вполне успевает их прожевать.
Наша база работает на железном сервере с характеристиками 64 cpu, 1 tb ram. Такие значения благоприятно сказываются на производительности.
Умное хранение или как мы снизили рост БД Oracle в полтора раза