Wednesday, June 22, 2011

Best Practices

Вот набрались некоторые наблюдения, которыми я хотел бы со всеми поделиться.
Не буду утверждать, что это истина в последней инстанции, просто Экзадатой навеяло ...
--------------------------------------------------------


           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 тоже прекрасно работает без нашего с вами вмешательства.


Wednesday, June 15, 2011

Support

Много говорится о том, что в Экзадату ничего нельзя устанавливать. Есть такая проблема.
На прошедшем неделю назад семинаре было много вопросов на тему "А кто будет менять в Экзадате батарейки, диски, адаптеры ?". Сейчас у меня есть более точный ответ на этот вопрос.

Нашлось в документации
Oracle® Exadata Database Machine Owner's Guide
11g Release 2 (11.2)

Part Number E13874-12

приложение "С", которое называется "Replacement Units". В нем говорится:

"There are two types of replacement units, FRUs (field replaceable units), and CRUs (customer replaceable units). FRUs are installed by trained Oracle field technicians. CRUs are installed by the customer."
и далее идут таблицы

Table C-2 Replacement Parts for Sun Fire X4170 Oracle Database Server
Table C-3 Replacement Parts for Sun Fire X4170 M2 Oracle Database Servers
Table C-4 Replacement Parts for Sun Fire X4800 Oracle Database Servers
Table C-5 Replacement Parts for Exadata Storage Server with Sun Fire X4275 servers
Table C-6 Replacement Parts for Exadata Storage Server with Sun Fire X4270 M2 servers
Table C-7 Replacement Parts for InfiniBand Switches  - полностью CRU
Table C-8 Replacement Parts for Cisco Switch - полностью CRU
Table C-9 Replacement Parts for KVM/KMM - полностью CRU
Table C-10 Replacement Parts for Power Distribution Units
Table C-11 Replacement Cables for Oracle Exadata Database Machine


Таблицы большие, описывают каждый шурупчик. В общем, при беглом взгляде я бы сказал, что соотношение компонент CRU/FRU - где-то 60/40. F20 и ее составные части, планки памяти, диски, источники питания, батарейки, Sun dual-port QDR (40 Gb/s) InfiniBand host channel adapter PCIe - всё это полностью CRU.

Себе Оракл оставил замену процессоров и радиаторов на процессоры.
Ну и материнскую плату.
Вот как-то так.
Документация

Oracle® Exadata Storage Server Software User's Guide
11g Release 2 (11.2)

Part Number E13861-10

гласит:
 "File creation operations are offloaded to Exadata Cells. Operations such as CREATE TABLESPACE, which can create one or more files, have a significant increase in speed due to file creation offload."


Проверим:
SQL> set timing on

SQL> create bigfile tablespace yu extent management local segment space management auto datafile '+DATA' size 32g;

Tablespace created.

Elapsed: 00:00:21.12

SQL> alter session set cell_offload_processing=false;

Session altered.

SQL> create bigfile tablespace yu extent management local segment space management auto datafile '+DATA' size 32g;

Tablespace created.

Elapsed: 00:00:21.55


SQL> alter session set "_cell_fast_file_create"=false;

SQL> create bigfile tablespace yu extent management local segment space management auto datafile '+DATA' size 32g;

Tablespace created.

Elapsed: 00:00:46.40

А попробуем-ка отключить offloading другим способом. Что получится?

$ ./sqlplus / as sysasm

SQL> alter diskgroup DATA set attribute 'cell.smart_scan_capable'='FALSE';

Diskgroup altered.

SQL> create bigfile tablespace yu extent management local segment space management auto datafile '+DATA' size 32g;

Tablespace created.

Elapsed: 00:00:44.79

SQL> alter session set "_cell_fast_file_create"=false;

Session altered.

Elapsed: 00:00:00.00

SQL> drop tablespace yu;

Tablespace dropped.

Elapsed: 00:00:00.40

SQL> create bigfile tablespace yu extent management local segment space management auto datafile '+DATA' size 32g;

Tablespace created.

Elapsed: 00:00:45.67


Итак, на 36 дисках файл создается 22-45 секунд.
Учитывая зеркалирование будем считать, что дисков 18.
Интересно, а как долго создается этот датафайл не на Экзадате, а просто на 18 шпинделях ?


Tuesday, June 7, 2011

Mr. Benchmark

Попался блог в интернете, весьма интересный, всем рекомендую:
http://blogs.oracle.com/mrbenchmark/

Вообще из этой серии я бы выделил чрезвычайно полезный в работе:
http://blogs.oracle.com/UPGRADE/
и просто полезный
http://blogs.oracle.com/optimizer/



Does DEALLOCATE UNUSED or SHRINK SPACE will free space occupied by LOB segment?

Lets check how it works. My env is DB 19.20@Linux-x64 1) I created the table with 4 LOB columns of 4 different LOB types: BASICFILE BLOB, BA...