https://m.opennet.dev/openforum/vsluhforumID3/71200.html После нескольких лет разработки увидел свет (http://www.firebirdsql.org/) релиз новой ветки СУБД Firebird 2.5 (http://www.firebirdsql.org/rlsnotesh/rlsnotes25.html), переведенной на многопоточный режим обработки запросов. Одновременно ведется тестирование ветки Firebird 3.0, переписанной на языке C++ и основанной на переработанной архитектуре, оптимизированной для использования на многоядерных системах. <br><br><br><br>Ключевые улучшения Firebird 2.5:<br><br><br>- Распараллеливание запросов на несколько нитей и переработанная низкоуровневая система синхронизации нитей, что позволяет значительно повысить производительность на многопроцессорных и многоядерных системах;<br>- Реализована поддержка ALTER VIEW и изменен синтаксим CREATE VIEW;<br>- Возможность обращения к другой базе данных, через использования выражения "EXECUTE STATEMENT";<br>- Возможность использования регулярных выражений в SQL запросах;<br>- Автономные транзакции<br>- Управление аккаунтами пользователей СУБД через SQL-выражения "CREATE/ALTE...<br><br>URL: http://www.fir https://m.opennet.dev/openforum/vsluhforumID3/71200.html#34 Mon, 11 Oct 2010 19:56:48 GMT Работаем с СУБД уже много лет. Используется в качестве производственной СУБД на крупном машиностроительном заводе. Платформа ОС - FreeBSD7. Сервер HP DL380G5 c честным RAID-контроллером с SAS 15K RPM Винчестерами. Объем базы доходит до 16,2 ГБ. Одновременных сессий, например сегодня было около 520.<br>Из плюсов - скорость. Она просто бешенная. Надежность. Практически неубиваемость. Компактность.<br>Из минусов - слабые средства администрирования, которые во многом вылечились в 2.5. Отсутствие с свободной версии кластеризации.<br> https://m.opennet.dev/openforum/vsluhforumID3/71200.html#33 Wed, 06 Oct 2010 21:22:38 GMT Спасибо разработчикам! Пользовался всеми релизами, начиная с 1-ки...<br>На 1.5-ке работала торговая сеть из 15-ти розничных магазинов, объем базы центрального офиса был за 35 гигов...В магазинах по 2-4 гига. Надежный движок субд, конечно не без грехов, но у кого их не бывает...<br>Если и падала пару раз на магазинах, то из-за того, что не заметил, что операторы забили свободное место на диске с базой. После падений сравнительно легко и без потерь подымал базу. <br>В 2007-м перешел на 2-ку под Linux, а 1,5 года назад уволился из фирмы...С тех пор базы работают без "внешнего вмешательства". Пока полет нормальный - ни разу не обращались, но и, насколько я знаю, не было необходимости<br> https://m.opennet.dev/openforum/vsluhforumID3/71200.html#32 Wed, 06 Oct 2010 05:19:55 GMT Перечитайте внимательно сообщение, там не про 33% загрузки железа, там про использование всего 33% фич, наворотов больших дорогих коммерческих СУБД<br> https://m.opennet.dev/openforum/vsluhforumID3/71200.html#31 Wed, 06 Oct 2010 01:27:49 GMT &gt; Приведу такой факт - по опросам Ит спецов больших фирм их БольшиеПлатныеКоммерческиеСУБД используются на 33%.<br><br>Ну ты и перец :) А погуглить _почему_так?_ не пробовал? :)<br><br>У нас опупенно дорогие системы мониторинга стоят чтобы бэйслайн считать. И как только превышает 30% - идёт заказ на новое железо. Ибо "DoS is not an option", "многа девяток", "бёрст протекшжн" и прочие страшные слова :)<br><br>Хотя да - во всяких ЖЭКах где стоит 98% этой датабазы - всё вышеперечисленное есть просто бла-бла-бла ... :)<br><br> https://m.opennet.dev/openforum/vsluhforumID3/71200.html#30 Wed, 06 Oct 2010 01:15:49 GMT &gt;&gt; а "фирменный" невосстановимый бэкап это фича?<br><br>Так починили или нет?! <br>В свое время это стало шоустоппером, ибо тестировать _каждый_ бэкап на резервном серваке чтобы убедиться что это бэкап, а не пис-оф-самизнаетечего - несколько напрягало ...<br><br>... наверное починили - лет то уже сколько прошло :) Хотя пейсатели там те ещё ...<br> https://m.opennet.dev/openforum/vsluhforumID3/71200.html#29 Wed, 06 Oct 2010 01:11:23 GMT &gt;&gt; Вот тоже интересно, каким образом можно покоцать версионник загадка.<br>&gt; Достаточно писать на диск некорректно обрабатывающий команду SYNC :)<br><br>Даже проще - достаточно попытаться скопировать файл bd при работающей базе. Без дураков - в официальной документации написано. Ниии - нам такого не нать :)<br><br><br> https://m.opennet.dev/openforum/vsluhforumID3/71200.html#28 Tue, 05 Oct 2010 11:13:11 GMT Работаем с Firebird 7 лет. Написали кучу софта который стоит и работает годами без администрирования. Очень доволен что в 2002г выбрали именно Фаребирд - тогда еще версии 1.0<br><br>Не буду разводить религиозные войны насчет кто лучше, это не будет правильно. Приведу такой факт - по опросам Ит спецов больших фирм их БольшиеПлатныеКоммерческиеСУБД используются на 33%. <br><br>Про нас скажу, что Фаребирд 2.0 мы используем процентов на 70-80, при этом решая поставленные задачи. <br><br>Если будет оооочень большой заказ - может и подумаю про смену СУБД, а так по 60-100 клиентов с базой в 5Гиг работают только в путь. <br><br>Благодарим разработчиков за их труд. С уважением, отдел программирования {фирму не пишем чтобы не заподозрили рекламу}<br> https://m.opennet.dev/openforum/vsluhforumID3/71200.html#27 Mon, 04 Oct 2010 22:13:46 GMT в linux на сервере желательно tmp каталог монтировать на отдельный раздел, да побольше - FB там хранит результат промежуточных выборок. И под базу отдельный раздел.. А еще кошернее если tmp с базой на разных контроллерах.<br> https://m.opennet.dev/openforum/vsluhforumID3/71200.html#26 Mon, 04 Oct 2010 22:10:15 GMT &gt; а "фирменный" невосстановимый бэкап это фича?<br><br>Если база оказалась ломанная и/или бэкап - восстанавливать без индексов и еще там ключ, кажется -O восстанавливать каждую таблицу отдельно.. Что-то вроде этого.. или игнорировать ошибки.. забыл.. А констрейнты/индексы потом "поднимать".<br>