что делает dbcc checkdb

Что делает dbcc checkdb

В моменты бедствия проверка согласованности базы данных (DBCC), может оказаться вашим самый ценным другом. Здесь приводится краткий обзор того, что DBCC может сделать для Вас, в частности:

· Проверить целостность ваших таблиц и связанных с ними индексов.

· Проверить всю базу данных.

· Проверить целостность страниц базы данных.

· Восстановить индексы на заданной таблице.

Почему Вы должны дружить с DBCC

Если Вы задаетесь вопросом, почему использование DBCC является даже необходимым, то вот причины:

· Страницы базы данных (и таблиц и индексов) необходимо периодически разбиваются на несколько, что может привести к их плохому распределению.

· Индексы могут испортиться или просто стать неэффективными.

· Движок Сервера SQL может иногда неправильно понять ваши намерения.

· Отдельные страницы, хотя все еще «звучат», могут потерять свое оптимальное место хранения.

Как использовать DBCC

Вы можете запустить DBCC двумя способами: от командной строки и из окна Query Analyzer. Вы можете выполнять эти операции по расписанию, если считаете это необходимым. (Я никогда не чувствовал в этом потребности, поскольку из всех продуктов Microsoft я более всего уверен в стабильности SQL Server. Я полагаю, что это самый замечательный продукт, который когда-либо появлялся из Редмонда. Но не всегда все идет так, как надо.)

Команда DBCC имеет следующие расширения:

· CheckDB: проверяет согласованность всей базы данных, и является основным методом для проверки поврежденности базы данных.

· CheckTable: проверяет заданную таблицу на наличие проблем.

· CheckAlloc: проверяет отдельные страницы данных в базе, занятые как таблицами, так и индексами.

· Reindex: восстанавливает индексы на указанной таблице.

· CacheStats: сообщает об объектах, в настоящее время находящихся в кэше памяти.

· DropCleanBuffers: Удаляет все данные, находящиеся в настоящее время в буфере, для того, чтобы Вы могли продолжить тестирование, не используя предыдущие результаты.

· Errorlog: стирает (усекает) текущий журнал. Вы могли бы задать расписание для выполнения джоба, содержащего эту команду, чтобы выполнять ее, например, один раз в неделю.

· FlushProcInDB: Очищает процедурный кэш для заданной базы данных (используйте ее dbid, а не имя). Вот так можно определить используемое id:

SELECT dbid FROM master.dbo.sysdatabases
WHERE name = ‘ ‘

· IndexDefrag: уменьшает фрагментацию в индексах, не накладывая блокировок на файлы, так что пользователи могут продолжать работу с базой данных.

· CheckCatalog: проверяет указанную базу данных на согласованность в таблицах и между ними (последнее означает внешние ключи и т.д.).

Как использовать пять из этих расширений

DBCC сначала создает снимок вашей базы данных (за исключением определенных специфических обстоятельств, например, работы с Master, TempDB или базой данных только для чтения). Условие: Чтобы использовать DBCC, ваша база данных должна находиться в однопользовательском режиме.

Использование DBCC CheckDB

Эта команда гарантирует, что: · Страницы данных и индексов правильно связаны.
· Индексы отсортированы правильно и актуальны.
· Указатели согласованы.
· Данные на каждой странице актуальны.
· Смещения страниц актуальны.

Ниже три самых общих способа использоватния CheckDB:

DBCC CHECKDB (‘AdventureWorks’, REPAIR_FAST)

DBCC CHECKDB (‘AdventureWorks’, REPAIR_REBUILD)

DBCC CHECKDB (‘AdventureWorks’, REPAIR_ALLOW_DATA_LOSS)

Использование DBCC CheckTable

Любые проблемы, с которыми Вы сталкиваетесь, чаще всего будут связаны с одной или более таблицами базы данных, а не всей базы данных. В таких случаях, запускайте DBCC CheckTable. Сначала перейдите в требуемую базу данных, а затем выполните команду DBCC CheckTable. Вот два примера:

DBCC CheckTable (‘Sales,SalesOrderHeader’)

DBCC CheckTable (‘Sales,SalesOrderHeader’, REPAIR_REBUILD)

Использование DBCC CheckAlloc

Эта команда проверяет согласованность страниц данных и их индексов. Ниже два примера:

DBCC CHECKALLOC (‘Sales.SalesOrderDetails’)

DBCC CHECKALLOC (‘Sales.SalesOrderDetails’, REPAIR_REBUILD)

Использование DBCC CheckCatalog

Используйте эту команду для проверки согласованности системных таблиц базы данных. Вы задаете имя базы данных, которую требуется проверить и необязательный аргумент WITH NO_INFOMSGS. Например:

DBCC CHECKCATALOG (‘AdventureWorks’)

Использование DBCC ReIndex

Эта команда вызывает перестройку одного или более индексов на заданной таблице или представлении. Вы можете также задать имя конкретного индекса, а также коэффициент заполнения (fill factor). Ниже два примера.

DBCC REINDEX (‘AdventureWorks.Sales.SalesOrderHeader’, PK_SalesOrderHeader_SalesOrderID’

DBCC REINDEX (‘AdventureWorks.Sales.SalesOrderHeader’, PK_SalesOrderHeader_SalesOrderID’, 90)

Третий аргумент указывает, что я хочу получить коэффициент заполнения 90 % на перестроенном индексе.

Дополнительная информация Теперь, когда Вы знаете самые общие примеры использования DBCC, обратитесь к Books Online за информацией о дополнительных аргументах и опциях для каждого варианта команды.

Источник

DBCC (Transact-SQL)

Язык Transact-SQL предоставляет инструкции DBCC, которые выступают в качестве консольных команд базы данных для SQL Server.

Инструкции консольных команд базы данных группируются по следующим категориям.

Команды DBCC принимают входные параметры и возвращают значения. Все команды DBCC могут принимать в качестве параметров как литералы в Юникоде, так и литералы в двухбайтовой кодировке.

Использование внутреннего моментального снимка базы данных в командах DBCC

Следующие команды DBCC выполняют операции с внутренним моментальным снимком базы данных, предназначенным только для чтения, который создает компонент Компонент Database Engine. Тем самым предотвращаются проблемы блокировки и параллелизма при выполнении этих команд. Дополнительные сведения см. в разделе Моментальные снимки базы данных (SQL Server).

При выполнении одной из этих команд DBCC компонент Компонент Database Engine создает моментальный снимок базы данных и приводит ее в согласованное состояние на уровне транзакций. Затем команда DBCC выполняет проверку этого моментального снимка. После завершения команды DBCC этот моментальный снимок удаляется.

Иногда внутренний моментальный снимок базы данных не требуется или его невозможно создать. В этом случае команда DBCC выполняется в отношении реальной базы данных. Если база данных находится в режиме в сети, команда DBCC использует блокировку таблиц для обеспечения согласованности проверяемых объектов. Это поведение то же самое, как если бы был указан параметр WITH TABLOCK.

Внутренний моментальный снимок базы данных не создается, если команда DBCC выполняется:

Команды DBCC используют блокировки таблиц, а не внутренние моментальные снимки базы данных, если выполняются:

Для запуска команды DBCC CHECKALLOC или эквивалентной части DBCC CHECKDB с параметром WITH TABLOCK требуется X-блокировка базы данных. Такую блокировку нельзя устанавливать для базы данных tempdb или master: это может привести к ошибкам во всех остальных базах данных.

Команда DBCC CHECKDB вызывает ошибку при выполнении в базе данных master, если невозможно создать внутренний моментальный снимок базы данных.

Формирование отчета о состоянии команд DBCC

В представлении каталога sys.dm_exec_requests содержатся сведения о ходе выполнения и текущем этапе выполнения команд DBCC CHECKDB, CHECKFILEGROUP и CHECKTABLE. В столбце percent_complete указывается процент выполнения команды, а в столбце command отображается текущий этап ее выполнения.

Определение единицы хода выполнения зависит от текущего этапа выполнения команды DBCC. Иногда отчет о состоянии формируется на уровне гранулярности страницы базы данных, на других этапах — на уровне гранулярности одной базы данных или исправления распределения пространства. В следующей таблице представлены все этапы выполнения и уровень гранулярности, на котором команда формирует отчет о состоянии.

Информационные инструкции

Инструкции проверки

Инструкции обслуживания

Вспомогательные инструкции

Источник

DBCC CHECKDB оповещение о повреждении баз данных SQL

Всем доброго времени суток!

Сразу оговорюсь, что мои познания в T-SQL не сильно велики т. к. по большей части пишу код для конфигураций на платформе 1С:Предприятие, и предложенное решение может быть не совсем оптимальным.

Оптимизация и улучшения предложенного скрипта приветствуется.

Небольшое предисловие.

Часто случается, что базы данных повреждаются, по различным причинам, и мы не всегда это вовремя замечаем.

Что бы проверить базу данных надо зайти в интерфейс, запустить скрипт, получить результат. И уже в зависимости от результата принимать какие-то решения и действия. Возможно это нормально, когда есть свободно время и не лень запустить скрипт вручную. Но что делать когда, к примеру, на поддержке с 10-к и более баз и находятся они на разных серверах. Подключаться к каждому серверу и запускать скрипт руками занимает много времени, да делать это вручную лень.

Для разработчика, администратора и т. п. л ень это двигатель его прогресса, настроил систему как надо и читай логи, письма и прочее оповещения.

Вот после очередного повреждения базы, я опять вернулся к задаче проверки целостности баз по регламенту и рассылке результата на почту. Ранее я уже занимался этой задачей но не доделал, точнее не нашел нужного мне решения.

Это было небольшое предисловие, теперь перейдем к самой задаче.

Целью задачи было: проверять целостность баз данных 1с на сервере SQL по регламенту и при обнаружении поврежденной базы оповещать по почте. Оповещение только если найдена поврежденная база. Состав письма краткий, все данные результата проверки высылать не требуется.

Поиски готового решения в интернете ничего не дали. Нашел всего одно решение, но оно мне не подходит. Кому интересно, можете ознакомится с публикацией Отправляем результаты задания DBCC CHECKDB по электронной почте.

На просторах интернета прочитал, что данные можно вывести в таблицу.

DBCC CHCKDB WITH TABLERESULTS выведет данные в таблицу, но просто так взять и сделать выборку из из этой таблицы нельзя, но выход все же нашелся.

В поисках нужной информации для решения моей задачи наткнулся на публикацию Capture and Store SQL Server Database Integrity History using DBCC CHECKDB, которая была взята за основу решения задачи.

1. Создаем временную таблицу.

Исходное описание таблицы немного изменено.

Добавлена колонка «DatabaseName».

Изменил типы данных в некоторых колонках, т.к. при первом же тесте получил ошибки о невозможности преобразования типов данных

Колонка: RepairLevel с INT на VARCHAR(300)

В каких колонках нужно менять тип данных искал методом тыка и исключения.

IF OBJECT_iD(‘tempdb..#DBCC_DataReport’) is not null
DROP TABLE #DBCC_DataReport
GO

— table structure for SQL Server 2012, 2014, 2016 and 2017
CREATE TABLE #DBCC_DataReport(
[DatabaseName][VARCHAR](100) NULL
,[Error] [int] NULL
,[Level] [int] NULL
,[State] [int] NULL
,[MessageText] [VARCHAR](7000) NULL
,[RepairLevel] [VARCHAR](300) NULL
,[Status] [int] NULL
,[DbId] [int] NULL
,[DbFragId] [int] NULL
,[ObjectId] [int] NULL
,[IndexId] [int] NULL
,[PartitionID] [bigint] NULL
,[AllocUnitID] [bigint] NULL
,[RidDbId] [int] NULL
,[RidPruId] [int] NULL
,[File] [int] NULL
,[Page] [int] NULL
,[Slot] [int] NULL
,[RefDbId] [int] NULL
,[RefPruId] [int] NULL
,[RefFile] [int] NULL
,[RefPage] [int] NULL
,[RefSlot] [int] NULL
,[Allocation] [int] NULL
)

У меня есть база ‘Recovery’, использую для разных целей. Сегодя она играет роль поврежденной базы данных. Результ ее проверки и поместим во временную таблицу.

DECLARE @database_name NVARCHAR(50)
DECLARE database_cursor CURSOR FOR

OPEN database_cursor
FETCH NEXT FROM database_cursor INTO @database_name
WHILE @@FETCH_STATUS=0
BEGIN

INSERT INTO #DBCC_DataReport ([Error], [Level], [State], MessageText, RepairLevel, [Status],
[DbId], DbFragId, ObjectId, IndexId, PartitionId, AllocUnitId, RidDbId, RidPruId, [File], Page, Slot,
RefDbId, RefPruId, RefFile, RefPage, RefSlot,Allocation)
EXEC (‘DBCC CHECKDB(»’ + @database_name + »’) WITH TABLERESULTS, ALL_ERRORMSGS, DATA_PURITY’)

UPDATE #DBCC_DataReport SET [DatabaseName] = ‘DB ‘ + @database_name WhERE [DatabaseName] IS NULL

FETCH NEXT FROM database_cursor INTO @database_name
END

CLOSE database_cursor
DEALLOCATE database_cursor

3. Делаем выборку из временной таблицы и формируем строку сообщения. Выбираем только строки, которые содержат текст ошибки.

Теперь с данными можно работать, накладывать отборы, делать сортировку и все остальное.

DECLARE @MSG NVARCHAR(MAX)
SET @MSG = (
SELECT
TextData + CHAR(10) AS [text()]
FROM (
SELECT
Concat(DatabaseName, ‘: ‘, MessageText) as TextData
FROM #DBCC_DataReport
WHERE
SUBSTRING(MessageText, 1, 50) like ‘CHECKDB обнаружил 3%’
or SUBSTRING(MessageText, 1, 50) like ‘CHECKDB обнаружил 4%9%’
) AS ReportData
FOR XML PATH (»))

DB Recovery: CHECKDB обнаружил 0 ошибок размещения и 10 ошибок согласованности, не связанных ни с одним объектом.
DB Recovery: CHECKDB обнаружил 0 ошибок размещения и 30 ошибок согласованности в таблице «_InfoRg23950» (идентификатор объекта 469889041).
DB Recovery: CHECKDB обнаружил 0 ошибок размещения и 9 ошибок согласованности в таблице «_Reference12359» (идентификатор объекта 956790716).
DB Recovery: CHECKDB обнаружил 0 ошибок размещения и 5 ошибок согласованности в таблице «_InfoRg24673» (идентификатор объекта 1015882886).
DB Recovery: CHECKDB обнаружил 0 ошибок размещения и 3 ошибок согласованности в таблице «_InfoRg9101» (идентификатор объекта 1179359466).
DB Recovery: CHECKDB обнаружил 0 ошибок размещения и 57 ошибок согласованности в базе данных «Recovery».

Строку сообщения сформировали, временная таблица более не нужна, поэтому

DROP TABLE #DBCC_DataReport

Осталось проверить есть ли у нас в сформированной строке данные, при их наличии отправляем данные на почту.

EXEC msdb.dbo.sp_send_dbmail
@profile_name = @Profilename,
@recipients = @Recipients,
@body = @MSG,
@subject = @Msubject;
END
GO

Проверяем скрипт, все работает.

Создаем Job, настраиваем расписание и готово

IF OBJECT_iD(‘tempdb..#DBCC_DataReport’) is not null
DROP TABLE #DBCC_DataReport
GO

— table structure for SQL Server 2012, 2014, 2016 and 2017
CREATE TABLE #DBCC_DataReport(
[DatabaseName][VARCHAR](100) NULL
,[Error] [int] NULL
,[Level] [int] NULL
,[State] [int] NULL
,[MessageText] [VARCHAR](7000) NULL
,[RepairLevel] [VARCHAR](300) NULL
,[Status] [int] NULL
,[DbId] [int] NULL
,[DbFragId] [int] NULL
,[ObjectId] [int] NULL
,[IndexId] [int] NULL
,[PartitionID] [bigint] NULL
,[AllocUnitID] [bigint] NULL
,[RidDbId] [int] NULL
,[RidPruId] [int] NULL
,[File] [int] NULL
,[Page] [int] NULL
,[Slot] [int] NULL
,[RefDbId] [int] NULL
,[RefPruId] [int] NULL
,[RefFile] [int] NULL
,[RefPage] [int] NULL
,[RefSlot] [int] NULL
,[Allocation] [int] NULL
)

DECLARE @database_name NVARCHAR(50)
DECLARE database_cursor CURSOR FOR

OPEN database_cursor
FETCH NEXT FROM database_cursor INTO @database_name
WHILE @@FETCH_STATUS=0
BEGIN

INSERT INTO #DBCC_DataReport ([Error], [Level], [State], MessageText, RepairLevel, [Status],
[DbId], DbFragId, ObjectId, IndexId, PartitionId, AllocUnitId, RidDbId, RidPruId, [File], Page, Slot,
RefDbId, RefPruId, RefFile, RefPage, RefSlot,Allocation)
EXEC (‘DBCC CHECKDB(»’ + @database_name + »’) WITH TABLERESULTS, ALL_ERRORMSGS, DATA_PURITY’)

UPDATE #DBCC_DataReport SET [DatabaseName] = ‘DB ‘ + @database_name WhERE [DatabaseName] IS NULL

FETCH NEXT FROM database_cursor INTO @database_name
END

CLOSE database_cursor
DEALLOCATE database_cursor

DECLARE @MSG NVARCHAR(MAX)
SET @MSG = (
SELECT
TextData + CHAR(10) AS [text()]
FROM (
SELECT
Concat(DatabaseName, ‘: ‘, MessageText) as TextData
FROM #DBCC_DataReport
WHERE
SUBSTRING(MessageText, 1, 45) like ‘CHECKDB обнаружил 9%’
or SUBSTRING(MessageText, 1, 45) like ‘CHECKDB обнаружил 5%2%’
) AS ReportData
FOR XML PATH (»))

Источник

Исправление ошибок DBCC CHECKDB (1С, SQL) вручную

Все началось с того, что после проблем с жестким диском на сервере и «не совсем удачным» восстановлением рабочей базы данных 1С начала сообщать «could not continue scan with nolock» при проведении документов и закрываться с непоправимой ошибкой. Бэкап был, но не самый свежий, а данные терять не хотелось. Что же лучше делать?

Такое сообщение говорит, как правило, о том, что данные базы разрушены.

Первым делом нужно сделать резервную копию.

Далее запускаем в SQL Management Studio и выполняем DBCC CHECKDB. Выполняем ее так, чтобы данные не терялись, параметр REPAIR_ALLOW_DATA_LOSS оставим на случай совсем безнадежный.

Например, наша база называется Office

Выполняем следующие запросы:

ALTER DATABASE Office
SET SINGLE_USER
WITH ROLLBACK IMMEDIATE;
GO

DBCC CHECKDB (N’Office’, REPAIR_REBUILD) WITH NO_INFOMSGS
GO

Смотрим что сообщила проверка и видим множество сообщений примерно такого содержания:

CHECKDB found 0 allocation errors and 8 consistency errors in table ‘DT3311’ (object ID 1970106059).
CHECKDB found 0 allocation errors and 43 consistency errors in database ‘Office’.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (Office, repair_rebuild).

После проверки выполняем запрос для дальнейших операций с базой данных:

ALTER DATABASE Office
SET MULTI_USER;

Как видим, все ошибки относятся к index или index Это говорит о том, что повреждены данные. Но не будем отчаиваться и воспользуемся резервной копией.

Обращаем внимание на сообщенную таблицу DT3311. Пытаемся открыть ее или прочитать данные запросом, возникает сообщение об ошибке:

SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xacafd5b7; actual: 0x21c9cf6a). It occurred during a read of page (1:8473) in database ID 8 at offset 0x00000004232000 in file ‘E:\SQL_Data\Office.mdf’. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

Обращаем внимание, на какой строке таблицы останавливается запрос при полном показе содержимого таблицы в графическом интерфейсе. Например, он показал нам данные до строки 1915.

Смотрим резервную базу, поле IDDOC в таблице начиная со строки 1916, это документ с ID ‘ 1SP ‘

В рабочей базе мы ничего с документом не можем сделать: ни открыть его в 1С, ни прочитать его табличную часть, ни удалить его. Что делать?

Предлагаю перебросить по кусочкам данные из разных баз (рабочей и резервной), удалить таблицу в рабочей базе, создать ее повторно и положить данные на место.

Insert into Test.dbo.DT3311
Select * From DT3311 Where IDDOC <> ‘ 1SP ‘

Запрос выполнился без ошибок. Это говорит о том, что других данных с «мусором» в этой таблице нет.

Данные о поврежденном документе берем из резервной копии. Выполняем запрос в резервной базе:

Insert into Test.dbo.DT3311
Select * From DT3311 Where IDDOC = ‘ 1SP ‘

Теперь в тестовой базе есть полные данные. Удаляем таблицу в рабочей базе, создаем заново и выполняем запрос:

Insert into DT3311
Select * From Test.dbo.DT3311

Пробуем прочитать полностью другие таблицы, ведь мы помним, что не проводились документы. Выясняется, что не могут прочитаться некоторые таблицы итогов регистров (RGXXX). В данном случае можно просто удалить эти таблицы, данные в них восстановит сама 1С. Заходим монопольно в 1С: Предприятие, сдвигаем ТА на самый первый документ, затем на самый последний проведенный документ. В результате итоги по регистрам пересчитаются.

Производим повторную проверку ошибок и убеждаемся в их отсутствии.

Беремся за другую базу, Acc.

Выполняем следующие запросы:

ALTER DATABASE Acc
SET SINGLE_USER
WITH ROLLBACK IMMEDIATE;
GO

DBCC CHECKDB (N’Acc’, REPAIR_REBUILD) WITH NO_INFOMSGS
GO

Для нее мы получили такой перечень ошибок:

Тут картина совсем нестрашная. Данные не повреждены. Ошибки можно исправить удалением и созданием некластерных индексов.

Не забываем вернуть доступ к базе данных:

ALTER DATABASE Acc
SET MULTI_USER;

Для начала запишем скрипты на создание индексов (поочередно):

Затем удаляем индексы:

Затем выполним поочередно скрипты по созданию индексов в открытых окнах, попутно закрывая их (чтобы ничего не забыть).

Все исправили, производим повторную проверку и убеждаемся в отсутствии ошибок.

Источник