Восстановление базы данных SQL от резервного копирования восстанавливают ее индексы?
В зависимости от, "как виртуальный" Вы хотите добраться, vservers может быть опцией. Это сопоставимо с понятием Зон в соответствии с Солярисом 10, и это нисколько не сложно для установки.... Это не полная виртуализация хотя....
Ответ не, поскольку любое программное обеспечение для резервного копирования используется.
Резервное копирование является физической операцией, не логической операцией. Это читает все степени, содержащие выделенные страницы (т.е. даже при том, что только единственная страница от степени на 8 страниц выделяется, это скопирует всю 64K степень), и это делает это в физическом порядке.
Восстановление является физической операцией, не логической операцией. Это устанавливает степени в их законных местах в файлах данных.
Восстановление индекса (или что-либо как он) является логической операцией, которая должна быть зарегистрирована. Резервное копирование и восстановление управляют файлами данных непосредственно, не проходя пул буферов, который является одной причиной, почему это не может быть сделано. Другая причина это не может быть сделано, состоит в том, что резервное копирование и восстановление не имеют никакого понимания того, что содержится в сохраняемых данных.
Главная причина это не может быть сделано, однако, является этим, перемещающиеся страницы во время операции восстановления повредили бы указатели B-дерева. Если страница точки к странице B, но странице A перемещена процессом восстановления, как страница B обновляется для указания на страницу A? Если это обновляется сразу же, то это может быть перезаписано остальной частью процесса восстановления. Если это задержало - обновленный, что, если процесс восстановления восстановил некоторый журнал транзакций, который удалил страницу A или страницу B? Это просто не может быть сделано.
Нижняя строка - резервное копирование и восстановление являются физическими операциями, которые никогда не изменяют данные.
Надеюсь, это поможет!
PS, Хотя это непосредственно не рассматривает этот вопрос, проверяет статью, которую я написал в течение июля Журналу TechNet, который объясняет, как различные резервные копии работают внутренне: Понимание Резервных копий SQL Server. Сентябрьский журнал будет иметь следующее в ряду при понимании восстановлений.
-
1Я люблю то, что Вы объяснили, что индексация является логической операцией. – Jim B 29 June 2009 в 23:11
-
2А-ч, который имеет смысл. Резервное копирование захватывает полные 64k физические степени, не 8k страницы данных. – BradC 30 June 2009 в 00:03
Собственное резервное копирование SQL просто постранично дамп файлов резервных копий, таким образом, ответ, там "нет". Quest lightspeed копирует вероятное использование своего рода алгоритм сжатия сжатия, но он все еще не "восстановит" файлы данных или индексы, которые заняли бы страшно большое количество времени на большой базе данных.
-
1Да, но это должно записать каждую страницу в диск так или иначе. Почему бы не записать им в последовательности логических операций, вместо во фрагментированном порядке? (Возможно, это - больше резервное копирование вопрос вместо восстановление вопрос: резервное копирование пишет страницы в физическом порядке, или в логическом порядке?) – BradC 29 June 2009 в 22:44
-
2принятие там было продуктом, который выписал данные в индексном порядке, в каком порядке хотели бы Вы таблицу, сохраненную? Позволяет говорят, что у меня есть таблица с 3 столбцами product_id, productname, и цена. Который является корректным столбцом к виду на сохранить страницы в индексируемом порядке? BTW там - ничто мешающее Вам индексировать на всей таблице (кластерный индекс) или каждая из строк (сводный индекс). – Jim B 29 June 2009 в 23:19
-
3@Jim B: That' s легкий. Таблицы были бы сохранены в порядке кластерного индекса. Некластерные индексы были бы сохранены в ключевом порядке. "Куча" была бы сохранена в исходном (неотсортированном) порядке. (Aaron и Paul упомянули допустимые причины то резервное копирование/восстановление doesn' t делают это. Не будучи способен выяснять " предпочтенный order" isn' t одна из этих причин. Или иначе выполнение полного индекса восстанавливает, имел бы ту же проблему.) – BradC 29 June 2009 в 23:40
-
4Данные сохранены в том же самом физическом порядке страницы, что это сохраняется в в файлах базы данных. Когда данные восстанавливаются, они восстанавливаются в том же порядке страницы, что они были сохранены в. SQL doesn' t перемещают данные по различным причинам. Включая это могли быть проблемы с транзакциями, восстанавливающими журналы, и проблемы объединения в цепочку страницы, не говоря уже о серьезном количестве дополнительного времени должны были переставить данные вокруг по базам данных мульти-ТБ. – mrdenny 26 July 2009 в 10:38
Резервное копирование делается регулярно и очень часто (я надеюсь). Таким образом, разработчики удостоверились, что резервное копирование максимально быстро. Каков самый быстрый ввод-вывод? Последовательный. Вы читаете блоки из дисков в точном физическом порядке, у Вас есть лучшая производительность.
С какой стати база данных должна выполнять громоздкую случайную операцию ввода-вывода каждую ночь, повреждая верхние части дисков повсеместно? Различием были бы приблизительно два порядка величины. Нет никакого возможного усиления в этом.
-
1Я соглашаюсь с Вашей полной точкой зрения, но в зависимости от конфигурации базовой системы хранения, случайный ввод-вывод не может быть порядками величины, хуже, чем последовательный ввод-вывод (диск SAN, который распространен по десяткам шпинделей, например). На самом деле, если файл данных фрагментируется на жестком диске, то даже " sequential" ввод-вывод isn' t действительно последовательный вообще. Но Paul' s точки переопределяют это так или иначе (проблема с обновлением указателей, и та дефрагментация должна быть зарегистрированной операцией), – BradC 29 June 2009 в 23:58
Хм. BradC, Вы имеете работавшими с Firebird/Interbase прежде - где основная утилита/API резервного копирования/восстановления более подобна "База данных Копии..." SSMS/EM? Если так, знайте, что SQL Server MS не похож на это.
Резервное копирование SQLServer является больше дампом базы данных, который восстанавливается "ASIS" - таким образом, это больше похоже на удобный ярлык онлайн для "повторного прикрепления копии отсоединения на другом месте" операция. Восстановленная база данных является почти точной копией исходного файла базы данных (почти, потому что можно изменить размещение файлов базы данных восстановленной базы данных)...