Monday, July 25, 2011

Price is negotiable, Performance is not !

Вот тут
http://dsvolk.blogspot.com/2011/07/exadata-better-than-emc.html
происходит баталия по поводу  производительности В/В на Экзадате и ЕМС.

По этому поводу могу сказать, что оба вендоа - как ЕМС так и Оракл - не являются производителями этих плат, а покупают флеш-устройства у их реальных производителей, вероятно, у LSI, RICOH: http://www.ricoh.com/LSI/product_pcif/pcc/5c833/index.html.


Затем, отобрав лучшее путем нагрузочных тестов используют эти устройства в своем оборудовании. Таким образом, с большой долей вероятности и у ЕМС и у Оракла будут стоять самые лучшие девайсы, показывающие примерно одинаковые характеристики производительности.

Разница между ЕМС и Ораклом в том, что ЕМС не знает какие данные ему лучше кешировать, а какие - не кешировать. А Оракл - точно знает.
В результате, ЕМС будет кешировать redo, которое составляет половину всего В/В в базе данных, а Оракл - нет. ЕМС будет кешировать сортировки (которые пишутся в ТЕМР), а Оракл - нет. ЕМС будет кешировать операции многоблочного чтения и записи, а Оракл - нет.
ЕМС будет кешировать операции бэкапа, а Оракл - нет. ЕМС будет кешировать LOB-ы, а Оракл - нет (inline-lob кешируются).
Таким образом, видно, что при проектировании Экзадаты Оракл произвел систематизацию типов данных и отделил полезные данные (которые надо кешировать), от вспомогательных (которые кешировать не  надо).
В результате, кеш ЕМС будет минимум наполовину (redo), если не на 3/4 или 5/6 забит бесполезными данными, что понижает эффективность кеширования и  увеличивает нагрузку на стородж-процессоры, которые тысячи раз в секунду должны решать какие блоки следует вытеснить из кеша, чтобы найти очередной свободный блок под интенсивно льющиеся данные (недостатки write-back). Кроме того, в обычных массивах, кеш на запись всегда зеркалируется. А это означает, что пространство под даные резко уменьшается.
В результате кеширования в Экзадате останутся наиболее часто запрашиваемые блоки - наиболее востребованный контент - справочники и индексные блоки, что способствует стабильности работы приложений. Т.е. приложения на Экзадате просто не заметят 8-часовой бэкап, поскольку практически все необходимые им данные будут всегда под рукой. Иными словами, Экзадата во-первых - качественнее кеширует данные, а во-вторых, надежнее защищает кеш от размывания.

Я так думаю, что если бы оборудование ЕМС кешировало данные лучше, чем сам Оракл,
то Оракл просто поставил бы это оборудование в Экзадату взамен своих серверов хранения.
И если ЕМС в будущем решит кешировать данные Оракла избирательно (т.е. также как в Экзадате), то вряд ли они смогут это сделать так же аккуратно, как Оракл. Кроме того, появление новых типов данных будет приводить к тому, что ЕМС в этом вопросе всегда будет отставать на несколько лет.

Если говорить о механизм кеширования Экзадаты, то, например, операция записи порции данных на сервер хранения вначале записывает эту порцию на диск, а затем серверный процесс решает, кешировать ли поступившие блоки = записывать их в флеш кеш или нет. Операция чтения блока вначале читает блок в RAM сервера хранения, и отдает его наверх, а потом также решает кешировать или нет.
Для временного хранения этих блоков в сервере хранения в оперативной памяти выделена shared memory размером 8Г. Эта область используется процессами сервера хранения в качестве рабочей области. Т.е. это полноценная work area (так и хочется сказать - SGA) = быстрый кеш на динамической памяти.
Таким образом, если сравнивать архитектуру обычных массивов с сервером хранения Экзадаты,
то у Экзадаты  на 1 сервер хранения приходится DRAM-кеш = 8Гб + 12 (24) ядер  + FlashCache 384Гб.

Sunday, July 24, 2011

Oracle поглотил компанию Ksplice, развивающую технологию обновления Linux-ядра без перезагрузки

Корпорация Oracle объявила о заключении сделки по покупке компании Ksplice, развивающей технологию обновления Linux-ядра без перезагрузки и временной остановки работы. Разработки Ksplice будут интегрированы в продукт Oracle Linux, что позволит усовершенствовать дистрибутив в плане увеличения безопасности, надежности и отказоустойчивости.

Ранее сервис распространения готовых Ksplice-обновлений был бесплатно доступен для пользователей Ubuntu и Fedora Linux, а поддержка Red Hat Enterprise Linux, CloudLinux, Ubuntu Server, Debian GNU/Linux и CentOS осуществлялась на коммерческой основе. Около 700 компаний пользовались сервисом Ksplice. После перехода технологии в руки Oracle, сервис распространения обновлений планируется реализовать в виде стандартной опции "Oracle Linux Premier Support" и сделать его доступным клиентам Oracle, пользующимся данным типом технической поддержки. Отдельно отмечается, что Oracle не планирует продолжать поддержку Red Hat Enterprise Linux и SUSE Enterprise Linux, все Ksplice-обновления будут доступны только для ядра Unbreakable Enterprise Kernel.

http://www.opennet.ru/opennews/art.shtml?num=31257

Saturday, July 23, 2011

Exadata check utility

Полезный софт, которым надо уметь пользоваться:
Oracle Exadata Database Machine exachk or HealthCheck [ID 1070954.1]
суть:
exachk is the current version.  HealthCheck is frozen and retained for backward compatibility with HP hardware based Oracle Exadata Database Machines.



Wednesday, July 20, 2011

Оракл отмечает успехи ФОРСа в развитии направления Экзадаты:


http://www.oracle.com/us/corporate/customers/customersearch/fors-dev-center-1-exadata-ss-433986.html

Tuesday, July 19, 2011

RAM 144G

Как решил Оракл, серверы БД в Х2-2 теперь могут нести на борту до 144Гб оперативной памяти.
Ранее на них могло быть максимум  96Гб.

Thursday, July 14, 2011

Expansion Cabinet

В качестве приложения к Экзадате Оракл выпустил Expansion Cabinet, он же Exadata Storage Expansion Rack. По-просту говоря, это стойка набитая серверами хранения. Задача такой стойки - предоставить серверам БД много места под хранение данных. Как заявлено в новости - от 96Тб до 3 Петабайт.В ней также работает НСС. Все серверы хранения оснащены флеш-кешем, как и в обычной Экзадате.

Еще возможности:
Oracle Exadata Hybrid Columnar Compression;
Oracle Exadata Smart Scan;
Oracle Exadata Storage Indexes;
Oracle Exadata Data Mining Offload;
Oracle Exadata Backup Acceleration
Oracle Exadata I/O Resource Manager prioritization by Database User or Job.


Продается сей девайс в 3-х вариантах:
- полный = 18 серверов хранения,
- половинка = 9 и серверов хранения,
- четвертинка = 4 .

В зипе идут диски и карточка флеша.

До 8 стоек (Экзадат + Кабинетов) позволяется объединять в  единый пул.

http://www.oracle.com/us/corporate/press/429242

Tuesday, July 5, 2011

Oracle анонсировал 1000-ю инсталляцию Exadata!

Как сообщил Владимир Демкин
http://www.dba.ru/2011/06/oracle-1000-exadata.html

27 июня Oracle анонсировал 1000 инсталляцию Oracle Exadata Database Machine у своих клиентов. На текущий момент Exadata используется в 23 различных отраслях в 67 странах мира.

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/



# ocrconfig -add +DATA PROT-30: The Oracle Cluster Registry location to be added is not usable. PROC-50: The Oracle Cluster Registry locatio...