Вы пока базу поремонтируйте, а мы с ней поработаем

 Есть такое понимание у людей, когда база вроде бы рабочая, но где-то там что-то повреждено. Например, всё работает, кроме запросов к одной из таблиц.

Ну и, останавливать работу нельзя, поврежденная часть вроде бы не каждодневно используется, можно потерпеть, пока нам "базу отремонтируют".

Но увы, нет. Редко какая база (в смысле разработки и предметной области) позволяет "склеить" базу из двух - починенной и "рабочей". Можно даже сказать, что вообще никакая.

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

Так что, единственный вариант ремонта:

- останавливаем работу
- передаем базу в ремонт
- сидим ждем, пока починят
- получаем отремонтированное, продолжаем работать.

И тут, конечно, засада в том, что длительность ремонта неизвестна. Поэтому что?
Да, надо чаще делать бэкапы! :-) Вполне вероятно, что восстановиться из вчерашнего бэкапа и перевбить данные за день будет гораздо дешевле, чем тупо сидеть пару дней, пока базу починят (еще и с неизвестным результатом).

- А вы базы чините? - Ага...

 Да, с 2002 года у нас есть услуга платного ремонта баз данных СУБД Firebird и InterBase. В процессе ручного ремонта для облегчения наших усилий мы выпустили утилиту для ремонта этих БД, под названием FirstAid (для России и для всего мира). И она чинит примерно 70% наиболее частых повреждений (Direct). А если не чинит, то даже при самых сильных повреждениях можно экспортировать уцелевшее содержимое БД в новую БД (Extract).

Как и что делать, можно прочитать в документации (см. раздел documentation, слева). Также есть общее описание типов повреждений БД, и что можно сделать в этом случае штатными средствами Firebird и InterBase.

Собственно, зачем я всё это пишу. Дело в том, что весьма часто, когда повредилась база данных, администратор этой БД начинает в панике нам звонить. Но по устному телефонному разговору мало что можно понять, в смысле, для оценки ремонтопригодности БД. Поэтому, телефонный разговор на эту тему сводится к следующему

- здравствуйте! а вы базы чините?
- да, чиним
- ок, хорошо

Никакой более ценной информации из этого разговора практически никогда нельзя извлечь.

Всё равно требуется письмо на support@ibase.ru (или support@ib-aid.com), где будет перечислено:

- что за ошибка при соединении с БД, примерно в результате какого события она произошла
- размер базы данных, ОС, версия Firebird или InterBase
- лог диагностики из FirstAid (это бесплатно)

Если нам что-то будет неясно, мы уточним технические вопросы опять же, по email.

В общем, я думаю, вы поняли. Что звонить нам не надо. Да, мы чиним базы Firebird и InterBase. Точно. Конечно, можно и позвонить. Но вы ведь уже прочитали этот пост.

SMR и кое-что еще

Наверное, уже все (кому интересно) в курсе про скандал со спецификой записи на некоторых моделях жестких дисков. Эта специфика называется SMR.
Вот отличный пост на хабре, где объясняется проблема и приведен перечень дисков, где реализована данная технология:
https://habr.com/ru/post/500214/

Цитата:
"SMR хорошо подходит для обеспечения большой емкости по невысокой цене, когда число операций записи мало, а чтения — велико."
То есть, для баз данных даже со средней интенсивностью записи диски с такой технологией не подходят. И еще они не только сбоят в raid, но и могут давать невосстановимые ошибки.


Так что, рекомендую прочитать статью, а также изучить комментарии. Там я нашел несколько интересных моментов:
https://habr.com/ru/post/500214/#comment_21571374
"У меня лежит ящик разных SSD, которые после ремонта живут без проблем, пока не отрубишь им питание на две недели. После чего файлы уже не прочитать, или ссд вообще не включится. Память «стекает», это нормально, и чем больше износ, тем быстрее. Вендоры гарантируют сохранность данных в 3 месяца (Для TLC). Гуглите даташиты на энтерпрайз ссд, где информация более честная, чем в потребительском сегменте. PS: да, и регулярно на рекавери тащат флешки USB, с которых файлики полутора-двугодичной давности не читаются совсем, годовалые — с большим трудом, свежие — норм. Флешки разносольного качества, как ни странно — много оригинальных кингстонов".

и дальше в этой же ветке комментов:
"MicroSD и USB флешки не занимаются Self Refresh, поэтому их от потери данных не спасет постоянное нахождение под питанием. Большое количество недорогих SSD на Phison — я точно знаю что тоже не рефрешат себя."

Понятно, что обо всём этом можно было догадываться, но вот чтобы прямо явно сталкиваться - лучше не надо.

Вебинар по InterBase 2020

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

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