Реконструкция базы данных — это процедура полной перестройки структуры хранения данных: создания новой базы (или новых файлов данных) и переноса в неё содержимого из старой, повреждённой или неэффективно организованной. К ней прибегают, когда обычное обслуживание — реиндексация, сжатие, очистка журналов — уже не решает проблему: файлы базы повреждены, производительность деградировала из-за сильной фрагментации, либо схема данных устарела настолько, что дальнейшая её поддержка обходится дороже, чем перестройка.
Термин используется в разных контекстах: администраторы SQL Server, MySQL, PostgreSQL и прикладных систем вроде 1С вкладывают в него близкий, но не идентичный смысл. Ниже разберём, что объединяет все эти сценарии, когда реконструкция действительно оправдана и как провести её без потери данных.
Что именно перестраивается при реконструкции
Под реконструкцией понимают не «ремонт» отдельных записей, а пересоздание физической и логической основы базы. В зависимости от задачи перестраиваются разные слои:
- 🗄️ Файлы данных — создаётся новый файл или набор файлов, куда данные переносятся постранично или построчно, с отбрасыванием повреждённых страниц.
- 🧱 Схема — таблицы, связи, ограничения целостности, типы полей пересоздаются по новой, часто изменённой структуре.
- 📇 Индексы — строятся заново на чистых страницах, что устраняет глубокую фрагментацию.
- 📜 Служебные метаданные — системные каталоги, статистика, настройки хранения.
Важно отличать реконструкцию от смежных операций. Восстановление из резервной копии возвращает базу к состоянию на момент бэкапа, а реконструкция работает с текущими данными, пытаясь спасти максимум из повреждённой или неэффективной структуры. Реиндексация перестраивает только индексы, не трогая сами таблицы и схему.
💡Реконструкция — это создание новой структуры базы с переносом данных из старой, а не «починка» существующих файлов на месте.