Восстанавливает ли база данных SQL из резервной копии таблицы и индексы с нуля? Или он сохраняет его в том же внутреннем физическом порядке, в котором он был во время резервного копирования?
Мы используем SQL 2000 со сжатым резервным копированием Quest Lightspeed, если это имеет значение.
Ответ - нет, независимо от того, какое программное обеспечение для резервного копирования используется.
Резервное копирование - это физическая операция, а не логическая. Он считывает все экстенты, содержащие выделенные страницы (т.е. даже если выделена только одна страница из 8-страничного экстента, он создает резервную копию всего 64-килобайтного экстента), и делает это в физическом порядке.
Восстановление - это физическая операция, а не логическая. Он помещает экстенты на их законные места в файлах данных.
Восстановление индекса (или чего-то подобного) - это логическая операция, которая должна регистрироваться. Резервное копирование и восстановление управляют файлами данных напрямую, без прохождения через пул буферов, что является одной из причин, по которой это невозможно. Еще одна причина, по которой это невозможно сделать, заключается в том, что при резервном копировании и восстановлении не понимается, что содержится в данных, для которых выполняется резервное копирование.
Однако основная причина, по которой это невозможно сделать, заключается в том, что перемещение страниц во время операции восстановления приведет к поломке указателей b-дерева. Если страница A указывает на страницу B, но страница A перемещается в процессе восстановления, как обновляется страница B, чтобы она указывала на страницу A? Если он обновлен сразу, он может быть перезаписан остальной частью процесса восстановления. Если это отложенное обновление, что, если процесс восстановления восстановил какой-то журнал транзакций, который удалил страницу A или страницу B? Это просто невозможно.
Итог - резервное копирование и восстановление - это физические операции, которые никогда не изменяют данные.
Надеюсь это поможет!
PS Хотя здесь нет прямого ответа на этот вопрос, ознакомьтесь со статьей, которую я написал для журнала TechNet Magazine за июль, в которой объясняется, как различные резервные копии работают внутри: Понимание резервного копирования SQL Server. В сентябрьском журнале выйдет очередная серия о понимающих реставрациях.
А родной Резервное копирование SQL - это просто постраничный дамп файлов резервных копий, поэтому ответ - «нет». Резервное копирование Quest Lightspeed, вероятно, использует какой-то алгоритм сжатия, но он по-прежнему не будет «перестраивать» файлы данных или индексы, что для большой базы данных потребует ужасно большого количества времени.
Бэкап делается регулярно и очень часто (надеюсь). Поэтому дизайнеры позаботились о том, чтобы резервное копирование происходило как можно быстрее. Какой самый быстрый ввод-вывод? Последовательный. Вы читаете блоки с дисков в точном физическом порядке, у вас лучшая производительность.
Почему база данных должна выполнять громоздкую операцию случайного ввода-вывода каждую ночь, разбрасывая головки дисков повсюду? Разница будет примерно на два порядка. В этом нет никакой выгоды.
Хммм. BradC, работали ли вы с Firebird / Interbase раньше - где основная утилита резервного копирования / восстановления / API больше похожа на «Копировать базу данных ...» SSMS / EM? Если это так, знайте, что MS SQL Server НЕ нравится.
Резервное копирование SQLServer - это скорее дамп базы данных, который восстанавливается «КАК ЕСТЬ» - так что это больше похоже на удобный онлайн-ярлык для операции «отсоединение-копирование-повторное подключение в другом месте». Восстановленная база данных является почти точной копией исходного файла базы данных (почти потому, что вы можете изменить размещение файлов базы данных восстановленной базы данных) ...