Восстанавливает ли индексы восстановление базы данных SQL из резервной копии?

10

Восстановление базы данных SQL из резервной копии перестраивает ее таблицы и индексы с нуля? Или он сохраняет тот же внутренний физический порядок, в котором он находился во время резервного копирования?

Мы используем SQL 2000 со сжатым резервным копированием Quest Lightspeed, если это имеет значение.

sql-server restore

— BradC
источник

16

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

Резервное копирование - это физическая операция, а не логическая операция. Он читает все экстенты, содержащие выделенные страницы (т. Е. Даже если выделена только одна страница из 8-страничного экстента, он создает резервную копию всего экстента размером 64 КБ) и выполняет его в физическом порядке.

Восстановление - это физическая операция, а не логическая операция. Он устанавливает экстенты в их законных местах в файлах данных.

Восстановление индекса (или чего-либо подобного) - это логическая операция, которая должна быть зарегистрирована. Резервное копирование и восстановление манипулируют файлами данных напрямую, без прохождения через буферный пул, что является одной из причин, почему это невозможно сделать. Другая причина, по которой это невозможно сделать, заключается в том, что резервное копирование и восстановление не имеют представления о том, что содержится в резервных копиях данных.

Однако главная причина, по которой это невозможно сделать, заключается в том, что перемещение страниц во время операции восстановления нарушило бы указатели b-дерева. Если страница A указывает на страницу B, но страница A перемещается процессом восстановления, как страница B обновляется, чтобы указывать на страницу A? Если он обновляется сразу, то он может быть перезаписан остальной частью процесса восстановления. Если оно отложено-обновлено, что если процесс восстановления восстановил некоторый журнал транзакций, который удалил страницу A или страницу B? Это просто невозможно сделать.

Итог - резервное копирование и восстановление - это физические операции, которые никогда не изменяют данные.

Надеюсь это поможет!

PS Хотя этот вопрос не касается непосредственно, ознакомьтесь со статьей, которую я написал для июльского журнала TechNet Magazine, в которой объясняется, как различные резервные копии работают внутри: Общие сведения о резервных копиях SQL Server . В сентябрьском журнале будет опубликована следующая статья о восстановлении понимания.

— Пол Рэндал
источник

2

Мне нравится тот факт, что вы объяснили, что индексирование - это логическая операция.

— Джим Б

Ах, это имеет смысл. Резервное копирование захватывает полные 64 КБ физических страниц, а не 8 КБ страниц данных.

— BradC

Это нонсенс. Операции резервного копирования часто сжимают данные, для которых они резервируются, и мы говорим о таком «изменении»: в конце концов, индексы могут быть воссозданы из таблиц, они являются избыточными данными (при условии, что схема резервируется). , конечно). Настоящая причина - лень со стороны разработчиков баз данных.

— Джон

1

@ Джон Что ты говоришь, чепуха? Сжатие здесь нигде не упомянуто - просто перестроение индексов, которое ни в коем случае не совпадает со сжатием (которое не изменяет страницы или их расположение в базе данных во время восстановления, тогда как перестройка делает). Воссоздание индексов с нуля во время восстановления будет невероятно медленным по сравнению с простым восстановлением из резервной копии как есть. Я думаю, что вы здесь что-то не так поняли.

— Пол Рэндал

Удаление и восстановление индексов - это тип сжатия, и сжатие может измениться в зависимости от типа сжатия. Сжатие с потерями при обработке изображений все еще называется сжатием. Любой механизм, который представляет данную информацию в меньшем пространстве, является формой сжатия, и удаление индексов является тривиальным примером этого. Однако медленное время восстановления может быть реальным аргументом, по крайней мере, против того, чтобы реализация была стоящей попыткой.

— Джон

6

Родной резервного копирования SQL является дампом страницу за страницей файлов резервного копирования, так что ответ есть «нет». Резервное копирование Quest LightSpeed, вероятно, использует какой-то алгоритм сжатия сжатия, но он все равно не будет «перестраивать» файлы данных или индексы, что потребовало бы ужасно большого количества времени в большой базе данных.

— Аарон Альтон
источник

Да, но это все равно должно записывать каждую страницу на диск. Почему бы не написать их в логической последовательности, а не в фрагментированном порядке? (Может быть, это скорее вопрос о резервной копии, а не вопрос о восстановлении : записывает ли резервная копия страницы в физическом порядке или в логическом порядке?)

— BradC

при условии, что был продукт, который записывал данные в порядке индекса, в каком порядке вы хотите сохранить таблицу? Допустим, у меня есть таблица с 3 столбцами product_id, productname и price. Какой правильный столбец сортировать, чтобы сохранить страницы в индексированном порядке? Кстати, ничто не мешает вам индексировать всю таблицу (кластеризованный индекс) или каждую строку (составной индекс).

— Джим Б

@ Джим Б: Это легко. Таблицы будут сохранены в порядке кластерного индекса. Некластеризованные индексы будут храниться в ключевом порядке. Кучи будут храниться в оригинальном (несортированном) порядке. (Аарон и Пол упомянули веские причины, по которым резервное копирование / восстановление не делает этого. Невозможность определить «предпочтительный порядок» не является одной из этих причин. В противном случае выполнение полного перестроения индекса будет иметь ту же проблему. )

— BradC

Резервное копирование данных осуществляется в том же физическом порядке страниц, в котором они сохраняются в файлах базы данных. Когда данные восстанавливаются, они восстанавливаются в том же порядке страниц, в котором они были сохранены. SQL по разным причинам не перемещает данные. В том числе, что могут быть проблемы с транзакциями, восстанавливающими журналы, и проблемы с цепочками страниц, не говоря уже о огромном количестве дополнительного времени, необходимого для перемещения данных по многотуберкулезным базам данных.

— Мрденный

2

Резервное копирование делается регулярно и очень часто (я надеюсь). Поэтому дизайнеры позаботились о том, чтобы резервное копирование было максимально быстрым. Какой самый быстрый ввод / вывод? Последовательная. Вы читаете блоки с дисков в точном физическом порядке, у вас лучшая производительность.

С какой стати база данных должна выполнять громоздкую случайную операцию ввода-вывода каждую ночь , разбивая головки дисков повсюду? Разница будет около двух порядков. В этом нет никакой возможной выгоды.

— kubanczyk
источник

Я согласен с вашей общей точкой зрения, но в зависимости от базовой конфигурации хранилища случайный ввод-вывод может быть не на несколько порядков хуже, чем последовательный ввод-вывод (например, диск SAN, который распределен по десяткам шпинделей). Фактически, если файл данных фрагментирован на жестком диске, то даже «последовательный» ввод-вывод на самом деле не является последовательным. Но точки Пола в любом случае переопределяют это (проблема с обновлением указателей, и что дефрагментация должна быть

— записанной

0

Хммм. BradC, вы работали с Firebird / Interbase раньше - где основная утилита резервного копирования / восстановления / API больше похожа на «Копировать базу данных ...» SSMS / EM? Если так, знайте, что MS SQL Server НЕ нравится.

SQLServer Backup - это больше дамп базы данных, который восстанавливается «как есть», так что это больше похоже на удобный онлайн-ярлык для операции «отсоединить-копировать-подключить в другом месте». Восстановленная база данных является почти точной копией исходного файла базы данных (почти потому, что вы можете изменить размещение файлов базы данных восстановленной базы данных) ...

— Фабрицио Араужо
источник