Я балдю с этого комьюнити

[metaclass]

ссылко
Действительно я считаю что фаерберд Гэ. И знаете почему? Потому что в Оракловом форуме ответы от Ваших отличаются конструктивностью, отсылкой к докам или вообще по нужному направлению. А не предложением платных услуг на бесплатном форуме

У человека, обслуживающего стороннее приложение без поддержки со стороны разработчиков, странная проблема - зависает сервер. В комьюнити ему сразу же начинают компостировать мозги, сраться между собой и предлагать платные услуги по оптимизации базы, вместо того, чтобы спросить уточняющую информацию и помочь.
Кстати, в Firebird всякие тонкие моменты по оптимизации, разборками с зависаниями и тому подобными странностями являются хардкорным вуду-гуру-карго-культом, нигде не описанным и до последнего времени (появления мониторинга и нормальных логов в FB 2.5) не поддающимся логическому изучению.

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

Comments

[usovalx.livejournal.com]

> являются хардкорным вуду-гуру-карго-культом

И в этом виноваты "невменяемые дебилы-разработчики" а не firebird?

[fraks-nsk.livejournal.com]

Ну это вообще-то преувеличение. :) ни с каким особым хардкором я там не сталкивался.
Нет, конечно можно при желании поставить раком ЛЮБОЙ сервер - но тут каждый ССЗБ.

[metaclass.livejournal.com]

Я уже писал вроде - те, кто используют FB активно, научились обходить все подводные камни с закрытыми глазами, у них эти проблемы просто не возникают. Кроме особо невменяемых случаев с кривым железом и реальных багов.

[fraks-nsk.livejournal.com]

Наибольшим недостатком на мой взгляд является отсутствие целостной документации.
Если она есть у нынешнего IB - то это сильный аргумент.
В свое время очень много подчерпнул из документации к IB 4.2.1.
Книга Хелен конечно помогает, но она уже существенно устарела.
Когда надо нарыть что-то по серверу приходится рыть в нескольких RN от разных версий и т.п. Что бы быть в курсе его там вообще есть - приходится читать форум. Можно конечно и RN но в форуме как-то живее получается, да и язык родной.

[fraks-nsk.livejournal.com]

Ну... установка и запуск MS SQL при наличии знаний только по FB и чуть-чуть по MySQL - это вообще неподъемный подвиг :)

[fraks-nsk.livejournal.com]

А еще вуду было с MS SQL когда он вдруг сильно незадружил с рейд-контроллером и база 1С под MS SQL периодически погружалась в глубочайшие тормоза.

[metaclass.livejournal.com]

Я наугад ставил и то и другое и третье :)

[metaclass.livejournal.com]

Сложный вопрос. Оно поддается изучению, другое дело, что исключительно через чтение сайтов и форумов. Не помню, освещается ли адекватно этот вопрос в книжке Хелен Борри по FB.

[fraks-nsk.livejournal.com]

А можно пример вуду с FB? Я не могу припомнить что бы были проблемы именно с FB.

С IB - были. Фантастическое торможение при работе по TCP. До этого работал по NetBEUI - там не тормозило но требовало авторизации на которые есть ограничение в винде. Заюзал gds32.dll от Yaffil а потом на него и перешел.

[metaclass.livejournal.com]

Сборка мусора, sweep interval и 4 числа выдаваемые gstat -h. Я понимаю, что надо людей сразу посылать читать www.ibase.ru, но даже там с первого раза не понятно. Пока сам лично на это не наткнешся и не отладишь. С перебором параметров транзакций, которые тоже объяснены только на всяких левосайтах.
И то - при гарантированно правильно работающем приложении транзакции иногда застревают (у нас 200 клиентов, у особо крупных установлен мониторинг этого дела, присылающий уведомления на почту) - предполагаю, что причина в сети и отваливающихся клиентах.

Зависание сервера на wow64 и многопроцессорных машинах - неоднократно такое было. К сожалению, все клиенты с подобным железом имеют жесткую политику администрирования и безопасности, поэтому снять дамп с боевого сервера в таком состоянии на предмет изучения я никак не могу.
Мониторинг и логи нормальные появились только в 2.5. При этом их настройка (трейсы) - адов пиздец, а firebird.log как был херней так и остался. Я не понимаю, почему у меня в тупых енд-юзеровских вещах каждый модуль имеет независимую настройку логгинга, а в системном демоне, к которому равнье вообще никакого разумного доступа кроме как из gstat и отладчика - ничего нету.
В версиях до 2.1 было еще много всякой фигни типа "если подключается один клиент по очень тормозной сети - все остальные ждут, пока пройдет процесс подключения" или "кончилось место - база умерла".
Падение базы от выключения питания - где здесь D из ACID? Я от разработчиков так и не добился четкого ответа - исправлено это или нет. Буду проверять самостоятельно, т.к. это одно из условий текущего проекта.
Всякие необъяснимые "internal gds consistency check" это тоже мрак - gfix в руки и сиди долбись.

[fraks-nsk.livejournal.com]

Ну вобщем да, почти все было ;)

[fraks-nsk.livejournal.com]

gds кстати - древнейшее сокращение :)
Groton Database Systems