Одна область, которую я ещё не затронул в этой серии, — это RESTORE (восстановление), и здесь существует тонна заблуждений (так много, на самом деле, что я не могу охватить их все в одной статье!). В одной статье было разоблачено 6 мифов о контрольных суммах страниц, а в другой — 5 мифов о FILESTREAM, так что сегодня мне нужно их превзойти.
Миф №24: двадцать шесть мифов об операциях восстановления…
Все они ЛОЖНЫ!
24а) возможно выполнить восстановление на момент времени (point-in-time restore) с использованием WITH STOPAT для полной или дифференциальной резервной копии
Нет. Синтаксис выглядит так, будто это разрешено, но это всего лишь синтаксическое удобство, позволяющее следовать лучшей практике — использовать WITH STOPAT при каждой операции восстановления в последовательности восстановления на момент времени, чтобы случайно не пройти мимо нужного момента. Я подробнее рассказываю об этом в старой статье блога Debunking a couple of myths around full database backups.
24б) возможно продолжить последовательность восстановления после того, как пришлось использовать WITH CONTINUE_AFTER_ERROR
Нет. Если резервная копия повреждена настолько, что для её восстановления необходимо использовать WITH CONTINUE_AFTER_ERROR, это восстановление завершает вашу последовательность восстановления. Если вы восстанавливаете несколько резервных копий журнала транзакций и одна из них повреждена, вам следует тщательно подумать, хотите ли вы принудительно её восстанавливать. Принудительное восстановление повреждённой резервной копии журнала может означать, что в базе данных появятся несогласованные данные или, в худшем случае, структурное повреждение. Я бы в большинстве случаев рекомендовал не восстанавливать её.
24в) возможно восстановить разные части базы данных на разные моменты времени
Нет. Часть базы данных не может быть переведена в онлайн, если она не находится в той же временной точке, что и первичная файловая группа. Исключением, конечно, является файловая группа, доступная только для чтения.
24г) возможно восстановить файловые группы из разных баз данных вместе в новой базе данных
Нет. Все файлы в базе данных имеют GUID на странице заголовка файла. Если GUID не совпадает с GUID файла данных с идентификатором 1 в базе данных, он не может быть восстановлен как часть той же базы данных.
24д) восстановление удаляет фрагментацию индексов (или обновляет статистику и т.д.)
Нет. Что вы сохранили, то и получаете при восстановлении.
24е) возможно сжать базу данных во время восстановления
Нет. Это часто запрашиваемая функция в SQL Server — возможность восстановить очень большую, но в основном пустую базу данных на сервере разработки или QA и получить её размер, равный только объёму данных в исходной базе данных. Но это невозможно.
24ж) вы можете восстановить базу данных на любую нижестоящую версию SQL Server
Нет. Это один из самых распространённых мифов. SQL Server не может понимать базы данных из более новых версий (например, SQL Server 2005 не может понимать базу данных SQL Server 2008). Я уже много объяснял об этом в статье Миф DBA SQL Server на день: (13/30) вы не можете запускать динамические административные представления (DMV) в режиме совместимости 80.
24з) вы всегда можете восстановить базу данных в любом выпуске (Edition) SQL Server
Нет. В SQL Server 2005, если в базе данных есть секционирование таблиц/индексов, она может быть восстановлена только в выпуске Enterprise (или Enterprise Eval, или Developer). В SQL Server 2008 в этот список входят секционирование, прозрачное шифрование данных, отслеживание изменённых данных (change data capture) и сжатие данных. Я писал об этой проблеме, новом динамическом административном представлении, которое можно использовать в SQL Server 2008, и примере скрипта в статье блога SQL Server 2008: Does my database contain Enterprise-only features?.
24и) использование WITH STANDBY прерывает последовательность восстановления
Нет. Параметр WITH STANDBY позволяет получить доступ к базе данных в режиме «только для чтения», транзакционно-согласованном, в середине последовательности восстановления. Что касается последовательности восстановления, это то же самое, как если бы вы использовали WITH NORECOVERY. Вы можете останавливаться сколько угодно раз, используя WITH STANDBY. Это то, что использует доставка журналов (log shipping), когда вы просите разрешить доступ к вторичной базе данных между восстановлениями резервных копий журнала. Однако имейте в виду, что использование WITH STANDBY может вызвать некоторое, казалось бы, странное поведение — смотрите Why could restoring a log-shipping log backup be slow?.
24к) мгновенная инициализация файлов во время восстановления не работает, если база данных не была сохранена на сервере с включённой мгновенной инициализацией файлов
Нет. Использование мгновенной инициализации файлов полностью зависит от того, включена ли она на экземпляре SQL Server, выполняющем восстановление. В самой резервной копии нет ничего, что управляло бы этим. Вы можете многое прочитать о мгновенной инициализации файлов, начиная со статьи в блоге Миф: Мгновенной инициализацией файлов можно управлять изнутри SQL Server.
24л) RESTORE — лучший способ восстановиться после повреждения
Нет, не обязательно. В зависимости от того, какие у вас есть резервные копии, восстановление может быть лучшим способом восстановиться с нулевой или минимальной потерей данных, но оно может быть наааамного медленнее, чем запуск восстановления с некоторой потерей данных или извлечение повреждённых/утраченных данных из вторичной базы данных доставки журналов. Лучший способ восстановления после повреждения — это тот, который позволяет вам наилучшим образом соблюсти ваши соглашения об уровне обслуживания (SLA) по времени простоя и потере данных.
24м) вы можете создать резервную копию «хвоста журнала» (tail-of-the-log) после начала последовательности восстановления
Нет. Как только вы начинаете восстанавливать базу данных, вы теряете возможность создать резервную копию хвоста журнала. Самое первое действие в плане аварийного восстановления всегда должно заключаться в проверке, нужно ли создать резервную копию хвоста журнала, на всякий случай.
24н) вы всегда можете выполнить восстановление на момент времени, охватываемый резервной копией журнала
Нет. Если резервная копия журнала содержит минимально логируемую операцию (minimally-logged operation), вы не можете остановиться на моменте времени, который охватывается этой резервной копией журнала. Вы можете восстановить её только целиком. Это происходит потому, что резервная копия журнала, следующая за минимально логируемой операцией, должна включать экстенты данных, изменённые этой операцией, но в резервной копии нет ничего, что говорило бы когда эти экстенты были изменены (это был бы журнал транзакций, но он не был создан, потому что операция была минимально логируемой!). Вы можете выяснить, сколько данных будет включено в такую резервную копию журнала, используя скрипт из статьи New script: how much data will the next log backup include?.
24о) если резервное копирование завершилось успешно, то и восстановление также будет работать
Нет, нет, нет, нет. Файл резервной копии подобен файлу данных — он находится на подсистеме ввода-вывода. А что вызывает большинство повреждений? Подсистемы ввода-вывода. Вы должны периодически проверять, что ваши резервные копии всё ещё действительны, иначе вы можете получить неприятный сюрприз, когда случится бедствие. Смотрите Importance of validating backups. Другая вещь, которую следует учитывать: возможно, была создана внеочередная полная резервная копия или резервная копия журнала, которая прерывает вашу последовательность восстановления, если она недоступна. Смотрите BACKUP WITH COPY_ONLY – how to avoid breaking the backup chain.
24п) все типы страниц SQL Server могут быть восстановлены постранично (single-page restored)
Нет. Различные битовые карты распределения и критические страницы метаданных не могут быть восстановлены постранично (или исправлены с помощью автоматического восстановления страниц с использованием зеркалирования базы данных в SQL Server 200). Моя статья в блоге Search Engine Q&A #22: Can all page types be single-page restored? объясняет подробнее.
24р) использование RESTORE ... WITH VERIFYONLY проверяет всю резервную копию
Нет. Использование VERIFYONLY проверяет только то, что заголовок резервной копии похож на заголовок резервной копии. Только когда вы создаёте резервную копию с WITH CHECKSUM и выполняете RESTORE ... WITH VERIFYONLY и с WITH CHECKSUM, восстановление выполняет более обширные проверки, включая контрольную сумму всей резервной копии.
24с) возможно восстановить резервную копию зашифрованной базы данных без предварительного восстановления сертификата сервера
Нет. В этом и заключается весь смысл прозрачного шифрования данных. Потеряете сертификат сервера — потеряете базу данных.
24т) операция восстановления выполняет все операции REDO и UNDO после завершения последовательности восстановления
Нет. Часть восстановления REDO выполняется для каждой операции восстановления в последовательности восстановления. Часть UNDO не выполняется до тех пор, пока последовательность восстановления не будет завершена.
24у) сжатую резервную копию можно восстановить только с использованием Enterprise Edition в SQL Server 2008
Нет. Все выпуски могут восстановить сжатую резервную копию. Новшество в SQL Server 2008 R2: Standard Edition также может создавать сжатую резервную копию, как и Enterprise Edition.
24ф) при восстановлении базы данных из более ранней версии SQL Server можно пропустить процесс обновления
Нет. Невозможно пропустить какое-либо необходимое обновление или восстановление во время восстановления или присоединения базы данных.
24х) резервную копию, созданную в 32-разрядном экземпляре, нельзя восстановить в 64-разрядном, и наоборот
Нет. Нет никакой разницы в формате базы данных на разных архитектурах процессора.
24ц) восстановление базы данных — это всё, что нужно приложению для продолжения работы
Нет. Как и в случае с отказоустойчивым переключением на зеркало базы данных или вторичную базу данных доставки журналов, всё, что я называю «экосистемой приложения», должно быть на месте для работы приложения. Это может включать вспомогательные базы данных, учётные записи (логины), задания, хранимые процедуры и т.д.
24ч) для восстановления повреждённого файла из многофайловой файловой группы необходимо восстановить всю файловую группу
Нет. Так было раньше, до SQL Server 2000, но больше нет.
24ш) вы можете восстановить резервную копию в любую вышестоящую версию SQL Server
Нет. Вы можете восстановить базу данных, только отстающую на две версии (т.е. вы не можете напрямую восстановить базу данных SQL Server 7.0 в SQL Server 2008).
24э) операция восстановления всегда будет занимать то же время, что и операция резервного копирования
Нет. Существует множество факторов, которые могут повлиять на время восстановления — например, есть ли длительная транзакция, которую нужно откатить, или нужно ли создавать файлы базы данных и инициализировать их нулями. Никаких гарантий.
24ю) вы всегда должны удалять базу данных перед восстановлением
Нет. Если вы удалите базу данных, то файлы базы данных должны быть созданы и инициализированы нулями (или, по крайней мере, файл журнала, если у вас включена мгновенная инициализация файлов). Кроме того, у вас всегда должна быть копия повреждённой базы данных на случай, если восстановление по какой-либо причине не удастся.
Комментариев нет:
Отправить комментарий