Psilon
Pl/sql гибче чем T-sql. И в некоторых вещах ощутимо, но сложнее.
Именно по этому, часто сервера Oracle выполняют роль и серверов приложений, и тут Oracle с точки зрения Разработчика "больше нравиться".
С другой стороны, когда на СУБД начинают валить то, что НЕДОЛЖНО обрабатываться в БД, начинается ппц.

А так да, когда я первый раз сел админить Оракл(щас отощёл)- плевался после T-SQL, с другой стороны, через полгода понял почему майки просрали все полимеры.
С 2000го по 2005 года они стояли на 10 шагов позади в связке win2003+ms sql 2000 против Oracle9i+*nix.
А потом ещё выход висты.
Это потом пришла 7ка и версия 2008 R2, а это ещё 2года.
Ещё бы лет 5 расп-ва и расклад был бы другой

Да пофиг, какой уровень - высокого или низкого конца. Репликация средствами массива убога по определению. Хотя бы потому, что элементарно получить испорченную таблицу (записалась половина транзакции, на второй половине мастер повис - и привет). Ну нет понятия "транзакция" у дискового массива, нельзя ему сказать "запиши сектор 100500, 100700 и 30500 вместе либо не пиши вообще".

NiTr0
Не пугайте...у вас были ТАКИЕ случаи? Или измышления?
Такого быть не может по определению. Это работает, как зеркало.

У меня были случаи битой базы при элементарном отключении питания без какого-либо массива.


Плохое у вас определение.


Зеркало без аппаратного контроллера с BBU работает тоже в общем-то хреновато. С ненулевой вероятностью БД (или ФС) может быть повреждена.

NiTr0
Хватит использовать "сделай сам сервера" и системы хранения- купили полку, напихали сегейтов...
Причём тут массив? Это настройки массива и операционки.

Второе- что за СУБД? И делайте в обход кэша файловой системы.
Зеркало без аппаратного контроллера хреново работает??? О как, пойду аиксистам скажу что они скоро файловую систему положат для чего нужен отдельный процессор на контроллере вы знаете? Контрольную сумму он вычисляет толко при Raid5 и выше.
Веритас кластер... В топку его тоже??
Логическое повреждение легко исправляется восстановлением из архива определённых страниц БД.

А репликация данных - средствами полки?
К слову, а в чем профит от СХД, в сравнении с нормальным сервером с нормальными винтами/SSD в нормальном массиве? Особенно - если это выделенный сервер с большой нагрузкой на дисковую подсистему?


И без этого бьется.


Для чего нужен кеш и батарейка на контроллере рэйд-массива - знаете?
О существовании writeback-кеша накопителей - знаете? А он до 64 МБ уже доходит, что дофига при 200 iops размером запроса в 4 КБ...


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

NiTr0
Какие 64мб??? Я вот 4х сокетный хъюлет на ксеонах Е7 щас буду мучать, там на не самом последнем P410 1Gb кэша.
75% отдам на запись.
И то, это под систему и локальные архивы... КЭШ легко забивается постоянной архавацией логов. Перестройкой индексов и тд.
Сама база на внешнем массиве, кэша там >32gb.
Но там правда ещё куча систем.

Какой профит от внешнего хранилища, нормального...распределение кэша по портам, лунам.
Балансировка нагрузки между контроллерами, подробный мониторинг. Тех поддержка.
Правда стоимость...

Добавлено спустя 11 минут 28 секунд:
NiTr0
Я бы побоялся держать OLTP БД размером 1-3 ТБ на массиве собранном из простых комплектующих.
А если таких баз 10?

Повреждённые блоки восстанавливаются в Oracle 11g через резервный standby сервер парой команд,
В ms sql 2008 и выше, если есть зеркало ср-ми sql- автоматом.

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

На плате винта которые.


Если с репликацией на второй такой же сервер - почему бы и нет? Ну издох полностью допустим, и фиг с ним, второй поднялся мастером, подхватил...
К слову, по моей практике винты дохнут куда чаще даже десктопного железа. А в полках - винты-то те же...


Автоматически? Нет? Т.е. админ должен постоянно быть готовым поднимать вручную? Никакого отпуска, никаких форс-мажоров типа больничных? Грусть-печаль...