Пришло время грандиозного финала!
Хотя было весело развенчивать все эти мифы, это было немного напряжённо — каждый день находить интересный и полезный миф для разоблачения.
В завершение я представляю вам 30 мифов о резервном копировании — по одному на каждый день апреля. Вчера вечером я сел писать эту статью и не добрал несколько мифов, поэтому обратился за помощью к великолепному сообществу SQL в Twitter — слишком много людей, чтобы перечислять (вы знаете, кто вы) — я благодарю вас!
Я очень надеюсь, что вам понравилась эта серия, и что множество мифов и заблуждений были развеяны раз и навсегда — я знаю, что многие из вас используют эти объяснения в качестве аргументов против сторонних поставщиков, разработчиков и других администраторов баз данных, которые настаивают на неправильных практиках.
Итак, поехали, последний выпуск…
Миф №30: разные мифы о резервном копировании…
Все они ЛОЖНЫ!!
Для хорошего введения в понимание резервного копирования и того, как оно работает, смотрите мою статью в TechNet Magazine «Understanding SQL Server Backups». [Примечание 2016 г.: статья была удалена — вместо этого можно почитать статьи о резервном копировании по адресу https://www.sqlskills.com/help/accidental-dba/]
30-01 операции резервного копирования вызывают блокировки
Нет, не для обычных DML. Операции резервного копирования не захватывают блокировки на пользовательских объектах. Резервное копирование создаёт очень высокую нагрузку чтения на подсистему ввода-вывода, поэтому может выглядеть, как будто рабочая нагрузка блокируется, но это не так. Она просто замедляется. Существует особый случай: резервная копия, которая должна захватить экстенты, изменённые массовыми операциями (bulk-logged extents), захватывает блокировку файла, которая может заблокировать операцию контрольной точки, — но обычные DML никогда не блокируются. Есть один случай блокировки: массовая загрузка не может начаться во время выполнения резервного копирования журнала, и наоборот.
30-02 переключение с модели восстановления FULL на BULK_LOGGED и обратно разрывает цепочку резервных копий журнала
Нет. Это не так. Однако переключение с FULL или BULK_LOGGED на SIMPLE действительно разрывает цепочку резервных копий журнала.
30-03 для перезапуска разорванной цепочки резервных копий журнала требуется полная резервная копия
Нет. Вы можете перезапустить цепочку резервных копий журнала как полной, так и дифференциальной резервной копией — чем угодно, что перекрывает разрыв в LSN с момента разрыва цепочки. Смотрите мою статью в блоге: Миф о том, что для перезапуска цепочки восстановления журнала требуется полная копия базы.
30-04 одновременное резервное копирование журнала невозможно во время выполнения полного или дифференциального резервного копирования
Нет, это изменилось в SQL Server 2005. Смотрите мою статью в блоге: Search Engine Q&A #16: Concurrent log and full backups.
30-05 полное или дифференциальное резервное копирование очищает журнал
Нет. Резервная копия журнала включает весь журнал с момента последней резервной копии журнала — ничто не может этого изменить, независимо от того, был ли этот журнал также скопирован полной или дифференциальной резервной копией. У меня был знаменитый спор в Twitter в прошлом году, и я написал эту статью в качестве доказательства: Заблуждения относительно журнала и резервных копий журнала: как самому проверить. В моделях восстановления FULL или BULK_LOGGED единственное, что очищает журнал, — это резервная копия журнала.
30-06 использование модели восстановления BULK_LOGGED для минимально логируемых операций уменьшает размер следующей резервной копии журнала транзакций
Нет. Минимально логируемая операция называется так потому, что логируются только распределения страниц. Резервная копия журнала должна содержать всю информацию, необходимую для воссоздания транзакции, поэтому резервная копия журнала, следующая за минимально логируемой операцией, должна содержать журнал плюс все экстенты, изменённые минимально логируемой операцией. Это приводит к тому, что резервная копия журнала будет примерно такого же размера, как если бы операция была полностью логируемой.
30-07 полные и дифференциальные резервные копии содержат только журнал, сгенерированный во время их выполнения
Нет. Полная или дифференциальная резервная копия содержит достаточно журнала, чтобы иметь возможность восстановить базу данных до транзакционно-согласованного представления базы данных на момент завершения части чтения данных резервного копирования (или настолько далеко назад, насколько позволяет самая старая запись журнала, ещё не обработанная транзакционной репликацией, — чтобы обеспечить правильную работу репликации после восстановления). Ознакомьтесь с этими двумя статьями для получения подробной информации:
- Debunking a couple of myths around full database backups
- Какая часть журнала транзакций попадает в FULL BACKUP
30-08 резервные копии всегда проверяют существующие контрольные суммы страниц
Нет. Это происходит только при использовании опции WITH CHECKSUM — которую вы должны использовать.
30-09 резервное копирование читает данные через буферный пул
Нет. Подсистема резервного копирования открывает свои собственные каналы к файлам базы данных, чтобы избежать потери производительности из-за необходимости читать всё в память SQL Server и обратно на устройство резервного копирования (а также фактически вытеснять буферный пул в процессе). Если вы запрашиваете проверку контрольных сумм страниц, она использует свою собственную небольшую область памяти.
30-10 резервные копии выполняют проверки согласованности (а-ля DBCC CHECKDB)
Нет. Больше нечего сказать.
30-11 если резервное копирование сработало, то и восстановление тоже сработает
Нет. Пожалуйста, не попадайте в эту ловушку. Вы должны регулярно проверять свои резервные копии, чтобы быть уверенными в их работоспособности в случае бедствия. Смотрите Importance of validating backups для получения более подробной информации.
30-12 зеркальное резервное копирование будет успешным, если зеркальное расположение станет недоступным
Нет. Если какой-либо из путей к зеркальной резервной (mirrored backup ) копии выходит из строя, вся операция зеркального резервного копирования завершается ошибкой. Мне бы очень хотелось, чтобы это работало наоборот — чтобы локальная резервная копия была успешной, а удалённые резервные копии — нет, но, к сожалению, это не так.
30-13 резервная копия «хвоста журнала» всегда возможна
Нет. Резервная копия «хвоста журнала» — это копия всего журнала, сгенерированного с момента последней резервной копии журнала, в исключительной ситуации. Если файлы данных повреждены, вы всё ещё можете сделать резервную копию хвоста журнала, ЗА ИСКЛЮЧЕНИЕМ случая, когда не скопированный журнал содержит минимально протоколируемую операцию. Это потребовало бы чтения экстентов данных — что невозможно, если файлы данных повреждены. По этой причине модель восстановления BULK_LOGGED не должна использоваться для баз данных с пользовательскими транзакциями 24×7.
30-14 вы можете использовать резервные копии вместо DBCC CHECKDB
Нет. Смотрите Миф об использовании BACKUP WITH CHECKSUM для замены DBCC CHECKDB.
30-15 вы можете создать резервную копию снимка базы данных (database snapshot)
Нет. Это не реализовано, но было бы здорово.
30-16 вы можете использовать снимки базы данных вместо резервных копий журнала
Нет. Снимок базы данных пригоден к использованию только тогда, когда база данных, на которой он основан, пригодна к использованию и доступна. Если исходная база данных повреждена, снимок базы данных, скорее всего, тоже повреждён. Если исходная база данных переходит в состояние SUSPECT, то же самое происходит со снимком базы данных. Кроме того, наличие нескольких снимков базы данных (что соответствует нескольким резервным копиям журнала) влечёт за собой постоянно растущее снижение производительности — каждая страница, изменяющаяся в исходной базе данных, может потребовать синхронной записи во все существующие снимки, прежде чем она может быть записана в файлы данных исходной базы данных, и все существующие снимки базы данных будут расти по мере того, как в них будет помещено больше страниц.
30-17 резервные копии журнала будут того же размера, что и журнал
Нет. Журнал должен обеспечивать пространство, необходимое для отката активных транзакций; объём пространства, возвращаемый DBCC SQLPERF (LOGSPACE) в загруженной системе, не отражает точно количество записей журнала в журнале. Эта статья в блоге это объясняет: Search Engine Q&A #25: Why isn’t my log backup the same size as my log? И кроме того, резервная копия журнала — это просто весь журнал, сгенерированный с момента последней резервной копии журнала, а не обычно весь файл журнала — и если это так, то вступает в силу первая часть объяснения.
30-18 вы не можете создать резервную копию повреждённой базы данных
Нет. В большинстве случаев вы можете использовать опцию WITH CONTINUE_AFTER_ERROR для создания резервной копии повреждённой базы данных. Если это не удаётся (возможно, из-за повреждённой загрузочной страницы или страницы заголовка файла), нет других вариантов, кроме резервного копирования файлов на уровне ОС.
30-19 вы можете продолжать использование BACKUP LOG ... WITH NO_LOG или TRUNCATE_ONLY
Нет. Это больше невозможно (ура!), а в 2005 году и ранее используйте флаг трассировки 3231, который превращает эту операцию в «пустышку» (no-op).
30-20 резервные копии журнала всегда очищают журнал
Нет. Если не выполняется одновременное резервное копирование данных, резервная копия журнала всегда будет пытаться очистить журнал, но преуспевает только в очистке неактивной части журнала — части, которая считается SQL Server «требуемой» только потому, что ещё не была скопирована. Если что-то ещё удерживает журнал как «требуемый», он не может быть очищен, даже если его резервная копия была создана. Последующие резервные копии журнала будут проверять снова и снова, пока не наступит момент, когда эта часть журнала может быть очищена. Статья TechNet Magazine «Ведение журнала и восстановление в SQL Server» подробно объясняет, как работает журнал. Кроме того, если выполняется одновременное резервное копирование данных, очистка журнала будет отложена до завершения резервного копирования данных. Смотрите статью в мифе 30-04 для получения более подробной информации.
30-21 дифференциальные резервные копии являются инкрементальными
Нет. Дифференциальные резервные копии — это все экстенты данных, которые изменились с момента последней полной резервной копии — то есть они являются кумулятивными. Резервные копии журнала являются инкрементальными — весь журнал, сгенерированный с момента последней резервной копии журнала. Многие называют дифференциальные резервные копии «инкрементальными», хотя на самом деле это не так.
30-22 после завершения резервного копирования вы можете безопасно удалить предыдущее
Нет. Нет. Нет. Если вы попытаетесь восстановиться и обнаружите, что ваша полная резервная копия повреждена, что вы будете делать? Если у вас нет более старой полной резервной копии, вы, скорее всего, начнёте обновлять своё резюме. Вам необходимо хранить скользящее окно резервных копий на случай, если произойдёт бедствие и вам потребуется восстановиться из более старого набора резервных копий.
30-23 вы можете создать резервную копию зеркальной базы данных
Нет. Зеркальная база данных недоступна, за исключением использования снимка базы данных, а вы не можете создать его резервную копию.
30-24 вы можете создать резервную копию одной таблицы
Нет. Вы можете эффективно создать резервную копию одной таблицы, если она целиком содержится в одной файловой группе, но нет способа выполнить BACKUP TABLE.
30-25 для создания резервной копии необходимо остановить SQL Server
Нет. Понятия не имею, как возник этот миф… [Примечание: судя по всему, этот миф возник с Oracle — и мы все знаем, насколько Oracle хорош по сравнению с SQL Server… :-)]
30-26 моя транзакция гарантированно попадёт в резервную копию, если она зафиксировалась до завершения операции резервного копирования
Нет. Запись журнала фиксации транзакции должна была быть записана до того, как завершилась часть чтения данных резервного копирования. Смотрите мою статью в блоге Search Engine Q&A #6: Using fn_dblog to tell if a transaction is contained in a backup для получения более подробной информации.
30-27 вы должны сжать базу данных перед резервным копированием, чтобы уменьшить размер резервной копии
Нет. Сжатие просто перемещает страницы, поэтому это не повлияет на размер. Смотрите мою старую статью в блоге Conference Questions Pot-Pourri #10: Shrinking the database before taking a backup. И, конечно, сжатие — это зло. Смотрите Миф: Сжатие файла данных не влияет на производительность. И что ещё хуже, как кто-то напомнил, если вы выполняете сжатие после полного резервного копирования, следующая дифференциальная резервная копия может быть огромной без каких-либо реальных изменений данных!
30-28 резервные копии всегда являются лучшим способом восстановления после бедствия
Нет. Резервные копии обычно являются лучшим способом восстановления с нулевой потерей данных (при условии, что у вас есть резервные копии журнала до момента бедствия), но не обязательно лучшим способом восстановления с минимальным временем простоя. Может быть гораздо быстрее выполнить отказоустойчивое переключение (failover) или запустить восстановление (repair) с некоторой потерей данных, если бизнес-требования это допускают.
30-29 вам не нужно создавать резервные копии master, msdb, model…
Нет. Вы всегда должны создавать резервные копии системных баз данных. Master содержит всю информацию о безопасности, о том, какие базы данных существуют; msdb содержит все пакеты SSIS, задания агента, историю резервного копирования; model содержит конфигурацию для новых баз данных. Не попадайтесь в ловушку, создавая резервные копии только пользовательских баз данных, иначе вы окажетесь в затруднительном положении, если вам придётся выполнять установку с нуля (bare-metal install).
30-30 вы всегда должны планировать хорошую стратегию резервного копирования
Нет. Теперь вы думаете: «Что?»… Вы должны планировать стратегию восстановления. Используйте бизнес-требования и технические ограничения, чтобы определить, что вам нужно восстанавливать и за какое время, а затем используйте это, чтобы определить, какие резервные копии вам нужно создавать, чтобы обеспечить возможность этого восстановления. Смотрите статьи в блоге:
В подавляющем большинстве случаев люди планируют стратегию резервного копирования без тестирования или размышлений о восстановлении — и когда случается бедствие, они не могут восстановиться в рамках своих соглашений об уровне обслуживания (SLA). Не позволяйте этому случиться с вами.
Комментариев нет:
Отправить комментарий