Вебинар по InterBase 2020

Завтра (9 апреля 2020) будет вебинар по InterBase 2020 с Embarcadero.
Расскажу про все интересные фичи, зачем, как использовать, и т.д.

upd: запись доступна тут
https://www.youtube.com/watch?v=I7Y920kSgKQ&feature=youtu.be

gbak -b -e. Сжимать или не сжимать?

При бэкапе (gbak -b) данные по умолчанию сжимаются. Что там за сжатие, я понятия не имею (надо спросить у разработчиков). Но у gbak есть опция -e, которая это сжатие отключает.

Решил проверить, как это повлияет, и имеет ли смысл.

Взял базу TPCR размером 30 гигабайт, Firebird 3.0.3, и сделал несколько раз бэкап на другой диск.
Результат - с опцией -e быстрее на 7.5-7.9%. На 18-ти минутах это 1 минута.
Если же база гораздо больше, и бэкап идет, например 10 часов, экономия бы получилась примерно 46 минут. На 10-ти часах это имеет смысл, а вот если бэкап идет часа 2, не больше, то тогда разница не так существенна.

Другое дело, что обычный бэкап этой базы занимает 21 гигабайт. А вот с опцией -e - 34 гигабайта! На 30% больше обычного бэкапа, и на 10% больше базы (в которой еще и индексы есть).

Так что, небольшая выгода по времени оборачивается серьёзным проигрышем в размере.
Решайте сами, надо оно (-e) вам, или нет.

Особенности ремонта баз без бэкапов

При ремонте баз данных периодически сталкиваемся с полным отсутствием бэкапов или копий БД. Если в этом случае в базе повреждены метаданные, то восстановить уже практически ничего нельзя, даже при помощи FirstAid Extractor.

Почему?
Firebird и InterBase, как и любые другие СУБД, используют т.н. "словарь метаданных". Т.е. описания структуры таблиц хранятся в системных таблицах. Структура таблиц может меняться, при этом в системных таблицах появляется новый формат данных, и сами данные в базе хранятся как в старых, так и в новых форматах, одновременно.
Прикладные базы данных на Firebird и InterBase в этом случае "делятся" на три типа

1. Метаданные не меняются. Как БД разработана, так она и работает годами, без изменений.
2. Метаданные изредка обновляются, при обновлении версии программ и БД
3. Метаданные меняются на ходу, т.к. пользователь через программу имеет возможность добавления или изменения столбцов у таблиц БД

Чем выше номер "типа", тем чаще требуется делать backup/restore или получать копию БД.
Если в базе повреждены метаданные, то FirstAid Extractor может использовать копию метаданных, чтобы вытащить максимум данных (одной из функций DataGuard является периодическое сохранение снимка метаданных в резервное хранилище).
Однако, если копия метаданных устарела, а описание форматов в БД повреждено, FirstAid Extractor не может определить тип данных, и корректно извлечь данные из поврежденной БД.

Например, в таблицу добавлен столбец varchar(100). А копия метаданных есть только на момент до добавления этого столбца. При попытке вытащить данные Extractor-ом этого столбца в "выходной" таблице не будет.

Кроме того, если нет точной копии метаданных, результатом восстановления будет лишь набор таблиц, без индексов, процедур, триггеров и прочего. Такие восстановленные данные невозможно использовать с прикладной программой. Их можно использовать только для ввода в БД заново, вручную, и то, не всегда, особенно если "объект" в БД представляет собой данные в нескольких взаимосвязанных таблицах.