Начало » Использование СУБД » Firebird, HQbird, InterBase » Проверялка базы
| Проверялка базы [сообщение #5480] |
Tue, 24 September 2024 17:21  |
ggreggory
Сообщений: 77
Зарегистрирован: July 2022
|
Member |
|
|
Приветствую знатоков и разработчиков!
WI-V3.0.8.33535 Firebird 3.0 (Windows/Intel/i386), ODS 12.0
Хочется иметь какой-то инструмент, который бы отвечал на вопрос - база в порядке или нет. С тем, чтобы в определенной ситуации (или с определенной периодичностью) запускать и если что - бить тревогу.
Попробовал isc_action_svc_validate. Но! Она выдает большой объем текстовой информации, а мне нужен ответ - Да или Нет. Как понимаю - решение в анализе выводимой информации, поиска слов типа "ERROR" или что-то в этом роде.
Вопрос: на какие слова завязаться?
И, как пример, вот у меня эта проверялка выдает:
16:32:42.46 Warning: Pointer page 807 {sequence 0} bits {0x05 full, swept} are not consistent with data page 6869 {sequence 373} state {0x01 full}
Error Message:
----------------------------------------
Unsuccessful execution caused by system error that does not preclude successful execution of subsequent statements.
BLOB not found.
-------------------------------------------------------------------------------------------------------------------
SQLCODE: -901
SQLSTATE: HY000
GDSCODE: 335544382
|
|
|
|
| Re: Проверялка базы [сообщение #5493 является ответом на сообщение #5480] |
Wed, 25 September 2024 12:30  |
sashaua01
Сообщений: 26
Зарегистрирован: July 2022
|
Junior Member |
|
|
может не совсем то что Вам надо. У нас есть такой велосипед.
Микросервис на пайтоне + фласк который имеет ендпоинт /heath , внутри этот ендпоин делает простой селект в базе (select max(id) from customers) и если все ок возвращает код 200, эсли что-то пошло не так возвращает код 500.
В системе мониторинга есть синтетический тест https://dba.vltava.local/heath и если ответ <> 200 будет аларм.
Примитивный тест жива база или нет.
[Обновления: Wed, 25 September 2024 12:31] Известить модератора |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Проверялка базы [сообщение #5505 является ответом на сообщение #5504] |
Fri, 27 September 2024 07:54 |
basid
Сообщений: 166
Зарегистрирован: June 2022
Географическое положение: Asia/Irkutsk
|
Senior Member |
|
|
Не пытайтесь решать нерешаемое.
gbak:ERROR: Error while parsing procedure ...
gbak:ERROR: action cancelled by trigger ...
gbak:ERROR: attempt to store duplicate value ...
Это всё ошибки восстановления из успешно сделанного бэкапа базы.
Первая строчка - некорректная правка метаданных. Может возникнуть для PSQL-кода, который уже давно и никем не используется. В исходной базе - плевать, но восстановиться из бэкапа - невозможно.
Вторая строчка - не хватило места для временных файлов на этапе активации индексов. Вообще ничего не говорит о "здоровье" исходной базы.
Третье - дубли в первичном/уникальном индексе, которые надо отдельно искать. А потом - решать, что делать с найденным.
Дубли, в общем и целом, могут и не влиять на работу приложения. Но возможны ньюансы.
А ещё есть всякие "приколы" с повреждениями отдельных записей/блобов.
Или, например разная видимость "по индексу" и "натуралом". Причём в обоих вариантах расхождения.
database file appears corrupt ...
internal Firebird consistency check ...
Это уже разновсяческие варианты физических повреждений, включая разную экзотику, которую сложно обнаружить "в дикой природе".
А ещё есть предупреждения, которые сами по себе некритичны, но которые указывают на какие-то другие проблемы.
Приведённое для примера, надо сказать, далеко не всё, с чем можно столкнуться.
А ещё есть уже исправленные ошибки "всякой древности" вроде "вашей" 3.0.8.
И вот вы, такой д'Артаньян, собираетесь решать - повреждена ли ваша база. Оперативно и онлайн.
Если СУБД Firebird работает с файлом базы, то база, в целом, исправна. Но могут быть не в порядке данные в этой вашей базе.
Хотите уверенности в завтрашнем дне?
Регулярно проверяйте метаданные - быстро и страхует от некоторых сюрпризов.
Регулярно проверяйте восстановимость бэкапов.
Регулярно (но реже) проверяйте физическую целостность на копии файла базы.
Две последние проверки не заменяют одна другую - они про разное.
P.S.
Совсем забыл - не забывайте "почитывать" firebird.log и системные журналы 
[Обновления: Fri, 27 September 2024 08:00] Известить модератора |
|
|
|
|
|
|
|
|
|
| Re: Проверялка базы [сообщение #5515 является ответом на сообщение #5507] |
Mon, 30 September 2024 07:23 |
fraks
Сообщений: 140
Зарегистрирован: June 2022
Географическое положение: Новосибирск
|
Senior Member |
|
|
basid писал(а) Fri, 27 September 2024 19:41
gbak -se ... -m -b -g источник stdout | gbak ... -m -c stdin приёмник -
Как-то это похоже на "Вредные советы" Остера.
п.1 - это бэкап и рестор базы, без сохранения файла бэкапа.
Во-первых, рестор - это длительная ресурсоемкая операция, на рабочих базах может занимать часы а то и сутки, рекомендовать такое как панацею...
Во-вторых, в данном примере не вижу что бы кто-то ловил вывод в котором могут быть сообщения об ошибках.
В-третьих, смысл проверять свежетресторенную базу заметно меньше чем ту что работает, и части ошибок в отресторенной может и не быть, а возможно что база которая смогла отресториться, пройдет тест без ошибок. Тут я не уверен, но как минимум про такой вариант нужно подумать.
В четвертых. Если рестор не прошел то это не значит что восстановить ничего нельзя. Но при передаче через пайп промежуточного файла не остается, и повторно ресторить неоткуда. А делать опять бэкап, как тут показано - может не получиться, по причине того что база при очередной попытке может быть уже нечитабельной, если к примеру диск посыпался.
Ну и по проверке.
Бэкап должен быть. Точка. Свежий. И если подходить к проверке базы вышеупомянутым образом, т.е. gfix -v по отресторенной базе, нужно взять последний из сделанных и сохраненных бэкапов, с него отресториться и проверяться, а не разносить эти две операции по разным кустам. Легко может выйти что проверку таким образом прошли, но в результате ничего не сохранили, или сохранили отресторенную базу. В принципе, бэкапиться таким образорм тоже можно, и даже есть некоторые плюсы, но может быть крайне накладно по ресурсам. Процессор, ввод-вывод, место на диске.
P.S.
Че-то я несколько прогнал, не обратил внимания на ключик -m.
Извиняюсь.
[Обновления: Mon, 30 September 2024 07:28] Известить модератора |
|
|
|
| Re: Проверялка базы [сообщение #5516 является ответом на сообщение #5515] |
Mon, 30 September 2024 09:55 |
basid
Сообщений: 166
Зарегистрирован: June 2022
Географическое положение: Asia/Irkutsk
|
Senior Member |
|
|
Также обращаю внимание, что gfix -v работает (должен работать) на файловой копии исходной базы, а не на базе, восстановленной из бэкапа.
И, да: восстановление базы из бэкапа - процесс длительный. Но бэкап, не проверенный на восстановимость - полезен крайне условно: очень плохо, когда неизвестно ни сколько времени потребует восстановление из такого бэкапа, ни сколько ресурсов для этого понадобится.
P.S.
Если "нет лишнего" на "рабочем сервере", то, немного поднапрягшись, можно сделать отдельный бэкап сервер, где никого не будет напрягать ни время восстановление, ни количество одновременно восстанавливаемых баз. Когда бэкапы делаются раз в сутки, а восстанавливаются - дольше суток.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Переход к форуму:
Текущее время: Wed Dec 18 11:57:06 GMT+3 2024
Общее время, затраченное на создание страницы: 0.01394 секунд
|
SQLRU.net
Поиск
Помощь
Участники
Регистрация
Вход
Начало
