Когда мы настраиваем FC LUN для наших модулей MSSQL, нам редко приходится предоставлять им более 8 отдельных LUN различных типов (Quorum, MSDTC, TempDB, Data, Logs, Backup и некоторые другие).
У нас есть новый администратор базы данных Oracle, и он дал мне список LUN, которые он хочет использовать для своего первого нового сервера - их 38! и это для действительно базовой коробки БД, только с одной БД. Все они довольно маленькие (100 ГБ) LUN, и они явно соединяются вместе с помощью ASM по типу LVM.
Это лучший способ сделать это, я на самом деле не эксперт по Oracle, но мне это кажется слишком сложным, что вы думаете и испытываете по этому поводу?
Я администратор базы данных Oracle. Ваш новый администратор баз данных действует как многие администраторы баз данных Oracle и занимается разработкой.
НИ ОРАКУ НЕ НУЖДАЕТСЯ 38 LUN. Я распространил файлы данных на большое количество LUN, но они находятся в ОЧЕНЬ активных и ОЧЕНЬ больших системах. LUN не обязательно должны отображаться в новые группы RAID, верно? Таким образом, наличие файлов на отдельных lun'ах в любом случае не обязательно что-либо распространять (я не эксперт в этом).
Этот вид чередования файлов сделает гораздо больше работы для администратора базы данных. Это увеличивает его важность для команды. Многие администраторы баз данных Oracle ВСЕГДА пытаются казаться более важными и чрезмерно занимаются проектированием.
Разделение данных по разным группам рейдов / логам не зависит от Oracle. Это основано на использовании. Чтобы правильно разложить файлы, ваш администратор баз данных должен понимать приложение, чтобы знать, к чему осуществляется доступ (кстати, отделение индексов от данных НЕ улучшает производительность, поскольку доступ является последовательным ...). Он знает приложение? Смотрел ли он в базе данных, чтобы узнать, к каким объектам часто обращаются? Что нужно разложить? Что массово пишет и читает и что нужно изолировать.
Это похоже на базу данных малого / среднего размера. Какой уровень активности? Он, наверное, не знает.
Как правило, для небольших баз данных вам не нужно много делать на уровне файловой системы для повышения производительности. 95% - это SQL, и разработчики запускают слишком много операторов sql в циклах.
редактировать (годы спустя!):
Я потратил некоторое время на разговоры с инженерами SAN и несколько улучшил свои знания о SAN и LUN после публикации этого сообщения. Во-первых, LUN «логичен». Нет необходимости отображать на отдельные группы RAID, диски и т. Д. Это настраивается инженером SAN и не будет отображаться для администратора базы данных. Большинство людей понимают, что разделение операций ввода-вывода в 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 Такой прирост производительности в основном наблюдается в ситуациях с высоким уровнем параллелизма, чего вы не ожидаете. Но, возможно, это то, к чему привык ваш администратор базы данных.
Я знаю, что для DB2 на AIX наши администраторы баз данных получают по 5 томов на базу данных - каждый для отдельной части базы данных. Один для БД, один для первичного журнала, один для архивного журнала, временный и что-то еще. Это тома, они не обязательно должны быть LUN, это зависит от того, как вы хотите управлять своим хранилищем.