|
Страница 20 из 38
Физически запорченная база и что с ней делать И так, сервер обвалился. Что может произойти с базой? В нормальных СУБД от этого должны оставаться недописанные страницы данных и элементы журнала транзакций. При следующем старте сервер должен прочитать журнал, проанализировать его и либо дописать то, что недописано, либо отмотать изменения назад согласно журналу. В общем, база возвращается в корректное состояние и начинается приём запросов от клиентов. Это как по уму. На практике же в InterBase иногда возникают ситуации, когда БД после падения восстанавливается не полностью и начинает работать с базой, в которой есть повреждённые элементы. Это касается падений по внутренним причинам, а не по внешним, типа отключения питания. При этом все дальнейшие операции чтения и обработки содержимого базы, похоже, выполняются в предположении, что база корректна. И при попытке обработать мусор могут возникнуть новые сбои, новое падение сервера, новые ошибки в структуре файла БД, и т. д. Чтобы гарантированно это предотвратить, нужно после каждой аварии до начала работы принимать меры по ремонту базы. Меры (с помощью ServerManager или аналогичных утилит командной строки) могут быть следующие: - Проверка базы (Validation). Проверяет корректность внутренних структур файла БД и выявляет порченные. Это в теории. На практике было достаточно много случаев, когда база, прошедшая проверку без ошибок, в дальнейшем вела себя, как откровенно некорректная, в том числе не снималась резервная копия. С другой стороны, были случаи, когда Server Manager страшно ругался, даже отказывался приступать к проверке, в то время, как с точки зрения клиентских подключений никаких аномалий не наблюдалось. В целом, если Validation ругается на базу, то в ней что-то не то (хотя и трудно понять насколько это опасно), и с ней лучше не работать. По крайней мере в данном сервере. Если же не ругается, то база возможно корректна, хотя и не обязательно. Обычно такая проверка достаточна, лишь если сервер упал по внешней причине.
- Снятие резервной копии (Backup). В ходе этого процесса сервер прочитывает всю базу и преобразовывает её содержимое в другой формат. При этом отбрасываются индексы, результаты компиляции хранимых процедур и прочее, что можно потом восстановить по данным и метаданным. В результате имеется шанс отловить те нарушения, которые игнорирует Validation. Хотя есть и такие, которые нормально попадают в резервную копию. В отличие от Validation, это ничего не лечит в исходной базе, а лишь проверяет её.
- Снятие и восстановление из резервной копии (Backup - Restore). Те ошибки, которые беспрепятственно попадают в резервную копию, обычно вызывают ругань при восстановлении. Иногда бывает возможно слегка обновить исходную копию базы и вновь прогнать Backup - Restore. Если удастся добиться, чтобы этот процесс прошёл полностью корректно, то это даст наибольшую гарантию, что база, получившаяся в результате не содержит ошибок. Кроме всего прочего, этот способ обычно сокращает объём базы, так как в процессе копирования производится "сборка мусора" и ликвидируется неиспользуемое пространство. Кроме этого, происходит балансировка деревьев в индексах и корректировка их статистических параметров.
|