Миф: DBCC CHECKDB вызывает блокировки

Автор: Paul Randal, A SQL Server DBA myth a day: (2/30) DBCC CHECKDB causes blocking

DBCC CHECKDB вызывает блокировки, потому что устанавливает их по умолчанию 

ЛОЖЬ

Когда-то давно, в версии 7.0 и ранее DBCC CHECKDB (и остальные команды проверки согласованности) представляли собой неприятную мешанину вложенного циклического кода на C, который устанавливал блокировки таблиц (а вложенные циклы делали алгоритм по сути порядка n-квадрат - это если среди вас есть программисты). Это было нехорошо, и поэтому…

В 2000 году парень по имени Стив Линделл (который всё ещё в команде SQL) переписал DBCC CHECKDB, чтобы получить согласованное представление базы данных с использованием анализа журнала транзакций. По сути, DBCC CHECKDB предотвращал усечение журнала, а затем в конце чтения несогласованной (из-за параллельных пользовательских транзакций) базы данных запускал восстановление после сбоя по журналу транзакций внутри себя. В основном, это была совершенно новая репродукция кода восстановления, но внутри DBCC CHECKDB. Я помог написать кучу кода анализа журнала — мучительно, но интересно. Нет, более мучительно. И с ним были небольшие проблемы — например, возможность ложных сбоев… «если появляются ошибки, запустите снова и посмотрите, появятся ли те же ошибки». Иногда он устанавливал блокировки стабильности схемы таблицы (SCH_S), которые блокировали только просмотр таблицы и изменения схемы таблицы. Код журналирования в целом был нехорош, и поэтому…

В 2005 году парень по имени Пол Рандал снова переписал DBCC CHECKDB, чтобы использовать моментальные снимки базы данных для получения согласованного представления базы данных (поскольку моментальный снимок базы данных автоматически предоставляет транзакционно согласованное представление базы данных на момент времени). Больше никакого неприятного кода анализа журнала транзакций, никаких блокировок вообще — поскольку доступ к исходной базе данных моментального снимка никогда не устанавливает блокировки — буферный пул управляет всеми возможными состояниями в процессе.

Вы можете больше узнать о внутреннем устройстве этого (как для 2000, так и для 2005+) в следующих записях:

• CHECKDB From Every Angle: Complete description of all CHECKDB stages
• CHECKDB From Every Angle: Why would CHECKDB run out of space?
• Database snapshots – when things go wrong
• Issues around DBCC CHECKDB and the use of hidden database snapshots
• Do transactions rollback when DBCC CHECKDB runs?
• Diskeeper 10 Intelliwrite corruption bug

Теперь, во всех версиях, если вы используете опцию WITH TABLOCK, DBCC CHECKDB будет устанавливать блокировки для гарантии транзакционно согласованного представления, но я не рекомендую этого делать. Первое, что он попытается сделать, — это захватить монопольную блокировку базы данных, что в подавляющем большинстве случаев не удастся (она ждёт только 20 секунд) из-за параллельных подключений к базе данных.

В 2000 году тот факт, что он предотвращал усечение журнала, мог вызывать некоторые проблемы — например, рост журнала — а в 2005 году могут быть проблемы, связанные с использованием моментальных снимков базы данных (см. ссылки выше).

Но по умолчанию DBCC CHECKDB не вызывает блокировок с SQL Server 2000.