Yo.![какой смысл на DL380G7 лицензировать SE , если канает SE1 ? 5800 * 2 сокета * 18% супорт = $13688
дальше не хило будет и цена ОС разниться. виндовс сервер раза в 3 любого линукса дороже Смысл простой - в SE1 HA обрезан почти весь. Вернее Oracle Fail Safe есть, но таки тот же Windows only.
А в SE хоть RAC есть.

Yo.!нет смысла, если нужен стендбай на SE1 на порядок дешевле из инета скриптики взятьСкриптики взять можно для любой СУБД с логами, но рассматривать их как полноценный прозрачный HA - странная идея.
Yo.!или докупить что-то типа такого http://www.dbvisit.com/features.php
чем воротить RACУгу, и оно добавит 3740$ на сервер, причем :
"Dbvisit Standard One (DS1) Max CPU - 2
AMD and Intel Dual core CPU are counted as single CPU.
AMD and Intel Quad core CPU are counted as 2 CPU."
Т.е. больше 4-х ядер на сервер - нельзя.
И в чем экономический эффект по сравнению с Windows решением?
"Ради экономии средств - никаких денег не жалко!" (с)

Yo.!если можно на любой, почему в том же мсскл до сих пор не сделано ? на сколько я знаю в мсскл до сих пор нет стендбая обеспечивающего целостность каждой закомиченной транзакции.Это как же? Т.е. MS Log Shipping может что-то пропустить?! Правда, оно там не автоматическое, но так и мы о скриптах говорили... И начинается оно только с Workgroup, т.е. Express в пролете. Мило :)
Yo.!во первых там не ядра, а сокеты. во вторых более 4х сокетов совершенно бессмысленно т.к. не влазит уже в оракловый SE, а если не выше SE то там полноценный data guard идет.Нет там ни сокетов, ни ядер. Там черным по белому написано:
Dbvisit Standard One (DS1) Max CPU* - 2
*CPU (processors):
AMD and Intel Quad core CPU are counted as 2 CPU.
Т.е. 4-ядерник - это уже 2 CPU, что уже есть Max :)
Yo.!Oracle Fail Safe как я понимаю шаред стореджа требует, думаю лицензия на dbvisit многократно дешевле чем виндовсы с MSCS и желязяка под шаред сторедж выйдет.Да уж. SQL Server 2008 R2 Failover Clustering действительно требует shared disks. Видимо, Oracle Fail Safe - тоже, раз оно поверх Windows Clustering.
Прикольно - получается, что HA без развлекухи с shared disks (что, к слову, уже не совсем HA) и на любых платформах в младших версиях есть только у DB2 ;)

2 Yo! - offtop
Кстати, о HA и винде - IBM тут отожгла с Informix .
Informix Ultimate-C Edition for Windows - 16 ядер, 16Гб ОП, Enterprise Replication, High Availability (H/A) cluster.
И все это счастье - бесплатно! Хочу такую же, но для DB2! :'(

pkarklin+1 Или Mirroring в режиме High-Safety да еще и с Automatic Failover. И никаких shared disks.Почитал. Оно там какое-то странное. Базы таки могут рассинхронизироваться при неправильной погоде.
Видимо, чтобы эту дырку заткнуть, в 2008 ввели Automatic Page Repair , которая, как я понял, меняет битую страницу в primary на небитую от secondary, оставляя primary работать и дальше. "which usually resolves the error"
На мой взгляд со стороны выглядит это все довольно странно :)

Yo.!это ты про платный express-C ? $3k в год, не так уж и дешево ...
и точно hadr в express-c не порезанный, разве там не только с задержкой вариант ?Платной Express-C FTL начиная c 9.7 больше нет (куда ей и дорога, только людей смущать).
Есть такая же Express по подписке (3000$ в год), есть Express навсегда (9000$).
Есть вкусно выглядящая для POWER7 платформы (1 сокет м.б. = 2-4-8 ядер, каждое ядро - 4 SMP потока) Workgroup по 15000$ за любой сокет (но до 4 сокетов и 16 ядер всего на сервере, именно ядер, а не потоков, "maximum 16 cores based on the server's enumeration as defined in the BIOS.").
HADR в Express обрезан только мах 2-мя серверами в кластере, в остальном - точно такой же.

pkarklinЛучше читать оригинал.Его-то я и читал, но как выяснилось не внимательно :) Действительно, Automatic Failover к Forced Service отношения не имеет.
Тогда я не очень понимаю претензии Yo! к такому HA. Где транзакции-то теряются?

Yo.!и точно hadr в express-c не порезанный, разве там не только с задержкой вариант ?Кстати, с 9.7.1 любой HADR поддерживает read-only запросы к standby. Правда, только на ur уровне :) Но за такие деньги и это неплохо.

Yo.!выглядит, что так и есть. если сбой произошел между джобами пересылающими бэкап лога то все транзакции от последнего переданного бэкапа будут утеряны.Меня это тоже смутило. Особенно отдельная процедура для логов Backup Job с некоторой периодичностью.
Вопрос к спецам по MSSQL - этот же Log Shiping и используется для Automatic Failover?
Если да, то транзакции от последнего Backup Job до краха действительно будут потеряны, или я чего не понимаю?
В DB2 можно настроить on-line дублирование логов на дополнительный девайс (что имеет смысл делать), и накатывать их на secondary можно в любой момент, а не после "log backup - log restore".

FavnВопрос к спецам по MSSQL - этот же Log Shiping и используется для Automatic Failover?Сам нашел ответ :) Это разные процессы , друг с другом не связанные.
Как я понял, в Database Mirroring Safety Full, единственно доступном на Standart, primary всегда ждет завершения накатывания каждой записи лога на secondary, асинхронный режим доступен только в Enterpirse (и он не может быть основой для automatic failover ). Оно, конечно, Safety Full технология надежная, но вот производительность такой системы... Промолчим.

Dimitry SibiryakovИ какой же в этом смысл? Дополнительный девайс накрывается медным тазом ничуть не хуже и как результат - транзакции опять потеряны.А в случае атомной бомбардировки датацентра накрывается вообще все. Но это не повод не использовать HA :)
Вероятность одновременного отказа 2-х устройств (причем одно м.б. внутри, другое - снаружи primary сервера) равна прямому произведению вероятности отказа каждого. Т.е. исчезающе мала.
А параноики могут поставить N+1 внешнее устройство :)
На самом деле, в DB2 9.7 из логов берутся предыдущие версии записей (2 Yo! - да-да, только при cs уровне :) ), и развести этот механизм с log shipping по разным дискам - здравая идея. Да и внешний диск повышает надежность.