metaclass: (Default)
[personal profile] metaclass
Как известно, после многолетних трудов был выпущен Firebird 3.0.
Если подключаться к нему клиентом от Firebird 2.5 то он выдает сообщение об ошибке "connection rejected by remote interface".
Если я правильно понимаю, это старый клиент так реагирует, когда его сервер посылает, когда обнаруживает устаревший wire-протокол, который по умолчанию запрещен (его надо разрешать в firebird.conf или использовать клиент от 3.0): https://stackoverflow.com/questions/30390465/connection-rejected-by-remote-interface-connecting-to-firebird-3-with-pdo

Еще в нем при инсталяции руками надо подключаться локально к произвольной базе (в примерах используется демо-база employee) и создавать юзера SYSDBA на весь сервер. Немного смущает что для манипуляции общей базой юзеров надо подключаться к частной базе - нелогично.
И еще надо давать пользователям - владельцам БД явные права на создание баз.

Посмотрю, что будет дальше, но уже понятно что процесс миграции с 2.5, если таковой понадобится, будет сложный.

Date: 2016-12-10 03:59 pm (UTC)
From: [identity profile] cross-join.livejournal.com
По этой и другим причинам рекомендуемая клиентам миграция с 2.5 - SQL Server 2016 :)

Date: 2016-12-10 05:03 pm (UTC)
From: [identity profile] metaclass.livejournal.com
А там уже завезли предсказуемую цену на лицензии, без зависимости от фазы луны и количества проводов в процессорах и возможность купить, не показав фотографию жопы и унитаза?

Date: 2016-12-10 05:08 pm (UTC)
From: [identity profile] cross-join.livejournal.com
С лицензиями ни разу не было проблем, там много опций (поюзерно, посерверно и т.д.).
Но для клиентов, использующих FB, в 90% случаев достаточно бесплатного Express.
В будущем году грядет версия SQL Server под Linux, беты уже доступны для тестов подписчикам.

Date: 2016-12-10 07:20 pm (UTC)
From: [identity profile] metaclass.livejournal.com
Constrained to a single CPU (in 2012, this limitation has been changed to "The lesser of one socket or four cores", so multi-threading is possible)
1GB RAM (Same in 2008/2012)
4GB database size (raised to 10GB in SQL 2008 R2 and SQL 2012) per database.

Что-то маловато. У меня базы под 60 гиг размером.

Date: 2016-12-10 07:34 pm (UTC)
From: [identity profile] cross-join.livejournal.com
Да, 10 Гб - лимит на одну базу, если выше - нужна стандартная версия.
Для транзакционных приложений 10 Гб - это немало.
From: [identity profile] click0.livejournal.com
Как уже сказали, есть PostgresSQL.
А еще есть классический Mysql, форки Перкона и Мариадб разных веток 5.5, 5.6 и 5.7.
From: [identity profile] cross-join.livejournal.com
На риторический вопрос следует риторический контрвопрос: "Зачем вы советуете якобы свободную и бесплатную каку?"

Date: 2016-12-10 04:18 pm (UTC)
From: [identity profile] q987.livejournal.com
Зачем нужен Firebird когда есть PostgreSQL?

Date: 2016-12-10 04:41 pm (UTC)
From: [identity profile] cross-join.livejournal.com
У Постгреса нет встраиваемой версии

Date: 2016-12-10 05:00 pm (UTC)
From: [identity profile] metaclass.livejournal.com
Ну, миграция на PostgreSQL будет не менее сложной, а еще и переобучать всех.

Date: 2016-12-11 08:44 am (UTC)
From: [identity profile] q987.livejournal.com
А на случаи из http://www.ibase.ru/db_repair/ вы или коллеги не налетали ? Уж очень страшно написано....

Date: 2016-12-11 10:02 am (UTC)
From: [identity profile] metaclass.livejournal.com
Сталкиваюсь, 1-2 раза в год.
Причина практически всегда - проблемы с железом. Память без ECC, диски с бэдами, выключение компьютера на живую из сети, итп.
Если я правильно понимаю ситуацию, у других СУБД то же самое, но они не делают себе черный PR из зарабатывания на ремонте баз :)

Date: 2016-12-11 10:12 am (UTC)
From: [identity profile] q987.livejournal.com
Там везде стандартный ответ "воостановите из бэкапа"...

А если не секрет, 1-2 раза в год это на сколько развернутых систем (интересует порядок 1-10-100) и каково примерно среднее/максимальное время починки?

PS. Недавно попросили починить маленькую (7GB) FB базу, пока знакомился с FB и чинил - сильно удивился проблеме невостановимости полного бэкапа и возможности скопировать файл во время работы. Но круче всего версионность метаданных и обновление процедур (быстрый bugfix на месте), которые используются другими процедурами, которые вызваны в подключенных сессиях...

Date: 2016-12-11 10:26 am (UTC)
From: [identity profile] fraks-nsk.livejournal.com
Копирование файла базы с которой идет работа - это убийство базы своими руками.
И в ряде случаев восстановлению не подлежит. Не надо так делать.
Причем мусором будет как копия базы так и ее исходник.
Пробовал такое, слава богу на тестовой базе.
Edited Date: 2016-12-11 10:37 am (UTC)

Date: 2016-12-11 10:57 am (UTC)
From: [identity profile] metaclass.livejournal.com
Пару недель назад умельцы из одного проклятого белорусского города так копировали БД, забыв выключить расписания заданий раз в 10 минут.
Хорошо, что убилась только консистентность между таблицей аудита подключений и генератором ее ID.
Кто б знал, как вот эти местные "ИТшники" бесят - слов нет передать. И, блядь, главное все же сами всегда лезут, никогда не позвонят в саппорт, ничего.

Date: 2016-12-11 12:22 pm (UTC)
From: [identity profile] fraks-nsk.livejournal.com
Я использую файловое копирование, но предварительно переименовав файл. Если переименовка обломалась - значит он таки использовался. А если переименование удалось - по старому имени никто не подключится.
Это на винде работает, на юниксах нет.

Date: 2016-12-11 10:54 am (UTC)
From: [identity profile] metaclass.livejournal.com
Не, я чинил некоторые повреждения и руками. Особо клинический случай был, когда у клиентов убилось 16 кб системных таблиц в самом начале БД. Взял их из бэкапа и трансплантировал поверх, затем бэкап-ресторе.

Файл во время работы ни в одной БД вообще копировать нельзя - он же не консистентный будет.
Невосстановимость бэкапов и то что бэкап бинарный и его нельзя руками починить - тоже маразм известный.
А замена процедур на ходу - вполне штатная ситуация.

Date: 2016-12-11 11:15 am (UTC)
From: [identity profile] q987.livejournal.com
"Особо клинический случай был, когда у клиентов убилось 16 кб системных таблиц в самом начале БД. Взял их из бэкапа и трансплантировал поверх, затем бэкап-ресторе. " - круто !

Edited Date: 2016-12-11 11:21 am (UTC)

Date: 2016-12-11 10:35 am (UTC)
From: [identity profile] fraks-nsk.livejournal.com
Если база не сильно нагружена запросами, например магазин с 1-2-3 кассами, то даже выключение питания сервера путем выдергивания из ИБП не приводит к порче базы.

У меня 5 серверов в разных городах, базы от 200мб до 7гиг, одинаковые по структуре.
За время существования FB проблема была только один раз, когда винт сдох.
На IB/YA бывали проблемки, один раз пришлось из бэкапа восстанавливаться.

Работаю на IB/YA/FB лет 15.

С невосстановимыми бэкапами сталкивался, но всегда заблаговременно, ибо для разработки использую копию базы поднятую из бэкапа. И всегда источником были мои ручки (изменение метаданных на ходу, NULL в поле NOT NULL из-за опять же изменения метаданных при наличии коннектов).

Date: 2016-12-11 10:23 am (UTC)
From: [identity profile] fraks-nsk.livejournal.com
На sql.ru это подробно обсуждалось.
Еще находили вроде какой-то баг в PDO, что к самому FB не относится.
Читай форум где разработчики присутствуют, наиболее быстрый путь разобраться.

Date: 2016-12-12 06:50 am (UTC)
From: [identity profile] kuaw26.livejournal.com
Они уже 4.0 анонсируют (http://s577861.stat-pulse.com/urls/19823319/MjA2NjUwNQ==/80678efbbe2ff03fb7c9fd25e12ebf7a/h/28edd3380a1c17cf65b137fe96516659) :)
А 2.5 хотят EOL в 2017

Profile

metaclass: (Default)
metaclass

April 2017

S M T W T F S
      1
2345678
9101112 131415
16171819202122
23242526272829
30      

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 25th, 2017 12:44 am
Powered by Dreamwidth Studios