Oracle: 1 большой сервер по сравнению с 2 серверами меньшего размера?

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

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

Не идите для более трудного SLA, чем Вы действительно нуждаетесь и не создаете систему с дополнительной сложностью для достижения SLA, который не поддерживается всеми аспектами программного обеспечения, операций и аппаратных средств.

Немного отличающееся представление 'пяти девяток' надежность.

Несомненно, Ваш поставщик будет требовать некоторой впечатляющей статистики надежности их продукт. Как счетчик, вот является взятие 'девятками', связывающими различные уровни SLAs к тому, что на самом деле необходимо для достижения их на практике:

• Два девяток (99%) вид переводит в период DR с 24 часами и может относиться к приложениям, таким как системы хранилища данных где система в прямой поддержке операционных процессов. Этот уровень обслуживания быть достигнутым путем восстановления системы от резервных копий.

• Три девяток (99,9%) вид приравнивается к окну DR с 4 часами и является действительно всем, что необходимо для большинства приложений направления деятельности. Этот тип стратегии DR может быть достигнут с простой репликацией передачи журналов и резервным сервером. Часто, простота этого типа архитектуры означает, что это имеет относительно немного основанных на конфигурации видов отказа и достигает значительно лучшей надежности на практике. Существует много экземпляров двухуровневых 4GL приложения, достигающие непрерывных времен работы месяцев или лет с этим типом конфигурации.

• Четыре девяток (99,99%) могут быть просмотрены как окно DR нескольких минут и нуждаются в горячем резервировании или горячей архитектуре обработки отказа. Достижение этого типа SLA на практике является довольно трудным и обычно требует программного обеспечения, разработанного для него. Как ни странно, дополнительная сложность кластеризованной архитектуры N-tier открывает намного более широкую поверхность видов отказа из-за неверной конфигурации или закрадывается в управление изменениями.
  
  Нужно отметить, что ошибки конфигурации и плохое управление изменениями являются самыми большими причинами незапланированного времени простоя в операциях дата-центра и, намного более вероятно, вызовут незапланированное отключение электричества, чем отказ оборудования на сервере.

• Пять девяток (99,999%) требуют не больше, чем нескольких секунд незапланированного времени простоя каждый год. Этот тип SLA помещает Вас в область специализированного аппаратного и программного обеспечения, созданного для отказоустойчивости. Реализация этого типа SLA является дорогой, требует специальной платформы, такой как мейнфрейм и люди со специализированными навыками, которые большинство компаний не имеет внутренними.

Большинство людей, требующих SLAs на 99,999%, полно дерьма, q.v. Microsoft, Accenture и Лондонская фондовая биржа.

Если речь идет о деньгах, то я настоятельно рекомендую другое решение СУБД.

RAC и DG очень сложно настроить и поддерживать, как указано выше. Для управления СУБД действительно требуются знания и опыт. Желательно иметь SCAN, VIP, HB и HBA.

Кроме того, я бы настоятельно рекомендовал держаться подальше от Windows для Oracle.

Данные в SAN также должны быть RDM, а не хранилищем данных.