только правда, ничего кроме правды

В начале было слово. И слово это было: в 20 раз. В 20 раз быстрее. 
Источник: http://www.oracle.com/us/corporate/advertising/412m-exd-eurortl-sec-1556931.pdf

Правда, немного подумав, Oracle решил взять свое слово обратно, ну а затем,  что и  5 раз будет достаточно


И, чтобы уж совсем быть уверенным добавил, цитата: "Oracle, the “sponsor will select the queries for measurement"", что в переводе на русский язык значит: я сам выберу те запросы,  которые окажутся у меня быстрее.
Я также обратил внимание, что ничего не говорится о числе пользователей - предполагается запускать единичные запросы ? Или я что то пропустил ?

Но даже это не важно. Важно то, что несмотря на то, что Exadata, цитата: "Exadata is optimized for Oracle Data Warehouse and OLTP database workloads", сравнивать хотят именно производительность Warehouse. Это гениально, я считаю. Ответным ходом было бы сравнить производительность Netezza против T4 -)

PS. Тем временем те, кому надо просто и без геморроя, чтобы стало быстрее, ставят SSD диски. Проект миграции между Power 550 и Power 740 занял 6 часов.  Цитата: "end-of-year batch jobs dropping from a minimum of eight hours to just one hour".  Почему я про это вспомнил ? Да в этом европейском ритейлере наверняка стояла Power 550. Данных найти мне не удалось, но по времени выходит, что больше нечему там еще было быть. 


Читать дальше...

Oracle on AIX. Part 2. Memory.

IBM Development совместно с Oracle Development обнаружили, что при совпадении некоторых условий работа Oracle Database 11.2 на AIX 7 может замедляться по происшествии нескольких дней.  Проявления этого замедления могут быть разные, в том числе (но не обязательно) медленный login в базу данных через sqlnet. Или крайне медленные операции parse. Странные вещи короче, которые проходят после рестарта Oracle.

Условия:  AIX 7, TL0 или TL1, Oracle 11.2.0.3 (строго, в 11.2.0.2 такой ошибки не случается).

Рекомендация: выключить параметр shm_1tb_unsh_enable.

vmo -r -o shm_1tb_unsh_enable=0

Для того, чтобы разобраться есть ли в вашей системе эта проблема (обратите внимание еще раз на версии ОС и СУБД) можно выдать следующую команду:

echo "pfhdata -lsa" | kdb 

Если в обведенных красном колонках будут не нулевые значения - применяйте параметр.


Читать дальше...

Oracle on AIX. I/O. Part I

Update 1. disk_asynch_io=true (значение по умолчанию) рекомендуется для любых вариантов установки Oracle on AIX


Update 2. AIX6 + 10GR2 все в порядке, детали в комментариях. Кажется проблема только с 11gR2 .


Если вы эксплуатируете  Oracle on AIX вы обязаны прочитать вот эту whitepaper. Замечательный документ.  Однако в нем есть несколько тонких моментов. Один из них - рекомендации по монтированию файловой системы для файлов данных. Стр 55 в частности сообщает:


Это абсолютно правильное сообщение.
Oracle Support также  согласен с вышеприведенной рекомендацией (MOS ID 960055.1)


Здесь нужно сделать маленькое отступление, чтобы понять, почему так много уделяется внимания этому вопросу. Без указание опции cio производительность СУБД Oracle во многих слуаях была неудовлетворительной. C опциями монтирования по умолчанию происходило двойное кэшировние данных, в кэше файловой системы и buffer cache Oracle. Дополнительно. такая конструкция  потребляет лишнее процессорное время.   Кстати, это же справедливо  и для  СУБД DB2 -).   Многие заказчики почему-то забывали   про это, и данная рекомендация всегда была одной из первых которая выдавалась в случае наличия проблем.

Итак - вывод очевиден, теперь filesystemio_options=setall и никаких больше cio?
Однако инженеры IBM из Montpelier, считают по другому, их строгая рекомендация использовать  filesystemio_options=async и строго cio. Один из заказчиков попросил аргументировать.  Пожалуйста !

Итого, рассматриваем конфигурации:
#1, filesystemio_options=setall, опция монтирования rw
#2, filesystemio_options=async, опция монтирования  cio

Использовалась Oracle Database 11.2.0.2, AIX 7. Для начала мы провели эксперимент используется ли кэш файловой системы. Оказалось, что в обоих случаях он не использовался. Т.е. кажется что рекомендация #1 имеет право на жизнь. Правда при более внимательном рассмотрении оказалось, что при использовании рекомендации #1 ...не используется Async I/O. Мониторинг проводился командой:

iostat -A 1 | awk '/avg/ {if(x!=1){print; getline; print; x=1}else{getline; print}}'
aio: avgc avfc maxgc maxfc maxreqs avg-cpu: % user % sys % idle % iowait physc % entc
      0.0  0.0     0     0      48             0.3   1.8   97.9      0.0   0.0    4.4
      0.0  0.0     0     0      48             0.2   1.8   97.9      0.0   0.0    4.5

Данная команда показывает кол-во асинхронных операций ввода-вывода.  Опять нужно сделать небольшое отступление, что в AIX  есть несколько вариантов Async I/O. Исторически в AIX существали async I/O сервера и async I/O шел черех них (AIX 5). Однако позже (AIX 6) сделали  kernel async I/O для сырых устройств и, главное файловой системы.  Так вот оказывается, если у вас идет async I/O для сырых устройств то не нулевые значения появляются в колонке avfc, а если kernel file system asycn I/O то в колонке avgc.  В обоих случаях, если async I/O - kernel, то async I/O сервера (процессы aioserver)  не поднимаются.  Мониторить кол-во aio серверов удобно в nmon,  там показывают пиковое кол-во активных (в идеальном случае должно быть близким к 0).

При помощи команды lsof удалось выяснить, как именно открывает Oracle файлы данных в варианте #1:

oracle  39846142 oracle   12u  VREG     R,W,CIO,DSYN,LG,0x800000000;CX   39,1 1069555712   33 /oradata/data (/dev/dsvolkssdlv)



grep -i "0x800" vmount.h
#define VFS_DIO         0x80000000      /* O_DIRECT mount               */


На мой взгляд это объясняет все происходящее: вариант #1 работает с direct I/O, что для AIX не слишком оптимально.  Это значит, что все описанное в IBM whitepaper и MOS верно, но не самый оптимальный вариант. Вариант #2 сохраняет оптимальный ввод-вывод, формально называемый file system fast patch async I/O.

Резюме: пожалуйста продолжайте использовать опции монтирования cio для размещения файлов данных Oracle на AIX. 


Читать дальше...

DNFS

DNFS (direct NFS)  это новая возможность 11gR2, и надеюсь вы о ней слышали.   Все, что содержало  слово NFS для меня, как  способ хранения файлов  данных,  не существовало. Oracle тоже устал от не оптимальности протокола NFS  и решил включить поддержку прямо в ядро СУБД.

Все это было здорово, но как то меня не зацепило.  На этой неделе я  несколько раз натыкался на то, как же DNFS это здорово.

Для начала была статья  от компании Netapp, по ходу которой  выясняется, что DNFS over 10GBE  чуть ли не однозначно "рвет" все остальные комбинации.  Совершенно техническая статья, масса подобностей и параметров. OET на графике это число транзакций.


Я тут же вспомнил, что с помощью DNFS можно даже сделать  клон базы данных, не используя возможность storage (если storage этого делать не умеет). И наконец, благодаря опечатке Oracle в одном из патчей, можно было попробовать Hybrid Columnar Compression на таблицах, подключенных по DNFS. Это была бы серьезная заявка на победу DNFS над всеми остальными, но Oracle, к сожалению, опечатку исправил (я так думаю). 

Если вам все это понравилось, то рекомендую вот эту заметку для начала. 

Все круто. Можно брать. Остается две заминочки:

 - не нашел сравнения DNFS с iSCSI.
- не понятно как устроить требуемую балансировку сетевых адаптеров (или это все гораздо ниже лежит и можно выдать уже агрегированный link для использования Oracle  ? )

Желающие поделиться опытом - you are welcome !



Читать дальше...