something stupid

Документация на Oracle Database 11.1 обещала  нам:

ASM has the following limits:

• 4 PB maximum storage for each ASM disk 

Что было грубо разрушено: Bug 6453944: ORA-15196 WITH ASM DISKS LARGER THAN 2TB
Выпущенные патчи всего лишь перестали давать создавать такие диски и предотвращали потерю данных. Ладно, с кем не бывает.

Теперь документация 11.2 говорит нам:


Without any Oracle Exadata Storage, Oracle ASM has these storage limits:

• 2 terabytes (TB) maximum storage for each Oracle ASM disk
  

Ну это уже  за гранью добра и зла. Я понимаю, что HCC compression специально для Exadata, я понимаю, что Database Flash Cache только для Linux и Solaris, но оставить дурацкое ограничения в 2 Tb для всех кроме Exadata понять не могу. Почему это важно - хотелось бы иметь возможность устанавливать ASM поверх LVM томов без таких дурацких ограничений, хотя бы на некоторых операционных системах, например AIX. Тут есть тонкость - не всякие LVM тома одинаково полезны,  подходят только raw logical volume, сами volume group не подходят, поскольку ASM хранит свои метки в самом начале диска. Описание как собрать ASM поверх именно raw logical volume вы найдете здесь. Почему LVM ? Потом, что у нее есть масса своих достоинств (и даже больше, в AIX 7  includes enhanced support in the AIX Logical Volume Manager (LVM) for SSD)  включая и нормальный мониторинг I/O (iostat из asmcmd также пока за гранью разумного). Ограничение в 2 Tb оставляет нам возможность использовать только hdisks, на которые  ASM еще накрутит свой strip'инг - если бы такого ограничения не было бы просто сделали бы для каждой группы ASM один большой raw logical volume, все были бы счастливы.  Смысла накручивать поверх hdisks  LVM, а затем еще и ASM я пока не вижу. Тут поневоле задумаешься о том, что 'подавить' кэш файловой системы уж не такая и дурацкая задача даже для больших баз данных...

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

ASM - to be or not to be ?

Про ASM я уже писал несколько раз. Однако эта тема беспокоит людей, мы получаем много вопросов - следует использовать ASM или нет.

В книге Oracle Automatic Storage Management Bill Bridge пишет, что идея ASM возникла у него в 1996 году, когда он работал в проекте по внедрению Oracle Video Server. У них возникли проблемы с производительностью, из за того, что часть дисков оказалась перегружена, а часть простаивала. Тогда, идея, чтобы БД сама автоматически распределяла экстенты между всеми дисками показалась ему отличной.

В 1996 году еще не было Linux LVM (так думает википедея), SUN Microsystems еще не раздавала Solaris Volume Manager, а Windows еще не умела зеркалировать диски (так думаю я).

С тех пор, ОС сделали большой шаг вперед, и многие содержат встроенные средства зеркалирования и балансировки нагрузки между дисками. Но каждая ОС обладает своим особенным volume manager, а значит его нужно изучать.

ASM дает нам возможность использовать кросс-платформенное средство хранения наших файлов Oracle (данные, redo, archive log, control, backup. Все кроме binaries). А значит, время вложенное в ASM для администратора не пропадет, при изменении платформы.

Если функции зеркалирования и балансировки нагрузки выполняет Ваш умный дисковый массив, стоит ли Вам использовать ASM ? Стоит, но разумно. Стоит поручить массиву работу, которую он выполнить лучше чем софтверное решение, и при этом не потребит CPU вашего сервера БД. Т.е. в ASM нужно выдать 1 lun и создать на нем одну группу external redundancy для данных (возможно еще одну для FRA). Почему все таки не создать на этом lun обычную файловую систему ? Как видно из картинки, ASM минует несколько уровней системных вызовов, а поэтому окажется эффективнее. По производительности ASM приближается к производительности сырых (raw) устройств.

Когда стоит не использовать ASM ? Если у Вас куплен, например, Veritas Storage Foundation, Oracle Disk Manager, у Вас всегда используется только одна ОС, накоплен многолетний опыт работы с Veritas, очень серьезная по нагрузке БД - я бы рекомендовал продолжить работать с Veritas. Там есть некоторые приятные возможности по работе с группами, которых нет в ASM. Хочу уточнить, что ASM бесплатен, в отличии от весьма серьезных затрат на лицензии Veritas.

Еще один аргумент в защиту ASM - если ваша single instance уже использует ASM, то переход в RAC или на Exadata для Вас будет значительно облегчен.

Можно построить даже extended cluster используя ASM, а не покупая дорогостоящих дисковых подсистем с опциями синхронизации между площадками.

Если вы добавите диск в конфигурацию дисковой группы, ASM произведет перераспределение нагрузки между дисками. При этом, вы можете указать степень влияния процесса перераспределения на существующую систему. Насколько я принимаю, делать такое в ONLINE умеют только аппаратные массивы класса midrange и выше.

Несколько фактов использования ASM (Статистика основана на нашей внутренней информации. Пользователи могу использовать или не использовать ASM не уведомляя Oracle):

• В промышленной эксплуатации с 2004 года
• 65% инсталляций RAC используют ASM
• 25% исталляций 10g используют ASM

Много VLDB баз данных объемом до 10TB используют ASM.

Примеры серьезных инсталляций:

• Sprint - 300 TB data
• Amazon – 150 TB data

Здесь вы найдете массу технических деталей по ASM.

Ребята из CERN озаботились, а вдруг что-то случиться с заголовками дисков, где ASM хранит свою конфигурацию и надо будет достать данные. И разобрались, что к чему.

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

ASM, change host name

Когда Вы устанавливали ASM, чтобы позже разместить на нем свои файлы БД 11g, Вас очень просили выполнить скрипт $ORACLE_HOME/bin/localconfig add

Если Вы позже решите изменить имя вашего хоста, Вам после изменения необходимо будет выполнить
$ORACLE_HOME/bin/localconfig reset
$ORACLE_HOME/bin/localconfig add

Ну и конечно не забудьте проверить правильность /etc/hosts, listener.ora, tnsnames.ora

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

ASM tips

Несколько трюков с ASM:

1. Помните, что по умолчанию compatible для ASM 11g стоит в 10.2, а вовсе не в 11.1. Это значит, что пока Вы его не измените, новые возможности ASM у вас не появятся.
   
2. Начиная с 11g появилась возможность выполнить backup метаинформации ASM. Это крайне полезно, поскольку сохраняется информация об ASM disks, diskgroups, failure groups, templates, aliases, directory structure. Если Вы потеряте по какой-то причине дисковую группу, то данные конечно rman восстановить может, но все вышеперечисленное придется вспомнить. Backup/restore выполняются с помощью asmcmd md_backup/restore соответсвенное.
3. Начиная с 11g появилась команда asmcmd cp для копирования файлов между ASM и файловой системой, что значительно удобнее чем rman или ftp через XDB.е
4. Если вы хотите поиграться с ASM, но у вас нет большого числа raw устройств, вы можете эмулировать их, создав обычные файлы. Заполните их 0 с помощью dd, затем свяжите их с /dev/raw/rawN. В ASM init.ora вы должны поставить параметр _ASM_ALLOW_ONLY_RAW_DISKS=FALSE.
   

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

ASMlib

Существует убеждение, что ASMlib для Linux позволяет ускорить ввод-вывод. Это странно, но однозначного ответа получить нельзя. В презентациях иногда вспоминают это, иногда пропускают. Преподаватели на курсах имеют самые разные идеи насчет этого вопроса :)

За разрешением вопроса о том, что же далает ASMLIB обратимся к книге Oracle Automatic Storage Management. Поскольку один из авторов Rich Long, Director of Development, можно предположить, что это наиболее достоверный источник информации.

В книге утверждается, что ASMLIB обеспечивает следующие 3 основные функции (курсив мой):

1. Device discovery
1. Действительно, с помощью команды oracleasm можно создать asm диски, чтобы облегчить немного жизнь ASM. В заголовок диска прописывается специальная строчка, говорящая о том, что следует адресоваться к диску с помощью asmlib. Далее в параметре ASM инстанс необходимо прописать asm_diskstring="ORCL:*" чтобы предотвратить открытие всех дисков для поиска необходимых ASM. Более подробно можно прочитать http://www.oracle.com/technology/tech/linux/asmlib/persistence.html
   Но в принципе, udev делает тоже самое (?)
   
   
   
2. I/O processing
1. Cокращается число file handler в системе. Для каждого диска существует всего лишь один, так называемый "portal device", через который ведется весь ввод-вывод. С одной стороны, это полезно чтобы не подкручивать лимиты ОС. С другой стороны, если файлы открываются, то их нужно и закрывать, а это не все процессы делают. Мне говорили, что замена ASM диска без ASMlib может стать проблемой, если дисков очень много.
   
2. ASMLIB не использует kernel async IO. Используется собственный механизм вводы-вывода, также асинхронный. надеюсь, что он быстрее чем родной, ведь его не просто так написали ?
   
   
3. Perfomance
1. Делается меньше переключений контекста, что экономит CPU time. Верю, но почему не воспользовались интерфейсом ODM, который реализовал, например, Veritas ?
2. За один вызов к asmlib можно выполнить несколько операций I/O. Наверно для full scan можно, а вот для чего еще это работает я понять не могу.

Почему меня так беспокоит весь этот гондурас ?

Если бы видели матрицу поддержки EMC powerpath ASMlib он вас тоже бы беспокоил.
Через версию они (EMC) все ломают. Апофеозом борьбы можно считать Note:469163.1
которая рекомендует игнорировать все происки врагов и использовать лом:
/usr/sbin/asmtool -C -l /dev/oracleasm -n -s /dev/ -a force=yes

Вот только зачем, если у Вас не тысячи пользователей и сотни файлов ?
Из-за экономии 10% CPU при следующем upgrade powerpath можно потерять свои диски...

Резюме:

Посмотрите сначала на поддержку ASMLIB на вашей платформе. Посмотрите на кол-во дисков и пользователей. Взвесьте все "за" и "против" - теперь Вы их знаете. В любом случае вы всегда можете мигрировать raw устройства в asmlib диски без потери данных. Дело в том, что в первых 128 байтах на диске находится название дисковой группы и признак, управляется ли этот диск asmlib. Так что oracleasm createdisk всего лишь проставляет признак, не разрушая название группы.

Update 1.
Для чтение заголовков ASM дисков у нас существует редактор kfed. К сожалению описание самого заголовка internal only. Можете поэкспериментировать сами :)

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

ASM or raw devices ?

Услышал очень емкую фразу про сравнение производительности ASM и сырых (raw) устройств:

"ASM не производит никаких операций ввода-вывода - поэтому сохраняет производительность сырых устройств"

Действительно (хотя я не смог явно найти этого в документации) регулярный ввод-вывод (т.е. то что делает DBWR или LGWR) как производился этим процессами так и производится. Другое дело, что ASM обеспечивает карту - т.е. куда именно следует записать. Картинка из презентации справа иллюсстрирует тоже самое.

Хорошее описание с правильным (я надеюсь) описанием также можно взять здесь:

AcingASM.pdf (application/pdf Object)

Из картинки мне кажется ясно следует, что только первоначальную разметку и создание/увеличение файлов делает ASM.

Раз так, то мне кажется нет смысла держать БД на raw устройствах.
Естественно, поскольку mirrroring & striping делается на прикладном уровне - это не очень быстро.
Так что если есть возможность - конечно лучше отдавать mirrroring & striping дисковому массиву. Опять таки статистики с массива по вводу выводу можно получить более разумные. Тут есть еще один не однозначный для меня ход :)

ASM всегда делает страйпинг. Таким образом если вы используете возможности массива в ваших дисковых группах должен быть всегда только 1 диск. В противном случае, если появится другой - начнется ребалансинг а затем и страйпинг. Добавление места должно осуществляться только путем расширения этого одного диска.

Опять таки, из-за того что ASM всегда делает страйпинг кажется, что если в дисковой группе будет два разных по объему диска, то будет использоваться только меньший объем. И даже больше - отличное замечание про размер дисков.


Другое дело - сравнение ASM с Volume Manager'ами.
Да, конечно в 11g появилось preferred mirror read, мы потихонечку догоняем функциональность VM, но пока только догоняем.
Мне также обещают прислать сравнение по скорости, где ASM выигрывает у Veritas VM.
Но по гибкости управления ASM все еще проигрывает. Опять таки в 11g в asmcmd появилась возможность копировать файлы данных между ASM и файловой системой.
Но те кто занимаются storage'ами конечно знают, что необходимо гораздо больше возможностей.

Но ASM бесплатно - а промышленные Volume Manager стоят существенные деньги.
Так что у каждого продукта свой круг пользователей.

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

ASM: to be or not to be

Замечательный пример, того, как вендор, в данном случае NetApp, показывает свое решение по управлению данными, не противопоставляет его ASM, а дополняя.

Так например, комбинируя ASM и FlexClone действительно удобно делать мгновенные снимки системы, используя их
как backup, или источник данных для тестовых баз. Идея в том, что такие мгновенные снимки занимаю гораздо меньше места чем традиционный backup. Или использовать SnapValidator для проверки битых блоков на аппаратном уровне (т.е. железо умеет считать контрольную сумму блока данных СУБД). Или использовать NetApp RAID-DP для double disk parity protection, чего ASM делать в принципе не умеет.

Важно следующее - NetApp спокойно излагает аргументы, почему необходимо заплатить еще и за его решение.
Наверно, другой вопрос, сколько заплатить :)

wp-7009-oracle-asm.pdf (application/pdf Object)


Да, ASM становится все умнее, быстрее и лучше, но аппратный вендор всегда сможет предложить нечто свое, уникальное.

Зачем тогда вообще нужен ASM спросите Вы ?
Мне кажется, что как минимум из-за унификации работы с БД. Вы захотите использовать другую ОС, дисковый массив, но с ASM вам не придется переделывать ланшафт БД, срипты или переучиваться.

PS
Я кстати работал с Data ONTAP® правда еще 6 версии. Мне лично очень понравилось это решение.

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