Вот набрались некоторые наблюдения, которыми я хотел бы со всеми поделиться.
Не буду утверждать, что это истина в последней инстанции, просто Экзадатой навеяло ...
--------------------------------------------------------
I. For DBAs
1.
Поставить Unbreakable Kernel. Оно по-умолчанию не стоит.
Настройте также Huge Pages - по-умолчанию их нет,
в результате чего память используется неэффективно, например, как у меня:
$ cat /proc/meminfo |grep PageTables
PageTables: 6991356 kB
почти по 7 Гб занимает таблица страниц на каждом сервере БД.
Около 7% физической памяти в системе!
И это на практически простаивающем тестовом сервере.
Скорее всего в вашем случае это значение будет гораздо больше,
если у вас нагруженный продуктив, который работает подолгу и редко перестартовывается.
2.
Если заглянуть на металинк и сделать поиск по ключевому слову "Exadata",
то станет видно, что ноты, касающиеся Экзадаты обновляются практически каждый день.
Поэтому пока Эказадата ехала в ваш ЦОД на металинке могли появиться новые версии софта и прошивок.
Поэтому особо опытные могут прикоснуться к софту и прошивкам: на серверы, на Infiniband, на cell.
3.
Выбирайте большие диски. Те, что по 2Тб.
Разница в производительности будет небольшой, а по емкости - значительной.
Производительность флеш кеша компенсирует недостатки дисков.
Обратите внимание на рекламные проспекты - при включенном кеше
разницы в производительности между разными дисками нет !
Так, Экзадата дает с выключенным флеш кешем :
1 800 IOPS/cell для НС-дисков
3 600 IOPS/cell для НР-дисков
А с включенным:
75 000 IOPS/cell в обоих случаях.
4.
Создавайте ASM disk group с большими AU size.
5. Создавайте БД с БОЛЬШИМ БЛОКОМ - 16K или 32K.
Понятно почему ?
Ну, во-первых, Smart Scan !
Чем был плох большой блок в традиционной архитектуре ?
Тем, что при чтении одной строки в физическую память сервера прибывало 16К или 32К.
И в этих 32К только одна строка могла быть полезной, а остальные строки в блоке могли оказаться ненужными.
В случае SmartScan на Экзадате в сервер БД будут отдаваться только полезные данные !
Кроме того, на большом блоке меньше накладных расходов (заголовки блока, например) !
Кроме того, в больших блоках более эффективно сжимает данные OLTP-компрессия !
Да и НСС-дедупликация также эффективнее!
Кроме того, для большого блока размер tablespace также будет больше = меньше ограничений на размер этого ТП.
И для индексов польза - и высота уменьшается, и clustering factor возрастает.
Кроме того, команды типа create index ... compress 3; - намного эффективнее на больших блоках.
Тогда уж до кучи включайте на табличное пространство Uniform Size = 32-64М -
мне кажется это более полезно, чем мельчить с autoallocate.
6.
Создайте группу bigfile temporary tablespace из 4-8 ТП,
потому что одного ТП даже из нескольких файлов БУДЕТ недостаточно.
И сделайте сразу uniform 32M-64М
И назначьте эту группу временных ТП дефолтной для всей БД.
7.
Предотвратите создание большого кол-ва малых экстентов для локально управляемых ТП
с автоматическим размером сегмента.
Для этого:
- измените INITIAL до >= 8M ( ну или никак не меньше 4)
- установите параметр в инит-файле CELL_PARTITION_LARGE_EXTENT=TRUE -
тогда новые экстенты для секционированных таблиц будут создаваться начиная с 8М-экстента.
8. Sizing SGA & PGA
SGA - надо делать небольшим - 10-20% of physical RAM. Потому что в Экзадате IO дешевый.
Причины: № 1 - опять таки SS! по причине SS не нужно кешировать много лишних данных.
№ 2 - доступ к дискам быстр как никогда. Флеш Кеш кеширует много полезных данных.
№ 3 - в Экзадате НЕОБХОДИМО отдавать больше памяти под PGA - как по причине
что много процессов, так и по причине 11g-архитектуры вообще.
PGA - надо делать гораздо больше, чем SGA, например 60-75% of physical RAM.
Дело в том, что в версии 11g повысилась нагрузка на PGA:
- мультиблочные чтения уже не идут в SGA, а напрямую в PGA (direct read).
- SS - он выполняется direct read'ом, т.е. тоже идет в PGA.
Кроме того, сортировки выполняются на сервере БД, а TEMP лежит на CELL !
Т.е. при сортировках возникает большой объем передаваемых данных между сервером БД и CELL.
Поэтому делаем боольшое PGA, чтобы быстрее выполнялись сортировки.
Единственное исключение я бы сделал для RESULT_CACHE - его хочется иметь большим.
Чтобы сразу получать готовые RC-ответы на свои SQL-запросы.
9.
Надо делать больше PROCESSES. Например, потому что это большой сервер и к нему будет много подключений.
Кроме того, надо ставить большой PARALLEL_MIN_SERVERS:
PARALLEL_MIN_SERVERS=256
Мы наблюдали большие временные затраты на порождение параллельлных процессов при изначально малом PARALLEL_MIN_SERVERS и большом количестве параллельных процессов, запрашиваемых в SQL-выражении.
Ну а поскольку болшоий PARALLEL_MIN_SERVERS, то надо и большой PROCESSES.
II. For Developers
1.
Х - дорогая штучка, не у всех она есть.
Спрашивается, как народу отлаживать под нее свои приложения ?
Поэтому мой совет разработчикам, желающим отлаживать свой софт под Экзадату:
- возьмите обычную БД 11.2.0.2 ( можно начинать и с 11.2 но не ниже),
- поставьте ее на Линукс 5.5 на х86-64
и САМОЕ ГЛАВНОЕ : установите параметр
CELL_OFFLOAD_PLAN_DISPLAY=ALWAYS
Можно Alter session, можно alter system ...
С этой опцией оптимизатор начнет показывать опцию STORAGE на тех шагах плана,
где он считает необходимым выполнить Smart Scan - это новый способ доступа к данным.
Оптимизация приложений под Экзадату, заключается в том, чтобы как можно больше выражений стали использовать SS. SS выполняется не на сервере БД, а на системе хранения. Поэтому чем больше SQL-работы вы отдадите на уровень системы хранения - тем лучше !
И для отладки не требуется сама Экзадата, достаточно просто иметь базу на 11.2 !
Если хотя бы 20% выражений (которые с учетом частоты выполнения выполняют 80% всей работы) станут выполняться путем STORAGE - то мои поздравления !
Пол-дела уже сделано.
2.
Учитывайте, что Экзадата спроектирована в рассчете на то, что многие запросы на ней будут выполняться параллельно. Причем наш опыт работы на ней подтверждает, что степень параллельности на ней можно задирать достаточно высоко - до 256 с исключительной пользой для всех участников.
Поэтому рассмотрите где и в каких модулях Вы можете включить параллельность.
Еще лучше, если ваше приложение с параллельными запросами уже отлажено
и использует все преимущества параллельности на уже работающем продуктиве.
Такие запросы - просто подарок для Экзадаты,
в смысле - крылья.
В этом случае есть шанс, что все залетает.
3.
Из предыдущего же посыла про проектирование Экзадаты следует второй вывод -
что в Экзадате можно отказаться от многих индексов, если не от всех !
Идея в том, чтобы заменить в подходящих случаях индексный доступ параллельным выполнением.
И это не шутка.
Найдите в Интернете pdf: "Large Scale Data Warehousing at Yahoo", автор
Bohan Chen (bchen@yahoo-inc.com) - в ней показано почему Yahoo отказалось
от индексов в своей 100TB БД.
В любом случае IUD однозначно станут быстрее, потому что отпадет необходимость обновлять индексы после IUD над таблицей. А обновить индексный блок,
это по времени то же что и три IUD над блоком таблицы, т.е. в 3 раза дольше.
Так что - удаляем индексы - открываем простор для OLTP-приложений.
Да и свободного места на дисках и в SGA поприбавится.
Опять же - под полезные данные.
В общем, от данного мероприятия только польза для всех IUD,
вот только отдельные Select - под вопросом.
В общем, чтобы сделать окончательный выбор этот способ надо пробовать.
4. Продумайте какие таблицы/партиции будут храниться в HCC-формате.
Это должны быть большие таблицы на которые практически не бывает update.
Наиболее очевидный вариант: обратите внимание на большие таблицы с партициями.
Типа таблицы звонков (CDR) в биллинге.
Последние 3-6 партиций/месяцев можно хранить без НСС, а все, что старее 1квартала-полугода переводится в НСС командой
alter table move partition ... compress for [query|archive] [high|low]
У НСС имеется 4 варианта, различающихся по уровню сжатия и скорости доступа,
поэтому Вам придется остановиться на одном из них.
Если надо выбор делать быстро, а времени на тестирование - нет, то я бы предложил остановиться на QUERY HIGH - на мой взгляд довольно приемлемый компромиссный вариант.
Хорошо сжимает и быстро достает данные.
На моих нескольких тестах ARCHIVE * - достает данные почти в два раза дольше, хотя жмет всего на 10-20% сильнее.
5. Говоря о компрессии надо упомянуть и про COMPRESSION ADVISOR - пакет
DBMS_COMPRESSION.
Если натравить его на ваших кандидатов в НСС, то он даст свои советы по сжатию ваших кандидатов.
Почитайте о нем в документации и интернете, там есть примеры.
6. Все, что не удалось упаковать в НСС -
рассмотрите варианта OLTP COMPRESSION.
На мой взгляд он уже вполне прилично работает в 11.2.
Проблемы, которые могут быть с OLTP: сложно менять структуру - добавлять/удалять столбцы,
изменять тип данных столбца.
Возможно, что индекс-организованные или кластерные таблицы не могут быть OLTP COMPRESSED.
Поэтому какие конкретно таблицы подвергать этому сжатию - вопрос на суд разработчика.
Но подвергать этому виду сжатия на мой взгляд полезно, потому что плотность данных возраетет раза эдак в два,
следовательно ввод/вывод - уменьшится, а скорость выполнения запросов - увеличится.
А это значит, что в два раза повысится плотность данных на дисках, в два раза - вSGA и в два раза в FlashCache. А это сотни и сотни Гб соответственно.
И помните, что админ для вас специально создавал БД с большим блоком,
чтобы получить побольше выигрыш и от OLTP компресси в том числе.
В общем, это легко включаемый способ чтобы резко повысить плотность данных на дисках, в FlashCache и в SGA, что по-идее должно дать вполне ощутимый синергетический эффект при полной прозрачности для приложения.
Этот вариант также можно также погонять под DBMS_COMPRESSION - адвайзером.
7.
Ввиду появления в Экзадате Smart Flash Cache некоторым - МАЛЕНЬКИМ и ЧАСТО ОПРАШИВАЕМЫМ таблицам можно назначить аттрибут CELL_FLASH_CACHE=KEEP = принудительно положить их поближе к SGA.
В свободное время подумайте над этой возможностью. Но без фанатизма.
Стандартная настройка DEFAULT тоже прекрасно работает без нашего с вами вмешательства.
