Oracle-club: FAQ - Применения Raid к технологиям БД ORACLE.

Распределение обьектов ORACLE.

Дискуссия в relcom.comp.dbms.oracle - март 1999


Затравка:

Часто рекомендуется разносить tablespaces and so on по различным физическим дискам. Совершенно не понятно как это может повлиять при работе с RAID уровня 5 (весьма и весьма распостраненная схема для серьезных серверов баз данных) - кажется данные в этом случае и так будут разнесены по разным дискам ?

Ответы:

Не всегда правильно держать базы на 5-ом райде. По данному вопросу - сколько людей, столько и мнений. На любой поисковой системе запрос по +(database storage) +RAID даст столько ссылок, что прочитать и осознать будет сильно затруднительно. Удачного распределения. -- romas mailto:my-pager@iname.com
From: "Mich" >Не всегда правильно держать базы на 5-ом райде. >По данному вопросу - сколько людей, столько и мнений. Почему же, кажется, мнения по поводу RAID5 вполне определенные. Исходя из того, что каждая операция записи на нем, фактически = 4 операциям ввода-вывода, то можно себе представить, как будет жить OLTP на 5RAID :) По моим впечатлениям, тормоз он порядочный. Хотя надежный - спасу нет..... А вообще, обычно, люди просто разносят разные файлы по разным RAID levels. Ну не нравится мне rollback & online redo на raid5 - медленно.... >На любой поисковой системе запрос по +(database storage) +RAID >даст столько ссылок, что прочитать и осознать будет сильно >затруднительно. Удачного распределения. >> кажется данные в этом случае и так будут разнесены по разным дискам ? Разумеется. По моему, явно всегда и пишут, что разнесение файлов по разным физ. устройстван касается только дисков, не объединенных в RAID0,3,5 Вот зеркалки разносить можно :)
> >Не всегда правильно держать базы на 5-ом райде. > >По данному вопросу - сколько людей, столько и мнений. > > Почему же, кажется, мнения по поводу RAID5 вполне определенные. > Исходя из того, что каждая операция записи на нем, фактически = 4 операциям > ввода-вывода, > то можно себе представить, как будет жить OLTP на 5RAID :) По моим Сильно зависит от рэйда. Живет вот и ничего. > впечатлениям, тормоз он порядочный. Хотя надежный - спасу нет..... Вот-вот тут каждый для себя решает, что важнее надежность или тормоза 8-) Отсюда и мнения. Правда мнение о надежности софтверных рэйдов на солярисе у меня сильно пошатнулось последнее время. > А вообще, обычно, люди просто разносят разные файлы по разным RAID levels. > Ну не нравится мне rollback & online redo на raid5 - медленно.... Ну разговор-то только про даные идет. Требуху конечно надо держать не на 5-ом рэйде. А вот держать редо на простых дисках опасно, нужно либо на ленте копии держать, либо архив за день в надежном и доступном месте, ибо без них тяжко будет восстанавливаться. Все вышесказанное - мое личное мнение, не обязательно воспринимать это как указание к действию. -- romas mailto:my-pager@iname.com
Mich wrote: > > > > >RAID-5 при на операциях записи всегда будет тормозом, независимо от > >того, программный или аппаратный. В любом случае RAID-0 самый быстрый. > > гм... или я гоню, или его ( RAID0) можно зазеркалить и получить надежность + > производительность..... > за много-много зеленых рублей :-) Все правильно, получится. Насчет зеленых рублей; их можно сэкономить, если дополнительные диски купить за счет аппаратного RAID. Считать надо. -- Andrew Lesnichenko
Итак, если я правильно понял, то следует использовать RAID контроллер, но RAID 5 только на редко изменяемых данных. RAID 10 же использовать для управляющих и журнальных файлов ? В связи с этим вопрос - Какой нужен аппаратный RAID контроллер для такой конфигурации и какое сочетание дисков рекомендуется использовать (общий объем базы не более 80Гб, кол-во одновременно работающих пользователей - не более 100) ? Кроме того, в связи с тем, что планируется приобретение нового сервера, то что лучше - 1) использовать недорогой RAID5 контроллер, а OLTP перенести просто на 2 диска с программным mirroring. Но зато приобрести крутой стриммер или 2) купить контроллер покруче и обойтись дешевым стриммером ? И то и другое хочется, но колется :(( КСТАТИ, А КАК НАСЧЕТ ИСПОЛЬЗОВАНИЯ DVD-RAM КАК СРЕДСТВА АРХИВИРОВАНИЯ ХОТЯБЫ ВСЯКИХ ТАМ LOG-файлов (на них-то 5,6 Гб RAM диска вроде и так хватит, а о данных пусть RAID5 как раз и заботиться. Конечно архивировать и их надо, но значительно реже) ? Может ну его к чертям всякие там ленточки, а то перематывай их .... With best regards, Sergey.
Sergey wrote in message news:7dateq$o1n$1@prince.dataforce.net... > > Итак, если я правильно понял, то следует использовать RAID контроллер, но > RAID 5 только на редко изменяемых данных. RAID 10 же использовать для > управляющих и журнальных файлов ? В целом правильно. > В связи с этим вопрос - Какой нужен аппаратный RAID контроллер для такой > конфигурации и какое сочетание дисков рекомендуется использовать (общий > объем базы не более 80Гб, кол-во одновременно работающих пользователей - не > более 100) ? Платформа какая? 80Гб - это обьем чистых данных или данные + Index Вообще 80Г Это очень приличная база. Тут крайне желательно мно-го мно-го дисков, не из-за размера, А для распараллеливания i/o. Разница что при использования RAID - об этом думает железо (Или софт), а если просто SCSI контроллер то приходится думать тебе. Кроме-того сколько пользователей будет работать одновременно, характер их работы и т.д. Если есть работающая система, то крайне желательно помониторить ее. Прежде всего: зависимость от количества пользавателей и характера их работы a) операторы ( update ). b) batch процедуры ( Загрузка данных, вывод тяжелых отчетов) и т.д. с) Разработка ( compile procedure ) .... Мониторятся i/o - read/write Kb/s - пропускная српособность шин и контроллеров i/o - transaction /s - количество физических дисков ( В зависимости от типа диска, это от 50-250 операций в сек. ) %cpu - количество процессоров в системе. Использование памяти... из этого можно хотя бы приблизительно определить какая аппаратура нужна. Какой обьем активных данных. Например могут лежать огромные архивы за прошлые года к ктороым обращаются раз в пятилетку, а рабочая область 200-300 метров. Кстати очень распространенный вариант. От этого зависитт сколько памяти отдать на буфера. Oracle рекомендует не меньше 10% от активных данных. :) Способ сохранения данных зависит от времени востанавления при сбоях. Учитывай что ломаются не только диски, но и машины. (Учитавая что стоимость решения при уменьшении времени простоя растет в геометрической прогрессии). 1) Подумать о standby database. + RAID-0 ( ИЛи ручками разложить по дискам ) 2) RAID-10 + tape full backup ( смотри 80Гиг, сколько ленточек тебе понадобится?) 3) RAID-10 + tape imp ( примерно в 10 раз меньше при паковке. сколько ленточек тебе понадобится?) Но время востановления ... 4) RAID-0 ( ИЛи ручками разложить по дискам ) + imp на ленту. Самый дешовый вариант. Разумеется справочники на RAID-5 ( Если RAID-10) Не хило работает и Read-Only tablespace > КСТАТИ, А КАК НАСЧЕТ ИСПОЛЬЗОВАНИЯ DVD-RAM КАК СРЕДСТВА АРХИВИРОВАНИЯ > ХОТЯБЫ ВСЯКИХ ТАМ LOG-файлов (на них-то 5,6 Гб RAM диска вроде и так хватит, > а о данных пусть RAID5 как раз и заботиться. Конечно архивировать и их надо, А о сервере тоже RAID заботится будет? Best regards, Vadim Lejnin Oracle and Unix Administrator company FORS Technical Support Department Phone: 788-07-60/72/73/74/75 E-mail: support@fors.ru, lejnin@fors.ru icq#20256486
Hi, продолжая thread :) Sergey wrote: > > Итак, если я правильно понял, то следует использовать RAID контроллер, но > RAID 5 только на редко изменяемых данных. RAID 10 же использовать для На редко изменяемых или изменяемых большими кусками (скажем от 5..10 размеров стрипа). > управляющих и журнальных файлов ? Не совсем так, для управляющих и журнальных файлов идеальный вариант - дуплексирование средствами Oracle на отдельных винчестерах. Это связано со следующим: объем записи в них относительно маленький и применение чистого стрипа эффекта не даст. А использование программного мирроринга по сравнению с аппаратным (именно в этом случае) имеет ряд дополнительных преимуществ по надежности. > В связи с этим вопрос - Какой нужен аппаратный RAID контроллер для такой > конфигурации и какое сочетание дисков рекомендуется использовать (общий > объем базы не более 80Гб, кол-во одновременно работающих пользователей Про аппаратный RAID-контроллер я говорить не буду - боюсь вызвать флейм. Однако решения от MYLEX, несмотря на относительную дороговизну и не самый писк моды могу считать приемлимыми в силу большого опыта использования. Распределение по дискам зависит от требований к работе и простоям. Есть несколько вариантов, линейно располагающихся по шкале Произволительность .... Надежность (скорость восстановления). При этом редко изменяемый tablespaces нужно класть на RAID-5, а часто изменяемые можно на стрип. Но опять же - все зависит от требование бизнеса. - не > более 100) ? > > Кроме того, в связи с тем, что планируется приобретение нового сервера, то > что лучше - 1) использовать недорогой RAID5 контроллер, а OLTP перенести > просто на 2 диска с программным mirroring. Но зато приобрести крутой > стриммер или К программному миррору у меня не очень хорошее отношение. Вообще IMHO, использование RAID через средства ОС большая глупость и может применяться только в случае колоссальной нехватки средств. И еще, планировать БД на 80 Гб и говорить о сильной нехватке средств - странно (не посчитайте за обиду - просто на таком объеме данных экономия рано или поздно вылезет, да так что мало не покажется) > 2) купить контроллер покруче и обойтись дешевым стриммером ? > И то и другое хочется, но колется :(( > > КСТАТИ, А КАК НАСЧЕТ ИСПОЛЬЗОВАНИЯ DVD-RAM КАК СРЕДСТВА АРХИВИРОВАНИЯ > ХОТЯБЫ ВСЯКИХ ТАМ LOG-файлов (на них-то 5,6 Гб RAM диска вроде и так хватит, > а о данных пусть RAID5 как раз и заботиться. Конечно архивировать и их надо, > но значительно реже) ? > Может ну его к чертям всякие там ленточки, а то перематывай их .... Для такого объема данных рекомендую решение от DLT в комбинации с автолоадером. А через схему Recovery Manager + Jobs можно организовать корректно автоматизированный полный бэкап скажем ночью. > > With best regards, Sergey. С наилучшими пожеланиями, Евгений Фаддеенков
Andrew Lesnichenko wrote: > > Evgeny Faddeenkov wrote: > > > > К программному миррору у меня не очень хорошее отношение. > > Вообще IMHO, использование RAID через средства ОС большая глупость > > и может применяться только в случае колоссальной нехватки средств. > > Это почему ? Еще раз подчеркну, что это глубоко IMHO, однако рассматривая вопросы производительности и надежности могу заметить следующее: 1) при реализации RAID средствами ОС падает производительность сервера (процессоры, шины, память нагружены дополнительными задачами). Причем для реализации RAID-5 дополнительную загрузку процессора сложно назвать незначительной. 2) у меня был опыт на Solaris 2.5 на SPARC, когда после некоторого набора операций том стал invalidate и восстановить его мы не смогли. Хочу заметить что после этого случая на этой же платформе нормально работает несколько томов со стрипом и все Ok уже в течение нескольких лет. 3) Изоляция компонент (инкапсуляция) - принцип современного построения систем. При использовании аппаратного контроллера, специально оптимизированного именно под выполнение этих задач и скрывающего внутреннюю структуру разбивки от ОС - мы добиваемся этого. > > -- > Andrew Lesnichenko --- Евгений Фаддеенков
Sergey wrote: > > Итак, если я правильно понял, то следует использовать RAID контроллер, но > RAID 5 только на редко изменяемых данных. RAID 10 же использовать для > управляющих и журнальных файлов ? > В связи с этим вопрос - Какой нужен аппаратный RAID контроллер для такой > конфигурации и какое сочетание дисков рекомендуется использовать (общий > объем базы не более 80Гб, кол-во одновременно работающих пользователей - не > более 100) ? > > Кроме того, в связи с тем, что планируется приобретение нового сервера, то > что лучше - 1) использовать недорогой RAID5 контроллер, а OLTP перенести > просто на 2 диска с программным mirroring. Но зато приобрести крутой > стриммер или > 2) купить контроллер покруче и обойтись дешевым стриммером ? > И то и другое хочется, но колется :(( 1. Да, RAID-5, в силу высокого объема вычислений при записи подходит лишь для данных для чтения. При этом софтверный RAID будет грузить процессоры. 2. Со всех точек зрения, кроме стоимости, наилучшее решение - RAID-0+1. 3. На мой взгляд, вопросы RAID-контроллера и стриммера друг с другом не связаны. Здесь другой момент: можно выбирать между контроллером с меньшим кол-вом дисков, которого не хватит для полноценного mirror'а, и софтверным RAID'ом, но с большим кол-вом дисков. Вы можете не тратиться на аппаратный RAID и купить больше дисков. Это позволит вам на софтверном RAID'е сделать полноценный 0+1. Имея опыт работы с Veritas Volume Manager'ом могу назвать следующие преимущества: 3.1. RAID 0+1 имеет наивысшую производительность и надежность. 3.2. Софтверный RAID великолепно управляется. Плюс к тому, имея зеркало вы можете делать практически любые переконфигурации дисков на ходу. Это очень удобно, поскольку гарантированно, что вы с первого раза не угадаете правильное распределение данных по дскам. 3.3. Указанный Veritas является стандартом де-факто в индустрии и поддерживает множество аппаратуры и вы оказываетесь практически аппаратно независимы. Т.е. вы не зависите от этих ящичков с дисками с названиями, типа Storage Array, Mass Storage и пр., что может пригодиться, когда вам понадобится upgrade. 3.4. Производительность. Естественно аппаратный RAID разгружает процессор, но здесь нужно смотреть конкретные цифры. Нагрузка на проц. от софтверного решения не так велика, как может показаться поначалу. При нынешних вычислительных мощностях хостов и технологиях массовых накопителей, решить проблему производительности дисковых накопителей может только кэш контроллера, а он редко бывает больше одного-двух десятков мегабайт, что при вашем размере базы может быстро привести к тому, что I/O будет происходить непосредственно "с пластин", а это обычно 50 операций в секунду (service time у команды iostat - 20 миллисекунд). Поэтому, ваши процессоры будут в состоянии ожидания I/O. Почему бы их не загрузить софтверным RAID'ом ? Я сомневаюсь, что алгоритмы работы аппаратного RAID'а кардинально производительнее софтверного, а объем памяти и процессор контроллера дороже модифицировать, чем докупить CPU/memory в хост. 4. Стриммер. Нужен для складывания archived logs и для backup (лучше иметь два). Выбор его не связан с дисковой подсистемой и определяется ИСКЛЮЧИТЕЛЬНО: 4.1. Размером базы и окном времени backup'а. 4.2. Объемом набегающих логов. 4.2. Стоимостью данных (сколько денег потеряете из-за потери данных, или простоя системы). IMHO, под этот объем вам нужно что-то с DLT-7000 стриммером (если у вас безостановочная сиистема) - 35G емкость ленты и 5М/c скорость записи. Технология очень надежна (в смысле кол-ва перезаписей на один накопитель и в смысле времени хранения данных), и очень прогрессивна (в смысле морального устаревания). > КСТАТИ, А КАК НАСЧЕТ ИСПОЛЬЗОВАНИЯ DVD-RAM КАК СРЕДСТВА АРХИВИРОВАНИЯ > ХОТЯБЫ ВСЯКИХ ТАМ LOG-файлов (на них-то 5,6 Гб RAM диска вроде и так хватит, > а о данных пусть RAID5 как раз и заботиться. Конечно архивировать и их надо, > но значительно реже) ? > Может ну его к чертям всякие там ленточки, а то перематывай их .... По стоимости хранения данных лентам равных нет и судя по всему, надолго. 5Мб/с (это 300 Мб/мин) вас устроит ? У вас либо интерфейс такую скорость не потянет, либо диски не поспеют. Старый конь борозды не испортит. -- Andrew Lesnichenko
Sergey wrote in message news:7da50h$ga6$1@prince.dataforce.net... > Часто рекомендуется разносить tablespaces and so on по различным физическим > дискам. > Совершенно не понятно как это может повлиять при работе с RAID уровня 5 > (весьма и весьма распостраненная схема для серьезных серверов баз данных) - > кажется данные в этом случае и так будут разнесены по разным дискам ? Совершенно верно > > По поводу применения RAID для Oracle, Существует множество мнений, но в целом можно сказать следующее: 1) Для массированных OLTP необходимо применение RAID-10 (RAID-0+1) Это комбинация mirror + strip При этом желательно указать размер strip блока=db_block_size=block_size_filesystems 2) Для данных к которым выполняется только read-only доступ, или update незначительный, допустимо применение RAID-5 3) Для массированных заливок strip_block должен иметь максимальный размер. -- Best regards, Vadim Lejnin Oracle and Unix Administrator company FORS Technical Support Department Phone: 788-07-60/72/73/74/75 E-mail: support@fors.ru, lejnin@fors.ru icq#20256486
Vadim Lejnin wrote: > > Sergey wrote in message > news:7da50h$ga6$1@prince.dataforce.net... > > Часто рекомендуется разносить tablespaces and so on по различным > физическим > > дискам. > > Совершенно не понятно как это может повлиять при работе с RAID уровня 5 > > (весьма и весьма распостраненная схема для серьезных серверов баз > данных) - > > кажется данные в этом случае и так будут разнесены по разным дискам ? > Совершенно верно > > > > > > По поводу применения RAID для Oracle, Существует множество мнений, > но в целом можно сказать следующее: > > 1) Для массированных OLTP необходимо применение RAID-10 (RAID-0+1) > Это комбинация mirror + strip > При этом желательно указать размер strip > блока=db_block_size=block_size_filesystems > 2) Для данных к которым выполняется только read-only доступ, или update > незначительный, > допустимо применение RAID-5 > 3) Для массированных заливок strip_block должен иметь максимальный размер. Я бы сказал, что независимо от операций, stripe size должен быть равен тому размеру, который контроллер может читать/писать за одну операцию. Определяется конкретным диском. Часто это размер цилиндра. Или размер буфера непросредственно в контроллере диска. Andrew Lesnichenko
> При этом желательно указать размер strip > блока=db_block_size=block_size_filesystems > Я бы сказал, что независимо от операций, stripe size должен быть равен > тому размеру, который контроллер может читать/писать за одну операцию. > Определяется конкретным диском. Часто это размер цилиндра. Или размер > буфера непосредственно в контроллере диска. 1) Тут есть неувязка. Например для Oracle for Nowell по умолчанию db_block_size=4096 и db_block_size '='/'кратен' Block size Netware volume, который ну ни как не равен размеру цилиндра, например: (4096|8192|16384..) и (~ 512|1024). Рассмотрим типичный пример Raid5 c 5 дисками. В Raid5 передаваемый блок, размером stripe size пишется целиком на одном диске, информ-я о четности этих устройств для блоков данных расположена на другом диске. Задача: За одну Raid-операцию записать db_block_size байт на одно устройство в Raid-массиве. Пусть db_block_size=Block size Netware volume=4096. Если на запись прийдет 4096 байт(db_block_size), то Raid контроллер co strip size=512 разобьет этот пакет на 8 блоков и их запишет(в четыре операции каждую), что приведет к падению производит-ти в 8 раз по сравнению со strip size=4096. Т.е. я считаю что здесь необходимо именно: stripe size = Block size Netware volume = db_block_size 2) Кстати, в руководствах по Tuning Oracle говорят о striping factor. По их руководствам stripe size = striping factor* Block size(Cylinder). А типичный striping factor - 32 блока. Следовательно, если принять Block size= 512|1024 bytes (зависитот модели и производителя): stripe size = 32 * 512|1024 = 16|32 Kb. 3) Также необходимо расчитаь кол-во дисков в Raid для покрытия необходимого уровня ввода-вывода. Предположим нам необходимо поддерживать 250 произвольных I/O в сек. к файлам данных. Эти I/O бьем на 125 записей в сек. и 125 чтений в сек.(Raid-5). Напомню, Процесс записи Raid 5 состоит: 1. Считать старые данные. 2. Считать старый код четности. 3. Записать новые данные. 4. Записать новый код четности. В принципе можно проанализировать и для других Raid: 3.1) I/O сгенерированные Raid. Уровень RAID I/O на запись I/O на чтение RAID-0 1 1 RAID-1 2 1 RAID-5 4 (2 Reads, 2 Writes) 1 3.2) I/O Raid'ов в 125 чтениях в сек. и 125 записях в сек. Уровень RAID Запись/sec Чтений/sec Всего/sec RAID-0 125 125 250 RAID-1 250 125 375 RAID-5 250 125 + 250 625 3.3) Примем для одного диска приблизно 50 I/O в сек.(Конечно можно и серьезнее нагрузить, но нежелательно - 70 предел). Сл-но, получим кол-во дисков для каждого из методов Raid с учетом требуемого уровня I/O. Число требуемых Дисков. Уровень RAID I/O в сек. Требуемые Диски RAID-0 250 5 RAID-1 375 7.5 округляем до 8 RAID-5 625 12.5 округляем до 13 Здесь явно виднa 'экономика' Raid 5 в терминах I/O. Но есть и плюс - дополнительное рабочее дисковое пространство. Примем, что используются SCSI диски 2Gb: Уровень RAID Полученные Диски Рабочее дисковое пространство RAID-0 5 10 Gb RAID-1 8 8 Gb RAID-5 13 24(22 - 2Raid) Gb Алексей Тюренков. Oracle DBA&Developer fnctrad@glasnet.ru
Отталкиваться в расчете от требуемого уровня I/O неудобно, в конце концов его необходимо вычислить исходя из типа системы(OLTP, DSS, Complex) и ее характеристик. В частности, я хочу показать как надо расчитывать необходимый уровнь ввода-вывода(I/O), отталкиваясь от транзакционной нагрузки, для разных Raid: Уровнь ввода-вывода(I/O): RAID 0: (reads/transaction + writes/transaction ) * transactions/second RAID 1: (reads/transaction + 2*writes/transaction ) * transactions/second RAID 5: (reads/transaction + 4*writes/transaction ) * transactions/second Обьем дисков(Округлим до след. целого): RAID 0: [Необходимое пространство / кол-во дисков] RAID 1: [Необходимое пространство / (кол-во дисков / 2)] RAID 5: [Необходимое пространство / (кол-во дисков - кол-во контроллеров)] SCSI 2 - до 7 дисков. UW SCSI - до 13 дисков. Пример расчета I/O и всего вместе для High-end OLTP системы с сотней пользователей и большой БД: Чтений: 20/transaction Записей: 8/transaction Скорость Транзакций: 15/second Необходимое пространство: 10 Gb база + 20% свободного = 12 Gb RAID 0: (20 + 8) * 15 = 420 I/Os / Сек Для одного диска приблизно 50 - 35 I/O в сек(Выбирайте нагрузку) 420 I/Os / Сек => 9 - 12 Дисков 12Gb / 12 = 1.0 => 1Gb Диски RAID 1: (20 + (2*8)) * 15 = 540 I/Os / Сек 540 I/Os / Сек => 11 - 14 Дисков 12Gb / (14 / 2) = 1.7 => Округлим до целого => 2Gb Диски RAID 5:(20 + (4*8)) * 15 = 780 I/Os / Second 780 I/Os / Second => 16 - 22 Drives 12Gb / (22 - 2) = .60 => Округлим до целого => 1Gb Диски (Конечно найти 1 Gb сейчас сложно и придется ставить 2 или 4Gb, но в конце концов на расчет шпинделей это сильно не влияет). Расчет приблизительный, но как точка опоры подходит! Алексей Тюренков. Oracle DBA&Developer fnctrad@glasnet.ru
Sergey пишет в сообщении <7da50h$ga6$1@prince.dataforce.net> ... >Часто рекомендуется разносить tablespaces and so on по различным физическим >дискам. >Совершенно не понятно как это может повлиять при работе с RAID уровня 5 >(весьма и весьма распостраненная схема для серьезных серверов баз данных) - >кажется данные в этом случае и так будут разнесены по разным дискам ? > > Я когда то интересовалcя этим вопросом. У маня двухканальный рэйд поддерживающий уровни 0, 0+1, 1, 5, JBOD. Мнений действительно много. Никто никаких рекомендаций не дает. Пришлось экспериментировать. Так вот, наивысшей произврдительности я добился на JBOD, и это понятно, диски работают независимо, никакой проверки, никакого контроля. Вот так работаю уже год и не жу жу. А как же сохранность данных ? А так. бэкапы часто делаю. Наблюдал, я как то как RAID - 5, восстанавливается после краха диска, зрелище потрясающее, но вот времени почему то много уходит. Так не легче ли с бэкапа восстановиться ? И потом экономия дисскового пространства Все таки в RAID - 5, 30 % псу под хвост. По моему при решении этого вопроса, нужно подходить индивидуально в каждом случае, исходя из решаемых задач. Идеальным кажется полная зеркализация RAID1 с разделением одинаковых дисков по разным каналам, если вам позволяет количество мест и количество денег ;-)) Всего доброго
Раз пошла такая пьянка ..., позвольте и мне внести скромную лепту. отличительная фича RAID - 5 (помимо обеспечения надежности) - параллельная запись на все диски при выполнении операции записи любого размера. Это приводит к тому, что производительность комплекта RAID-5 при выполнении записи мелкого размера в разные участки логического тома снижается ниже производительности отдельного винчестера. (Кстати потери в размере RAID-5 равны размеру одного винчестера). Операции чтения с RAID-5 больших размеров идут существенно быстрее чем с одиночным винтом. Операции записи больших размеров идут со скоростью не ниже чем для одного винта. Таким образом, по размещению Oracle'вских запчастей на RAID-5 можно дать следующие рекомендации: Дистрибутив - однозначно на RAID-5, Файлы данных - можно на RAID-5, но лучше на миррор. Управляющие и журнальные файлы - ни в коем случае на RAID-5. Надеюсь поможет. Кстати, по нижеуказанному письму: если у вас нормальный RAID-контроллер, то доступ к логическому тому будет обеспечен в течение всего времени восстановления одиночного винта (что иногда бывает сверхкритично). Поэтому нельзя говорить о сравнении этой технологии с обычными средствами восстановления. Евгений Фаддеенков
Коротко, по распределению обьектов. Выделим основные обьекты и их группы: 1a) Т.Пр. DATA(Данные) 1b) Т.Пр. INDX(Индексы) 2a) Т.Пр. SYSTEM 2b) Bin ORACLE 2с) Bin OS. 3a) Rollback Segments 3b) Т.Пр. TEMP 3c) Control file 4a) Redo Log Несколько вар-в распределения: 1 Вар-т: 1a,1b, 2a,2b,2c : RAID5. 3a,3b,3c, 4a : RAID0+1. 3 Вар-т: 1a,1b, 2a,2b,2c, 3а,3b : RAID5. 3с, 4а : RAID0+1. 2 Вар-т: 1a,1b, 2a,2b,2c : RAID5. 3a,3b,3c : мирроринг(пара). 4a : мирроринг(пара). 3 Вар-т: 1a,1b, 2a,2b,2c, 3а,3b : RAID5. 3с : мирроринг(пара). 4а : мирроринг(пара). Остальные - бэкап схемы. Замечания: 0. Мирроринг можно сделать и программно(без RAID), например 1HDD+1HDD(пара) для Redo Log. 1. RAID - как SCSI-устройство ограничен в кол-ве подключаемых дисков (SCSI2-7, Dual Channel UW SCSI3-7 на SCSI-шину). 2. В новых Raid'ах можно совмещать уровни(0+1 и 5) на одном устройстве. 3. Два Raid'а в системе(0+1 и 5 например) - очень производительное решение для многих 'не ограниченных' в средствах проектов. 4. SCSI HOST- При подключении дисков устанавливать их по шине в порядке приоритетов обращения к SCSI шине(SCSI ID) от 6 до 0(7-самый высокий приоритет-SCSI HOST). При этом первичны данные и журналы. Алексей Тюренков. Oracle DBA&Developer fnctrad@glasnet.ru

Еще фрагмент более ранней дискуссии

Зато Oracle очень плохо относится к дисковому кэшу. Это чуть ли >>> не unsupported решение. Мотивируется это тем, что после commit'а >>> не гарантируется, что данные зафиксируются на диске. >> Ты про какой кэш? То, что у тебя в NIKE стоит не запишется только >> в случае прямого попадания атомной бомбы. А вот OS кэш - это легко. Кроме того, >> как такие заявления стыкуются с поддержкой Oracle RAMdisk? Ну это фигня все, >> большая контора - большой бардак. Любой массив, даже самый примитивный > Хех, я тут поимел битый archivelog файл, и хотел было наехать на > Oracle по этому поводу. А у них сразу и отмаз есть, мол у вас > write-cache включен. > Вот думаю выключить и подождать до следующего битого файла... Кстати, попробуй поставить log_block_checksum=true. Это только средство диагностики - для каждого блока перед записью будет считаться контрольная сумма. безошибочную запись он не гарантиркует все равно. Кстати, в revealnet-овском справочнике пишут warning! насчет того, что использование этого параметра грузит базу дополнительно и рекомендуется его использовать только для диагностики по указанию Oracle Support :) Что касается параметра, то как он работает, я слегка в курсе ;) Товарищу нужен был повод наехать на Oracle по поводу битого лога. Так как я немного еще в курсе его ситуации с аппаратурой, то думаю, performance degradation ему тоже не грозит. Я бы на его месте еще выставил бы \ на тестовом инстансе log_checkpoint_timeout секунд 30 и сгенерил бы длинный insert/update/delete. Т.е. попытался добиться устойчивого эффекта. d_ovechkin@my-dejanews.com wrote: : После коммита изменения в файлы данных записываются из ораклового кэша : постепенно, а чтобы гарантировано прошло восстановление - должны быть : зафиксированы в журнальных логах - это, afair, basic concepts. А вот чтобы в : логи гарантированно записалось - их рекомендуют класть на raw-устройства. Я думаю, что Oracle не слабо вызвать fsync(2) для гарантии записи в log-и. А то и открыть файл с опцией O_SYNC, если таковая поддерживается. Так что надежность Oracle не fs будет ниже, только если эта самая fs накроется целиком. Другой вопрос, что работа через fs "вымывает" кэш файловой системы, что приводит к тормозам остальных приложений на этой машине. У меня данные живут на аппаратном RAID-5, а индексы на RAID-0. : А какой в этом смысл? Ты считаешь, что индексы важнее быстро писать, чем : данные? Здесь как раз все очень правильно, и именно рекомендации держать индексы на RAID-0, а таблицы на RAID-5 есть во всех книжках по администрированию ORACLE. Индексы важнее быстрее читать и писать, а данные очень важно, кроме того, сохранять в безопасности, даже за счет небольшой потери производительности.

Новости | FAQ | Ссылки | Темы | Утилиты | Documentation | Семинары