17.1.17

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

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

Почему?
Firebird и InterBase, как и любые другие СУБД, используют т.н. "словарь метаданных". Т.е. описания структуры таблиц хранятся в системных таблицах. Структура таблиц может меняться, при этом в системных таблицах появляется новый формат данных, и сами данные в базе хранятся как в старых, так и в новых форматах, одновременно.
Прикладные базы данных на Firebird и InterBase в этом случае "делятся" на три типа
  1. Метаданные не меняются. Как БД разработана, так она и работает годами, без изменений.
  2. Метаданные изредка обновляются, при обновлении версии программ и БД
  3. Метаданные меняются на ходу, т.к. пользователь через программу имеет возможность добавления или изменения столбцов у таблиц БД
Чем выше номер "типа", тем чаще требуется делать backup/restore или получать копию БД.
Если в базе повреждены метаданные, то FirstAid Extractor может использовать копию метаданных, чтобы вытащить максимум данных (одной из функций DataGuard является периодическое сохранение снимка метаданных в резервное хранилище).
Однако, если копия метаданных устарела, а описание форматов в БД повреждено, FirstAid Extractor не может определить тип данных, и корректно извлечь данные из поврежденной БД.

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

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

7.12.16

Жертвы тиража N 2

Продолжение темы в исходной "Жертвы тиража". Писал где-то в 2006-2007 году. Нашел как черновик, решил опубликовать, чего пропадать тексту :-)

http://www.osp.ru/os/2005/11/072.htm
7 проблем программной инженерии

середина 80-ых - нет документации (не в печатном виде), интернета, почты, форумов (!). Спросить не у кого. Программистов мало, квалификация повышается очень быстро. Малое число библиотек, но их высокое качество.
90-ые - появление ООП, неприятие, развитие настольных компьютеров, появление "персональных прикладных задач", рост числа программистов.
конец 90-х - инструментарий вроде Delphi и т.п. в массах. не напрягает изучением ООП, позволяет "рисовать" приложения.
параллельные foxpro, clipper, как контузия.
интернет - документация, форумы, компоненты, библиотеки - море.
книги - привести число по Delphi на интернет-магазинах.
books.ru - 184, Ozon - 212, bolero.ru - 204.
torry.ru,
форумы - sql.ru, delphiplus.org, мастера Delphi, королевство Delphi, codeby.net,
низкие зарплаты в регионах, отток разработчиков (нечего делать, кроме аутсоурсинга).
высокие зарплаты в мегаполисах, завышение резюме.

...
Инструментарий, вымывание кадров. ссылка на osp.ru, 11 номер от 2005 года.
...
энтузиазм, альтруизм, прагматизм, апатия. Еще в конце 90-ых годов прагматизм начал преодолевать энтузиазм и альтруизм. Безусловная смена работы максимум через 5 лет.
...
сложность найти студентов "на вырост". В любом случае, если "кадр" квалифицированный, дольше 2-3 лет он на фирме не задержится. Это срок реализации от начала до конца максимум двух-трех серьезных проектов. То есть, обучением новых кадров надо заниматься постоянно, понимая, что на длительный срок их удержать не получится (см. выше о прагматизме).
...
синдром рассеянного внимания. неспособность дочитать статью до конца. невнимательность, нежелание читать вообще (дети, рожденные в конце 80-начале 90).
изменения на генетическом уровне - шутка "ошибка в ДНК" становится реальностью.
http://offline.computerra.ru/2002/468/21520/
http://www.computerra.ru/think/239597/ ?
http://www.computerra.ru/features/243301/

и еще одна причина - демографическая.
http://www.gks.ru/free_doc/2005/b05_13/04-07.htm
Примерно в 2000 году я наткнулся на статью в Комсомолке по поводу призыва. Там говорилось, что при таком темпе снижения рождаемости в 2008 году будет в 3 раза меньше лиц призывного возраста, чем в 2000 году.
Посмотрите на график, он построен по цифрам в приведенной ссылке.
Не в 3, но в 2 раза это точно - сейчас молодых людей призывного возраста 12 миллионов человек, а через 5 лет их будет в 2 раза меньше. Я не стал рисовать весь график целиком, т.к. выше 40 лет люди программируют разве что для удовольствия, да и начиная с 25-29 уже переходят на "руководящие должности". То есть весь цвет программирования - это с 19 до 35 лет. Начиная с возраста в 20 лет идет "убыль" населения - смертность по разнообразным причинам. То есть, квалифицированные кадры или вымирают, или уходят на более высокие должности, а на их место приходят... кто?

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

13.9.16

Век живи, век учись

Если при restore бэкапа InterBase gbak вам выдает ошибку
decompression length error
то скорее всего бэкап был сделан другой (предыдущей) версией gbak (или InterBase).
В этом случае или надо взять gbak.exe от нужной версии, или сделать бэкап повторно с указанием опции -expand.

Получается, что у InterBase опцию -expand желательно указывать при бэкапе? И у Firebird?