Oracle позволяет использовать HCC-компрессию не только на Экзадате, но и на ZFS storage appliance и на Pillar Axiom. Если в качестве сервера взять T4 + Solaris 11, то получится отличная платформа для консолидации данных: много потоков и НСС впридачу!
Покажем работающи пример :
0. Берем сервер Т4, инсталлируем на нем Солярис 11. На Axiom создаем LUN и презентуем его серверу - все как всегда.
1. Компрессия возможна только на сырых томах (не на файловой системе), поэтому используем ASM, поэтому поэтому первым делом инсталлируем GI.
2. Для HCC требуется версия GI не ниже 11.2.3.0.3. В более ранних версиях оно не работает. Поэтому я взял последний PSU от January 2013 - ставим его на GI.
3. В ASM cоздаем дисковую группу. Для данной группы устанавливаем два обязательных параметра:
alter diskgroup data set attribute 'compatible.asm'='11.2.0.3';
alter diskgroup data set attribute 'storage.type'='AXIOM';
Если некоторая дисковая группа уже создана и в ней уже лежит БД, то ничего страшного - надо остановить БД и установить параметры. Причем, первый параметр - 'compatible.asm' - можно менять без остановки БД, он динамический.
4. Инсталлируем бинарники СУБД: опять берем последнюю версию - 11.2.0.3 - и последний PSU - January 2013. Инсталлируем Оракл и создаем БД на нашей дисковой группе.
Готово!
Статисика показывает, что около 75% данных в базе относятся к закрытым периодам - прошлый год, квартал.
Еще 20% - это активные данные, которые иногда меняются.
Еще 5% - это горячие данные, активно изменяющиеся.
Первая категория данных - это хорошие кандидаты на НСС. Если их пожать, например, в 10 раз, то объем базы значительно сократится. Затраты ЦПУ возрастают в 3 раза, но ввод-вывод сократится в 10 раз. В общем, прирост производительности налицо.
Вторую категорию можно объявить как OLTP Compression - затрат ЦПУ практически никаких, а объемы уменьшаются в два раза.
Третью категорию оставляем как есть.
Покажем работающи пример :
0. Берем сервер Т4, инсталлируем на нем Солярис 11. На Axiom создаем LUN и презентуем его серверу - все как всегда.
1. Компрессия возможна только на сырых томах (не на файловой системе), поэтому используем ASM, поэтому поэтому первым делом инсталлируем GI.
2. Для HCC требуется версия GI не ниже 11.2.3.0.3. В более ранних версиях оно не работает. Поэтому я взял последний PSU от January 2013 - ставим его на GI.
3. В ASM cоздаем дисковую группу. Для данной группы устанавливаем два обязательных параметра:
alter diskgroup data set attribute 'compatible.asm'='11.2.0.3';
alter diskgroup data set attribute 'storage.type'='AXIOM';
Если некоторая дисковая группа уже создана и в ней уже лежит БД, то ничего страшного - надо остановить БД и установить параметры. Причем, первый параметр - 'compatible.asm' - можно менять без остановки БД, он динамический.
4. Инсталлируем бинарники СУБД: опять берем последнюю версию - 11.2.0.3 - и последний PSU - January 2013. Инсталлируем Оракл и создаем БД на нашей дисковой группе.
Готово!
Статисика показывает, что около 75% данных в базе относятся к закрытым периодам - прошлый год, квартал.
Еще 20% - это активные данные, которые иногда меняются.
Еще 5% - это горячие данные, активно изменяющиеся.
Первая категория данных - это хорошие кандидаты на НСС. Если их пожать, например, в 10 раз, то объем базы значительно сократится. Затраты ЦПУ возрастают в 3 раза, но ввод-вывод сократится в 10 раз. В общем, прирост производительности налицо.
Вторую категорию можно объявить как OLTP Compression - затрат ЦПУ практически никаких, а объемы уменьшаются в два раза.
Третью категорию оставляем как есть.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.