Недавно возник вопрос: если я обновил базу данных с SQL 2000 или более ранней версии, как понять, будут ли выполняться проверки чистоты данных (data purity), или нет?
Как известно, начиная с SQL Server 2005, DBCC CHECKDB включает проверки «чистоты данных». Они ищут значения столбцов, выходящие за допустимый диапазон для их типов данных. Для баз, созданных в SQL Server 2005 и новее, эти проверки всегда выполняются DBCC CHECKDB и не могут быть отключены. Для баз, созданных в более ранних версиях, всё чуть сложнее.
В версиях SQL Server до 2005 можно было импортировать в базу некорректные значения. Такие значения могли приводить к проблемам при выполнении запросов или даже к неправильным результатам. В 2005 году, когда «дыры» в импорте закрыли, в DBCC CHECKDB добавили проверки чистоты данных, но не по умолчанию для обновлённых баз. Поскольку в обновлённых базах могла присутствовать некорректная информация, было принято решение не включать эти проверки по умолчанию, чтобы у пользователей не возникало подозрение, будто обновление якобы привело к повреждениям, которых «на 2000» не было.
Итак, если у вас обновлённая база и вы хотите запустить проверки чистоты данных, нужно использовать параметр WITH DATA_PURITY у DBCC CHECKDB. Это описано в Books Online, и я включал эту информацию в Release Notes к SQL Server 2005. Но вернёмся к вопросу: в какой момент не нужно указывать этот параметр? Для обновлённой базы: если вы один раз запускаете DBCC CHECKDB с WITH DATA_PURITY и проблем не обнаруживается, в загрузочной странице («boot page»; см. статью «Boot Page и их повреждения») безвозвратно переключается специальный бит. С этого момента проверки чистоты данных будут выполняться для этой базы при каждом запуске DBCC CHECKDB.
Проблема в том, как понять, установлен ли уже этот бит? Нужно посмотреть загрузочную страницу. Проще всего сделать это командой DBCC DBINFO (не документирована, но полностью безопасна). По сути, она равнозначна DBCC PAGE('dbname', 1, 9, 3), которая показывает содержимое загрузочной страницы, как я объяснял в предыдущей записи.
На что смотреть: на версию SQL Server, в которой была создана база (create version), и — если это 2000 или ниже — установлен ли специальный флаг «data purity».
Для базы, созданной в SQL Server 2005:
DBCC TRACEON (3604);
GO
DBCC DBINFO ('master');
GO
DBINFO STRUCTURE:
DBINFO @0x66C8EF64
dbi_dbid = 1 dbi_status = 65544 dbi_nextid = 1984726123
dbi_dbname = master dbi_maxDbTimestamp = 16000 dbi_version = 611
dbi_createVersion = 611 dbi_ESVersion = 0
dbi_nextseqnum = 1900-01-01 00:00:00.000 dbi_crdate = 1900-01-01 00:00:00.000
dbi_filegeneration = 0
dbi_checkptLSN
m_fSeqNo = 7612 m_blockOffset = 224 m_slotId = 1
dbi_RebuildLogs = 0 dbi_dbccFlags = 0
dbi_dbccLastKnownGood = 2009-05-12 16:07:15.647
dbi_dbbackupLSN
<snip>
Если dbi_createVersion равно 611 или выше, база создана в SQL Server 2005+ и проверки чистоты данных будут выполняться всегда.
Примечание: в 2013 году я обнаружил ошибку, из‑за которой автоматические проверки чистоты данных не выполняются в базах master и model — см. мою статью в блоге.
Для обновлённой базы (это одна из моих заранее «испорченных» баз; получить можно здесь: «Conference corruption demo scripts and example corrupt databases»):
DBCC TRACEON (3604);
GO
DBCC DBINFO ('DemoCorruptMetadata');
GO
DBINFO STRUCTURE:
DBINFO @0x6855EF64
dbi_dbid = 7 dbi_status = 16 dbi_nextid = 2089058478
dbi_dbname = DemoCorruptMetadata dbi_maxDbTimestamp = 100 dbi_version = 611
dbi_createVersion = 539 dbi_ESVersion = 0
dbi_nextseqnum = 1900-01-01 00:00:00.000 dbi_crdate = 2009-06-17 15:14:49.490
dbi_filegeneration = 0
dbi_checkptLSN
m_fSeqNo = 10 m_blockOffset = 303 m_slotId = 1
dbi_RebuildLogs = 0 dbi_dbccFlags = 0
dbi_dbccLastKnownGood = 1900-01-01 00:00:00.000
dbi_dbbackupLSN
<snip>
У этой базы dbi_createVersion меньше 611, значит, нужно смотреть на поле dbi_dbccFlags. Значение 0 означает, что проверки чистоты данных по умолчанию не включены. Значение 2 — что они включены по умолчанию. Это легко проверить для ваших баз.
Комментариев нет:
Отправить комментарий