Существует множество вещей, которые я постоянно слышу о том, что может и что не может восстановление (repair), что может вызывать повреждения и могут ли повреждения исчезать. Некоторые из них я уже описывал в постах за последние несколько лет, поэтому вместо того, чтобы повторять то же самое, этот пост-разоблачитель представляет собой несколько интересных ссылок, чтобы порадовать вас.
Во-первых, о том, что может и что не может восстановление. Я написал статью в блоге Заблуждения относительно восстановления базы данных, который охватывает 13 отдельных мифов и заблуждений — от того, можно ли запускать восстановление отдельно от DBCC CHECKDB (нет!), до того, приведёт ли REPAIR_ALLOW_DATA_LOSS к потере данных (мне непонятно, почему название сбивает с толку :-).
Во-вторых, я слышал, как многие жалуются, что DBCC CHECKDB показывает повреждения, которые затем «исчезают», когда они запускают DBCC CHECKDB снова. Для этого есть очень веская причина — страницы базы данных, на которых проявлялись повреждения, к моменту повторного запуска DBCC CHECKDB больше не входят в набор выделенных страниц в базе данных — поэтому они не отображаются как повреждения. Я подробно объясняю это в статье блога Заблуждения относительно повреждений: могут ли они исчезать?.
И наконец, существует широко распространённый миф о том, что прерывание длительной операции (такой как сжатие (shrink), перестроение индекса, массовая загрузка) может вызвать повреждение. Нет. Если только нет ошибки повреждения в самом SQL Server (что иногда случается, но редко), ничто из того, что вы можете сделать с помощью T-SQL, не может вызвать повреждение. Я написал подробный пост в блоге на эту пару лет назад — см. Sear ch Engine Q&A #26: Myths around causing corruption.
Комментариев нет:
Отправить комментарий