Мой новый Oracle DBA говорит о смысле

Когда мы настраиваем FC LUN для наших блоков MSSQL, нам редко приходится представлять им более 8 различных LUN различных видов (Quorum, MSDTC, TempDB, Data, Logs, Backup и некоторые другие).

У нас есть новый Oracle DBA, и он дал мне список LUN, которые он хочет для своего первого нового сервера - их 38! и это для действительно базового блока БД, только с одной БД. Все они довольно маленькие (100 ГБ) LUN, и они явно объединяются, используя ASM в стиле LVM.

Это лучший способ сделать это, я действительно не эксперт Oracle, но мне кажется, это слишком сложно, что вы думаете по этому поводу?

Я администратор базы данных Oracle. Ваш новый администратор баз данных действует как администратор баз данных Oracle, а не инженерный.

1. Никакому оракулу НЕ нужно 38 ЛУН. Я распространил файлы данных на большое количество луны, но они на ОЧЕНЬ активных и ОЧЕНЬ больших системах. LUN не обязательно отображаются на новые группы RAID, верно? Так что наличие файлов на отдельных лунах не обязательно в любом случае распространять (я не эксперт в этом).

2. Весь этот вид чередования файлов сделает намного больше работы для администратора баз данных. Это увеличивает его важность для команды. Многие администраторы БД Oracle стараются казаться более важными и перегруженными вещами ВСЕ ВРЕМЯ.

3. Разделение данных на различные группы рейдов / лун не является специфическим для оракула. Это основано на использовании. Чтобы правильно распределить файлы, вашему администратору БД необходимо было понять приложение, чтобы знать, к чему обращаются много времени (кстати, отделение индексов от данных НЕ повышает производительность, так как доступ является последовательным ...). Он знает приложение? Он просмотрел базу данных, чтобы увидеть, к каким объектам часто обращаются? Что нужно разложить? Что делает массовая запись и чтение, и должна быть изолирована.

Это звучит как база данных малого / среднего размера. Каков уровень активности? Он, вероятно, не знает.

Как правило, для небольших баз данных вам не нужно много делать на уровне файловой системы, чтобы повысить производительность. 95% - это SQL, и разработчики запускают слишком много SQL-операторов в циклах.

редактировать ( годы спустя !):

Я провел некоторое время, общаясь с инженерами SAN, и несколько улучшил свои знания о SAN и LUN с момента публикации этого сообщения. Прежде всего, LUN - это «логично». Нет необходимости сопоставлять отдельные группы RAID, диски и т. Д. Это настраивается инженером SAN и не будет виден администратору БД. Есть много больше, чтобы выделить IO в SAN, что большинство людей понимают.

Я работаю над очень большими системами, которые имеют очень высокий уровень активности. У нас есть сотни LUN, RAID-групп и т. Д., Мы распространяем файлы повсюду. Мы работаем с инженерами SAN, чтобы настроить LUN для обеспечения их распространения в разных частях SAN. У нас действительно НЕТ видимости того, как LUN отображаются на уровне операционной системы. Новая файловая система не означает, что у нас есть данные, сопоставленные с новым местоположением в SAN.

Что касается бумаги HP о чередовании ASM. Это совершенно бессмысленно при работе с SAN. Чередование, зеркалирование, RAID и т. Д. - все это делается под поверхностью. Вы не увидите его на уровне приложения или базы данных. Настройка Oracle ASM для «чередования» в SAN бессмысленна, поскольку вы будете просто чередовать логические тома, которые могут использовать конфигурацию RAID 5 (подавляющее большинство из-за затрат на управление. SAN - это многомиллионные инвестиции). Вы просто увидите файловые системы. Они не обязательно отображаются на разные диски или в разные места в SAN.

Очевидно, у IBM есть новая функция, которая позволяет SAN решать, куда записывать диски, основываясь на активности. Я хочу сказать, что люди, которые оптимизируют SAN, являются специалистами. Вам нужно работать с ними. Администратор базы данных или разработчик приложения не смогут увидеть, распространяется ли что-либо.

Из того, что я видел, в большинстве магазинов нет очень хороших инженеров SAN. Это, как правило, работа для людей младшего уровня. Большинство из них, как правило, являются консультантами. Поэтому в большинстве случаев вы просто используете настройки по умолчанию, установленные производителем. Повторное добавление большего количества LUN, вероятно, не приведет к распространению каких-либо данных, если только у вас нет инженера SAN, который настроил бы его для вас под поверхностью. Вдобавок ко всему, вы можете иметь 1 LUN и распространять его для вас. Если у вас нет хорошего инженера SAN, все это бессмысленно. Для меня очевидно, что рассматриваемый администратор баз данных недостаточно знает о SAN, чтобы даже знать, что он ничего не знает.

99,9% стандартных конфигураций времени просто отлично. Если у вас нет определенного узкого места ввода-вывода, это не нужно. Если да, то вам нужно поработать с инженером SA и SAN, чтобы определить, в чем проблема. Много времени это не имеет никакого отношения к макету SAN. Опять же, администраторы баз данных и разработчики не будут иметь доступа к просмотру того, что происходит, не говоря уже о знаниях, чтобы понять это. SAN очень сложны.

Вы можете попытаться ударить его по голове ЭТИМ , описывая ОДИН И ТОТ ЖЕ (Stripe And Mirror Everything) подход, который очень прост.

У меня нет прямого ответа, потому что мы используем MSSQL и mySQL. Но всякий раз, когда мой администратор БД просит что-то, что звучит просто безумно ... вот так. Я требую, чтобы он задокументировал, почему каждая часть требуется. Это служит двум целям: однажды они внезапно меняют свое мнение на что-то более вменяемое, а две позволяют мне увидеть их мыслительный процесс, чтобы я мог применить системную логику к тому, что они хотят, и представить альтернативу, которая не так уж и плоха. , Так что в этом случае я бы попросил документ, обосновывающий необходимость каждого из 38 LUN

Есть исследования, которые показывают, что чередование в ASM и на аппаратном уровне может быть преимуществом для производительности. Технический документ HP-Oracle Эти улучшения производительности в основном наблюдаются в ситуациях с высоким параллелизмом, что не похоже на то, что вы ожидаете. Но может быть то, к чему привык ваш DBA.

Я знаю, что для DB2 в AIX наши администраторы баз данных получают по 5 томов на базу данных - каждый для своей части базы данных. Один для БД, один для основного журнала, один для архивного журнала, временный файл и что-то еще. Это тома, они не обязательно должны быть LUN, это зависит от того, как вы хотите управлять своим хранилищем.