hvlad andsmЯ IB не изучал. Мне прислали gdb-файл (IB) с данными, я эти данные посмотрел и экспортнул в MSSQL. Зачем изучать продукт который:Не изучал - не стоит говорить того, чего не знаешь

andsm 1. Не подходит для тех задач которыми я занимаюсь. Например, легкость установки/размер 4 мегабайта - зачем это мне? Сейчас 5 админов осуществляют круглосуточный надзор за БД. Уж установить MSSQL они сумеют, я уверен И с учетом того что размер дискового пространства более терабайта место для SQL Server тоже найдется. База работает в режиме 24x7, FB/IB так умеет? По производительности - у меня вот уже полгода процентов 80, а в некоторые месяцы и все 100% времени уходит на оптимизацию, на работу по повышению производительности. Что у FB с производительностью? Сумеет выдержать 1000 довольно сложных транзакций в секунду, причем чтобы длительность каждой транзакции не превышала 250 мс?Не подходит - не пользуй. Зачем огульно хаять ?
Мне нравится эта фраза про повышение производительности. Она очень характерна. Или у вас за полгода настолько сильно изменилась БД, что приходится всё переделывать ? В любом случае это не характеризует ни FB, ни MSSQL - только вас.

andsm 2. Ненадежная. У меня business-critical application, и читая в форумах о проблемах с надежностью FB желание перенести все на FB не возникает. Выше были упомянуты еще и какие-то проблемы с бекапами. У меня бекап лога транзакций делается ежеминутно. Как на FB делать ежеминутный бекап на базе под высокой нагрузкой? FB поддерживает кластера?Ежеминутный бекап логов - я такого ещё не встречал. На FB можно делать хоть ежесекундный бекап, но смысла в этом, как и на MSSQL нет никакого. В FB2 есть мультиуровневый инкрементный физический бекап, аналогом которого в MSSQL есть одноуровневый differential backup

andsm 3. Нет поддержки производителя (может что-то и есть, но я не слышал). Поэтому обратиться в саппорт невозможно. Да ? Жаль Кузьменко не слышит. А этот сайт поиск не дал ? Впрочем поиска, насколько я понял, не было

andsm 4. Если подумать еще можно минусы привести, но и этого уже достаточно чтобы не изучать FB - как минимум до того времени пока FB не докажет что это продукт достаточно высокого класса.Это не нужно доказывать.
Как и ожидалось никто из сторонников FB/IB ответить по существу не смог - сплошь эмоции и попытка перейти на личности. Единственно что по существу было отвечено - что вроде как у FB есть саппорт, и только.
Про не подходит - не используй. Я и не использую. Но раз топик про сравнение IB/FB и MSSQL, то обьяснил почему не использую.
FB не нужно доказывать что это продукт высокого класса только если FB не претендует на применение в серьезных проектах.

hvlad lockyхм... а для зачем приостанавливать писателей, если можно приостановить бэкап? то бишь, дописав запись о транзакции не браться за очередную?
Хотя Вы правы, в БОЛ как-то не очень написано.
Надо попросить Глори, пусть разберется что там и как и доложит нам :-) или по крайней мере ткнёт носом куды чиатать.Ну наконец-то начали думать ;)
Если приостанавливать бекап, то он никогда не закончится, если в БД всё время идёт запись
Осталось только сообщить SQL Server-у о том что надо останавливать запись в лог во время бекапа лога А то у меня он не знает о том что ему нужно останавливаться На днях как раз в момент бекапа лога нагрузка была 630 транзакций в секунду. Ни одна транзакция не останавилась, максимальное время прохождения транзакции составило 156 мс при среднем времени ~12 мс.

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

Если FB не может делать аналогичный бекап - это проблемы FB.