Чи відновлення бази даних SQL з резервного копіювання відновить його індекси?

10

Чи відновлення бази даних SQL з резервного копіювання відновлює її таблиці та індекси з нуля? Або він підтримує його в тому ж внутрішньому фізичному порядку, в якому він був під час резервного копіювання?

Ми використовуємо SQL 2000 із стисненою резервною копією Quest Lightspeed, якщо це має значення.

sql-server restore

— БредК
джерело

16

Відповідь - ні, для будь-якого програмного забезпечення для резервного копіювання.

Резервне копіювання - це фізична операція, а не логічна операція. Він зчитує всі розширення, що містять виділені сторінки (тобто, навіть якщо виділяється лише одна сторінка із 8-сторінкового ступеня, вона створить резервну копію всього 64K-ступеня), і це робить у фізичному порядку.

Відновлення - це фізична операція, а не логічна операція. Він розкладає фрагменти на належні їм місця у файлах даних.

Перебудова індексу (або чогось подібного) - це логічна операція, яку необхідно зареєструвати. Резервне копіювання та відновлення маніпулюють файлами даних безпосередньо, не проходячи через буферний пул, що є однією з причин, чому цього неможливо зробити. Ще однією причиною цього не вдається зробити те, що резервне копіювання та відновлення не мають розуміння того, що міститься в даних, що резервуються.

Основна причина цього неможливо зробити в тому, що переміщення сторінок під час операції відновлення порушить вказівники b-дерева. Якщо сторінка A вказує на сторінку B, але на сторінку A переміщується процес відновлення, то як сторінка B оновлюється, щоб вказувати на сторінку A? Якщо він оновлюється відразу, він може бути перезаписаний рештою процесу відновлення. Якщо його відкладено-оновлено, що робити, якщо процес відновлення відновив журнал транзакцій, який видалив сторінку A або сторінку B? Це просто неможливо зробити.

Підсумок - резервне копіювання та відновлення - це фізичні операції, які ніколи не змінюють дані.

Сподіваюся, це допомагає!

PS Хоча це питання не стосується безпосередньо, перегляньте статтю, яку я написав для журналу TechNet за липень, де пояснюється, як працюють різні резервні копії внутрішньо: Розуміння резервних копій SQL Server . Журнал Вересень матиме наступний у серії про розуміння реставрацій.

— Пол Рандал
джерело

2

Мені подобається те, що ви пояснили, що індексація - це логічна операція.

— Джим Б

Ах, це має сенс. Резервне копіювання захоплює 64 тис. Фізичних розширень, а не 8 тис. Сторінок даних.

— BradC

Це нісенітниця. Операції з резервного копіювання часто стискають дані, які вони створюють у резервному режимі, і це таке «зміна», про яке ми говоримо: Зрештою, індекси можна заново створити з таблиць, вони є зайвими даними (за умови, що схема резервна копія , звичайно). Справжня причина - лінь з боку розробників баз даних.

— Джон

1

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

— Пол Рандал

Випадання та відновлення індексів - це тип стиснення, і стиснення може змінити що завгодно, залежно від типу стиснення. Стиснення втрат при обробці зображення все ще називають стисненням. Будь-який механізм, який представляє подану інформацію в меншому просторі, є формою стиснення, а випадання індексів є тривіальним прикладом цього. Хоча повільний час відновлення може бути справжнім аргументом, принаймні, проти того, щоб впровадження було вагомим починанням.

— Іван,

6

Рідний резервного копіювання SQL є дампом сторінку за сторінкою файлів резервного копіювання, так що відповідь є «ні». Резервне копіювання світлодіодної швидкості Quest, ймовірно, використовує якийсь алгоритм стиснення стиснення, але він все ще не "відновить" файли даних або індекси, що займе жахливо велику кількість часу у великій базі даних.

— Аарон Алтон
джерело

Так, але вона все одно повинна записувати кожну сторінку на диск. Чому б не написати їх у логічній послідовності, а не у фрагментованому порядку? (Можливо, це більше питання щодо резервного копіювання, а не відновлення питання: чи резервна копія записує сторінки у фізичному порядку чи в логічному порядку?)

— BradC

якщо припустити, що був продукт, який записував дані в порядку індексу, в якому порядку ви б хотіли зберегти таблицю? Скажімо, у мене є таблиця з 3 стовпцями product_id, найменуванням продукту та ціною. За яким правильним стовпцем слід сортувати, щоб зберегти сторінки в індексованому порядку? До речі, нічого не заважає вам індексувати всю таблицю (кластерний індекс) або кожен з рядків (складений індекс).

— Джим Б

@Jim B: Це просто. Таблиці будуть збережені в кластерному порядку індексу. Некластеризовані індекси зберігатимуться в ключовому порядку. Купи зберігатимуться в оригінальному (несортивному) порядку. (Аарон і Пол згадували вагомі причини, що резервне копіювання / відновлення не робить цього. Неможливо визначити "бажаний порядок" - це не одна з цих причин. Або ж, провести повне відновлення індексу, виникне та сама проблема. )

— BradC

Дані створюються резервними копіями у тому самому фізичному порядку, у якому вони зберігаються у файлах бази даних. Коли дані відновляються, вони відновлюються в тому ж порядку, на якому вони були створені. SQL не пересуває дані з різних причин. У тому числі, що можуть виникнути проблеми з відновленням журналів та виправленням сторінок, не кажучи вже про величезну кількість додаткового часу, необхідного для переміщення даних на багатобанкерних базах даних.

— mrdenny

2

Резервне копіювання робиться регулярно і дуже часто (сподіваюся). Тож дизайнери переконалися, що резервне копіювання є максимально швидким. Який найшвидший ввід / вивід? Послідовна. Ви читаєте блоки з дисків у точному фізичному порядку, у вас найкраща продуктивність.

Чому на Землі база даних повинна щомісяця виконувати громіздкі операції випадкового вводу / виводу , збиваючи голови диска всюди? Різниця складе близько двох порядків. У цьому немає можливого виграшу.

— кубанчик
джерело

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

— перевершують

0

Хммм. BradC, чи працювали ви раніше з Firebird / Interbase - де основна утиліта / API для резервного копіювання / відновлення більше схожа на "Скопіювати базу даних ..." SSMS / EM? Якщо так, знайте, що MS SQL Server НЕ подобається.

Резервне копіювання SQLServer - це більше дамп бази даних, який відновлюється "AS-IS" - тому він більше схожий на зручну онлайн-клавішу для операції "від'єднати-копіювати-повторно приєднати до іншого місця". Відновлена база даних є майже точною копією оригінального файлу бази даних (майже тому, що ви можете змінити розміщення файлів баз даних відновленої бази даних) ...

— Фабрикіо Арауджо
джерело