Comments 76
Ещё можно упомянуть, что Firebird одна из самый надёжный БД в плане поддержки целостности данных. Это из-за оригинальной реализации файла базы и хранения транзакций. «убить» файл базы или нарушить целостность базы практически не возможно (не считая конечно физического воздействия). Т.е. даже если приложение или сервер грубо завершается или закрывается. Или обнаруживаются серьёзные ошибки, то база всё равно остаётся работоспособной — лишь невидимые (в общем случае) незавершённые транзакции появляются. Там, где нужно получить необслуживаемую систему — самое оно.
Где-то с тысячи клиентов раз в две недели приходится чинить «битую» базу — «Internal gds software consistency check». Нужно заметить, что используется Firebird-1.5.5.4926, может, уже улучшили ситуацию. А может, и вообще это не с Firebird связано. Но вот такая ситуация имеет место быть.
«Internal gds software consistency check» — это стандартное начало всех ошибок в Firebird, залоговок, так сказать. Но базы просто так не ломаются даже на 1.5 (кстати, релиз 1.5 — это второй релиз 8 летней давности, а нынешний 2.5 — это 5-й, так что разница ого). Наверняка есть какое-то упущение в плане обслуживания, скорее всего интервалы между маркерами транзакций Next/Oit/Osp. Можете написать в личку, если интересно разобраться.
Как правильно сказал AlexeyKovyazin — ошибка скорее всего в неправильно настроенных ограничениях и транзакциях. Сам способ огранизации базы таков, что любое прерывание транзакции или сеанса связи с клиентов не может нарушить целостность, так как используется версиооность транзакций. У меня 1.5.xx (одного из первых релизов) почти пятьь лет простоял на богом забытом офисном компьютере, который нещадно выключали и прегружали. И когда я пришёл, то база полностью соответсвовала описаным правилам и ограничениям. Размер базы был ~400 Мб. После упаковки/распаковки с удалением мёртвых транзакций размер стал ~60 Мб. Можно представить какое количество ошибок было за все эти годы.
UFO just landed and posted this here
Да прекрасно используют. Аэрофлот летает и Газпром газ качает. А кому делать нечего, тот лезет в трекер по адресу tracker.firebirdsql.org и неподтвержденные баги без вопроизводимых кейзов выдает за аргументы в споре… о чем? Или отсутствие публичного доступа к трекеру от Microsoft или Oracle дает надежду на то, что там нет ошибок?
Стыдно не знать теорию разработки ПО, в Вашем-то возрасте, голубчик. Без ошибок ПО не делается. Это только «успешные менеджеры проектов» думают, что можно за 3 итерации любой код безошибочно на гора выдать.
Стыдно не знать теорию разработки ПО, в Вашем-то возрасте, голубчик. Без ошибок ПО не делается. Это только «успешные менеджеры проектов» думают, что можно за 3 итерации любой код безошибочно на гора выдать.
UFO just landed and posted this here
У Firebird есть 2 метода бэкапа — инкрементальный и полный. Начиная с версии 2.0 испортить (полный) бэкап до состояния, когда он стандартными средствами не восстанавливается, можно только физически. Сектор затереть, например, или диск кувалдой разбить. Все остальное решается дополнительным параметром у gbak или nbackup.
Что касается выстреливания «в неподходящий момент» — в вопросе надежности нужен комплексный подход и рабочий план обслуживания базы данных. Надеяться на надежность системы из одного звена (СУБД) — это некомпетентно. Рекомендую рассказ про критические сбои MSSQL и защиту от них www.techdays.ru/videos/1573.html — она хоть и про MSSQL, но на самом деле применима к любой системе обработки информации.
Что касается выстреливания «в неподходящий момент» — в вопросе надежности нужен комплексный подход и рабочий план обслуживания базы данных. Надеяться на надежность системы из одного звена (СУБД) — это некомпетентно. Рекомендую рассказ про критические сбои MSSQL и защиту от них www.techdays.ru/videos/1573.html — она хоть и про MSSQL, но на самом деле применима к любой системе обработки информации.
Во-первых, Densio правильно сказал — если сделан полный бэкап, то это о настоящему ПОЛНЫЙ БЭКАП — снимок базы на некоторой момент времени с учётом всех транзакций и он практически равен базе — испортить его можно только физически. Это реализовано на уровне формата базы данных. Т.е. если база не сохранилась — то нужно отрывать руки программистам, т.к. надобно весьма целенаправленно использовать нестандартные расширения SQL, чтобы обойти механизм транзакций.
А, во-вторых, возможно, судя по упоминанию поля blob, имеет место какое-то фатальное недопонимание принципа работы FB — везде ясно написано, что транзакции не распространяются на поля типа blob. Если используете поля такого типа и они критичны, то используйте дополнительные механизмы для обеспечения целостности — версии полей и т.п. Т.е. если у вас база с жёстко заданными ограничениями по полями blob, но поля blob никак дополнительно не контролируются, то извольте получить «чистый MySQL» с нарушением целостности при обрыве транзакции или неожиданной остановке сервера. Но так себя ведут с полями blob практически все современные базы данных — трудно поддерживать транзакции для данных/полей неограниченной/неизвестной длинны (как для blob).
А, во-вторых, возможно, судя по упоминанию поля blob, имеет место какое-то фатальное недопонимание принципа работы FB — везде ясно написано, что транзакции не распространяются на поля типа blob. Если используете поля такого типа и они критичны, то используйте дополнительные механизмы для обеспечения целостности — версии полей и т.п. Т.е. если у вас база с жёстко заданными ограничениями по полями blob, но поля blob никак дополнительно не контролируются, то извольте получить «чистый MySQL» с нарушением целостности при обрыве транзакции или неожиданной остановке сервера. Но так себя ведут с полями blob практически все современные базы данных — трудно поддерживать транзакции для данных/полей неограниченной/неизвестной длинны (как для blob).
На самом деле, сделать невосстановимый бэкап достаточно просто. Для этого не надо физически портить файл. Все может быть сделано средствами самого firebird-а. Например, так:
1. Создадим таблицу со столбцом Note, который может принимать значения null
CREATE TABLE «Test» (ID INTEGER NOT NULL, «Note» VARCHAR(15));
2. Добавим запись с null-ом
ALTER TABLE «Test» ADD CONSTRAINT «PK_Logs» PRIMARY KEY (ID);
INSERT INTO «Test» (ID, «Note») VALUES (1, null);
3. Установим столбцу Note ограничение not null.
UPDATE RDB$RELATION_FIELDS SET RDB$NULL_FLAG = 1 WHERE RDB$FIELD_NAME = 'Note' AND RDB$RELATION_NAME = 'Test';
Вуаля. Мы получили базу, бэкап которой будет невосстановимым. :)
Пруфлинк: www.firebirdfaq.org/faq103/
1. Создадим таблицу со столбцом Note, который может принимать значения null
CREATE TABLE «Test» (ID INTEGER NOT NULL, «Note» VARCHAR(15));
2. Добавим запись с null-ом
ALTER TABLE «Test» ADD CONSTRAINT «PK_Logs» PRIMARY KEY (ID);
INSERT INTO «Test» (ID, «Note») VALUES (1, null);
3. Установим столбцу Note ограничение not null.
UPDATE RDB$RELATION_FIELDS SET RDB$NULL_FLAG = 1 WHERE RDB$FIELD_NAME = 'Note' AND RDB$RELATION_NAME = 'Test';
Вуаля. Мы получили базу, бэкап которой будет невосстановимым. :)
Пруфлинк: www.firebirdfaq.org/faq103/
> UPDATE RDB$RELATION_FIELDS…
это не сильно отличается от ковыряния внутри файла.
это не сильно отличается от ковыряния внутри файла.
Единственный официальный способ установить столбцу ограничение Not Null. :) Alter Table, в этом случае, не поддерживается, за что отдельное спасибо разработчикам firebird :)
Впрочем, если не нравится такой способ, просто добавьте новый столбец Not Null в таблицу:
ALTER TABLE «Test» add «Problem1» integer NOT NULL;
С тем же результатом и тем же пруфлинком. :)
(Имейте в виду: Хабр кавычки меняет на парные)
Впрочем, если не нравится такой способ, просто добавьте новый столбец Not Null в таблицу:
ALTER TABLE «Test» add «Problem1» integer NOT NULL;
С тем же результатом и тем же пруфлинком. :)
(Имейте в виду: Хабр кавычки меняет на парные)
> Единственный официальный способ установить столбцу ограничение Not Null.
То что так делают некоторые тулзы, еще не делает этот способ официальным.
То что так делают некоторые тулзы, еще не делает этот способ официальным.
Перейдите по ссылке www.firebirdfaq.org/faq103/ (я ее приводил уже выше) и почитайте как делают это разработчики firebird-а. Если не ошибаюсь, за справочную документацию в firebird-е отвечает госпожа Helen Borrie. Полагаю, что FAQ было написано, как минимум, при ее участии.
Что еще считать официальным способом, как не описание на официальном сайте? (Вопрос риторический, отвечать не обязательно :)
К тому же, второй предложенный способ сделать невосстановимый бэкап не использует служебные таблицы вообще. :)
Что еще считать официальным способом, как не описание на официальном сайте? (Вопрос риторический, отвечать не обязательно :)
К тому же, второй предложенный способ сделать невосстановимый бэкап не использует служебные таблицы вообще. :)
Официальный сайт — это www.firebirdsql.org.
Если я не ошибаюсь, официальной документации — нет. По сути документация по FB это дока по IB6 + RN от всех версий.
Если я не ошибаюсь, официальной документации — нет. По сути документация по FB это дока по IB6 + RN от всех версий.
www.firebirdsql.org. Слева ссылка FAQ. Жмем — попадаем на www.firebirdfaq.org
Дальше в этой ветке писать не буду: обсуждение превращается во флейм. Исходную мысль о том, что сделать невосстановимый бэкап можно легко и просто, imho донес предыдущими постами.
Дальше в этой ветке писать не буду: обсуждение превращается во флейм. Исходную мысль о том, что сделать невосстановимый бэкап можно легко и просто, imho донес предыдущими постами.
firebirdfaq — сборник советов, и не является ни официальной документацией, ни официальным сайтом. То, что на firebirdsql.org есть ссылки на firebirdfaq, не является причиной считать его «официальным».
Хелен Борри не имеет отношения к этому сайту, его создали добровольцы по принципу с мира по нитке, что объясняет наличие ляпов и неточностей. Подробнее здесь firebirdfaq.org/about.php
Хелен Борри не имеет отношения к этому сайту, его создали добровольцы по принципу с мира по нитке, что объясняет наличие ляпов и неточностей. Подробнее здесь firebirdfaq.org/about.php
Описанная последовательность действий, и вообще применение NOT NULL в общем случае, не приводит к невосстановимому бэкапу. Ключ -N у gbak отключает ограничения NOT NULL и позволяет восстанавливить бэкап.
Не знаю, как Вы работали все эти годы (с 1.5, судя по утверждениям ниже?), если не знаете об этом — наверное, ни разу не сталкивались с невосстановимым бэкапом, о котором так все любят рассуждать.
Но это не извиняет апломб, с которым говорятся подобные некорректные вещи.
Представляю, что там за «серьезный проект», в котором мега-кластер наваяете… Провалитесь, а потом будете кричать, что Firebird-де плохая база данных…
Не знаю, как Вы работали все эти годы (с 1.5, судя по утверждениям ниже?), если не знаете об этом — наверное, ни разу не сталкивались с невосстановимым бэкапом, о котором так все любят рассуждать.
Но это не извиняет апломб, с которым говорятся подобные некорректные вещи.
Представляю, что там за «серьезный проект», в котором мега-кластер наваяете… Провалитесь, а потом будете кричать, что Firebird-де плохая база данных…
ЭЭээ… вы создали таблицу. Наполнили данными. Потом сменили изменили структуру таблицы. Ну, что тут сказать — сам себе злой Буратино? Там ещё и на триггерах напортачить моэно. Убить базу можно, но нужно быть весьма криворуким. Я же говорил про эксплуатацию базы.
А вот при эксплуатации, это весьма стабильная СУБД. В 99,9% она и внезапное отключение питания переживет без повреждения базы. IMHO в условиях когда оборудование ненадежно, у нее вообще конкурентов нет.
UFO just landed and posted this here
А есть модули к PHP?
Есть, погуглите. В западных саппорт-листах в качестве PHP frameworks обычно рекомендуют CakePHP и qqubed.
по крайней мере с Firebird 1.0 прекрасно работали функции от интербейза — ibase_connect(), ibase_query() и т.п.
Есть, но они для серьёзного использования не годятся практически. Там баги не фиксятся годами. Мы пытались использовать, но когда у нас стали вылазить совершенно неизлечимые ошибки, забили.
А что понимается под серьёзным использованием? Меня самого php_interbase не устраивает местами, но раскурить написание собственных модулей для пыха я не осилил — уж больно много глюков в самом Zend Engine :0)
А существующие глюки не мешают использовать тот же пых для работы с Птицем.
А существующие глюки не мешают использовать тот же пых для работы с Птицем.
Там были какие-то мистические проблемы с одновременным использованием базы, то есть когда несколько пользователей лезли на сайт, драйверу сносило крышу. В гугле находились только аналогичные куски из логов с вопросами «как пофиксить?» и ни одного ответа. В багтрекере были безответные баги, либо пофиксенные, но всё равно проявляющиеся.
Ещё были всякие сбои в попытках подружить Doctrine и этот драйвер.
В итоге просто забили и перешли на более предсказуемый pgsql.
Ещё были всякие сбои в попытках подружить Doctrine и этот драйвер.
В итоге просто забили и перешли на более предсказуемый pgsql.
Ну очень интересно. Мы у себя используем слегка патченный ADODB, который использует именно php_interbase — при сотне-двух одновременных коннектов полёт нормальный. FB 2.5, PHP 5.32/5.3.3. Но местами ИИ этого драйвера бесит, поэтому управление транзакциями в критических случаях (типа оплаты игровых предметов) лучше не доверять ему, а дёргать старт/коммит ручками.
C pdo_firebird проблемы есть, но он и числится экспериментальным.
С php_interbase работать можно, единственное, что огорчает, это отсутствие поддержки RETURNING.
С php_interbase работать можно, единственное, что огорчает, это отсутствие поддержки RETURNING.
Даже с execute не работает? Оно же полностью совместимо со старыми клиентами — мне даже сишные классы не пришлось переписывать для этого в своё время. Хотя каюсь, попробовав процедуры на вкус уже лет 10 как (ещё со времён IB) прямые запросы из скриптов практически не дёргаю — только через процедуры всё.
> Даже с execute не работает?
Процедуры вызывать можно, как и раньше. Я говорил про эту фичу.
Процедуры вызывать можно, как и раньше. Я говорил про эту фичу.
Всегда интересовало почему FireBird так редко используют например в Web.
Разработка с длинной и хорошей историей.
В сравнительных тестах с MySQL которые я видел FireBird в режиме сервера шустрее MySQL.
Есть какие-то подводные камни?
Разработка с длинной и хорошей историей.
В сравнительных тестах с MySQL которые я видел FireBird в режиме сервера шустрее MySQL.
Есть какие-то подводные камни?
Если даже Постгрес на шаред-хостингах редко встретишь, то что уж говорить про FB…
Более-менее готовой к продакшену Postgre стала не так уж давно.
Да простят меня поклонники это БД, но я бы не рискнул ставить ее на сервер шаред-хостинга лет 7 назад.
Да простят меня поклонники это БД, но я бы не рискнул ставить ее на сервер шаред-хостинга лет 7 назад.
Я, честно говоря, не знаю, какие были у Постгреса проблемы с шаред-хостингом, я сам его использую уже лет 10 на собственных серверах, и ничего плохого сказать не могу. Но если при этом есть какие-то проблемы с раздельным использованием, то почему Вы так уж уверены, что FB подходит для шареда? Может, там те же проблемы, невидимые при индивидуальном использовании.
ХЗ. В настройке проще. Стабильнее. Теневая репликация возможна. По скорости не хуже. Памяти есть не больше или сильно меньше (в завивисмости от настроек). Жёстко поддерживает целостность базы (в отличии от мускула, после падения, которого базу зачастую руками править нужно).
Но не умеет работать с таблицами в памяти и временными таблицами. :( Возможно это его и погубило.
Но не умеет работать с таблицами в памяти и временными таблицами. :( Возможно это его и погубило.
Опять же тяжёлся история FB. Все эти игры в бесплатность отпугнули много людей. И документация на него хромает — новые функции описаны очень всколзь.
В общем, народ посел на MySQL и слазить не хочет :) Если будет какой-то полуярный проект который будет использовать FB, то слезет :)
В общем, народ посел на MySQL и слазить не хочет :) Если будет какой-то полуярный проект который будет использовать FB, то слезет :)
По моему так просто исторически сложилось что когда то для WEB не нужна была такая функциональность которую предоставлял FB — он был слишком сложен — а вот MySQL самое то и мы видим сейчас что MySQL усложняется от версии к версии, обрастает новым функционалам который в том же FB давно реализован.
Но ведь можно использовать только нужный фукционал.
Сомневаюсь что MySQL была сильно компактнее InterBase.
Единственную причину, которую могу предположить изначальный OpenSource проекта.
Сомневаюсь что MySQL была сильно компактнее InterBase.
Единственную причину, которую могу предположить изначальный OpenSource проекта.
Дело не в компактности — дело в позиционировании — посмотрите в ветку сверху спрашивают про модули php для FB. MySQL позиционировалась именно как СУБД для интернета — поэтому на всех хостингах и т.д. стоит его поддержка, поэтому есть такие вещи как LAMP и Денвер. FB уже не занять эту нишу.
У создателей MySQL не было проблемы заработать деньги — они росли на венчурные деньги, и про продажах в 50m$/год продались за миллиард… Реальные молодцы. Но вот у покупателей, сначала у Sun, а теперь и у Oracle, стоит вопрос — как окупить вложения в $1B?
Пока еще они не преследуют пользователей, использующих MySQL в коммерческих приложениях (по крайней мере, я таких случаев не знаю), но идея конвертировать пользователей в продажи всегда бродит в мозгах продавцов софта :) Отсюда неопределенность.
Если бы я задумывался в данный момент, на чем делать серъезное веб-приложение/веб-проект для зарабатывания денег, то выбрал бы либо честные open-source БД PostgreSQL или Firebird, либо уж по полной программе вложился в коммерческих MSSQL/Oracle.
Пока еще они не преследуют пользователей, использующих MySQL в коммерческих приложениях (по крайней мере, я таких случаев не знаю), но идея конвертировать пользователей в продажи всегда бродит в мозгах продавцов софта :) Отсюда неопределенность.
Если бы я задумывался в данный момент, на чем делать серъезное веб-приложение/веб-проект для зарабатывания денег, то выбрал бы либо честные open-source БД PostgreSQL или Firebird, либо уж по полной программе вложился в коммерческих MSSQL/Oracle.
Спасибо разработчикам, с нетерпением жду выхода 3 версии
Судя по прошедшей недавно третьей конференции разработчиков Firebird, значительно лучше он не станет. Будет устранены архитектурные проблемы, а вот что касается расширения SQL и некоторых прочих необходимых вещей — они не в приоритете. Будем ждать 4 версии. :)
А что из SQL расширений так уж жизненно необходимо? Мне хочется Оракловских пакетов (зackages) но они в разработке и в тройке, по идее, будут. Что ещё нужно для счасться — слабо себе представляю.
З.Ы. Когда Птиц сможет делать не просто запросы к внешним БД, а ещё и кросс-Бд запросы — он превратиться в такой маленький Оракл :)
З.Ы. Когда Птиц сможет делать не просто запросы к внешним БД, а ещё и кросс-Бд запросы — он превратиться в такой маленький Оракл :)
Мне бы хотелось, чтобы появилась возможность одновременно пользоваться привилегиями двух ролей, если пользователь является их членом. Как в MS SQL, например. Пока можно только залогиниться с указанием только одной конкретной роли. Делать это в третьей версии не собираются. Зато в третьей версии введут изменения в trusted autentification и роль будет назначаться пользователю в зависимости от группы пользователей домена. А если пользователь является членом двух групп, каждой из которых сопоставлена своя роль, то в базу данных он вообще попасть не сможет, так как получит исключение при входе. IMHO хрень полная.
Ну не думаю, что разработчики не предусмотрят нормальную обработку данной ситуации. Но, насколько я знаю, в тройке можно самому городить что угодно с механизмами аутентификации на основе плагинов. Так что никто не запрещает реализовать хоть аутентификацию голосом.
Ну это да. Это ж OpenSource. Не понравилось — переписывай сам. :)
расслабься, казачок явно засланный.
Ну мало ли, вдруг религию сменит? Я тоже был фанатом мускуля. Ещё когда мускуль в пелёнках был и только-только появился. Только я вырос быстрее мускуля и мне стало не хватать этого «фокса с моторчиком», как его обозвал один знакомый ораклист :)
Ну-ну. А Вы, стало быть, восторженный фанат firebird-а.
К Вашему сведению, я работаю с firebird-ом с момента выхода версии 1.5. В данный момент работаю над кластером БД на базе firebird 2.1 в довольно серьезном проекте. Просто я предпочитаю здраво смотреть на продукт и видеть в нем как преимущества так и недостатки. И, если для некоторых проектов FB — отличное решение, то для других он совершенно не подходит. А фанатеть от чего-либо — это не по мне. Я предпочитаю голову включать и трезво оценивать продукт с точки зрения требований к проектируемой системе.
К Вашему сведению, я работаю с firebird-ом с момента выхода версии 1.5. В данный момент работаю над кластером БД на базе firebird 2.1 в довольно серьезном проекте. Просто я предпочитаю здраво смотреть на продукт и видеть в нем как преимущества так и недостатки. И, если для некоторых проектов FB — отличное решение, то для других он совершенно не подходит. А фанатеть от чего-либо — это не по мне. Я предпочитаю голову включать и трезво оценивать продукт с точки зрения требований к проектируемой системе.
А почему над 2.1? По-моему, если делать что-то на будущее — то надо брать сырые версии и делать на них — так хоть результат не устареет к релизу :)
А вот я, почему-то предпочитаю работать со стабильными продуктами. К тому же, перерывы между версиями FB слишком велики: можно разработать продукт и год ждать стабильного релиза.
С другой стороны, в стабильном релизе может ведь нехватать требуемых фич. Ко всему прочему, активное использование нестабильных OS-продуктов позволяет выявить как баги, так и тонкие моменты работы продукта.
Ну и иногда, активное взаимодействие с разработчиками позволяет быстро исправить недоработки. Причём, это касается не только Firebird, но и прочих OS-продуктов.
Ну и иногда, активное взаимодействие с разработчиками позволяет быстро исправить недоработки. Причём, это касается не только Firebird, но и прочих OS-продуктов.
Хотелось бы напоминить, что за 10 лет Firebird выпустил 5 релизов -1.0, 1.5, 2.0, 2.1 и 2.5. Это чаще, чем MSSQL — 2000, 2005, 2008 и 2008R2.
Рекомендую записаться в ibase.ru на курсы — узнаете много полезного.
Рекомендую записаться в ibase.ru на курсы — узнаете много полезного.
Сомневаюсь, что сейчас можно начать разработку под MS SQL 2012. А пот третий FB — пожалуйста. Но выйдет он еще не скоро. Я и говорю о том, что imho разрабатывать лучше всего под stable продукт. В случае с FB это 2.5, а в случае с MS SQL 2008R2. А стремиться обогнать время — не самый лучший вариант.
UFO just landed and posted this here
Что-то Вы тут тихо сам с собой общаетесь, по-моему :) Снова про невосстановимый бэкап вспомнили. Выше читайте — нет невосстановимых бэкапов у Firebird, нет. Погуглите, в конце концов, ну что ж всех тыкать носом надо.
Если действительно интересуют ответы на все эти где и почему — задайте вопросы на специализированных форумах, где присутствуют разработчики Firebird, где на русском (!) языке можно с ними подискутировать.
Если действительно интересуют ответы на все эти где и почему — задайте вопросы на специализированных форумах, где присутствуют разработчики Firebird, где на русском (!) языке можно с ними подискутировать.
как я понял, должен появиться RN на русском
Sign up to leave a comment.
Релиз Firebird 2.5: Производительность и Аудит