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

01.07.13

Задачи пользователя - Корректировка данных

Если Вы наблюдаете сообщение "could not continue scan with nolock" и подобные ему - значит эта статья для Вас. В статье рассказывается, как поправить ошибки выданные DBCC CHECKDB вручную.

Все началось с того, что после проблем с жестким диском на сервере и "не совсем удачным" восстановлением рабочей базы данных 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

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

Msg 8928, Level 16, State 1, Line 2
Object ID 814625945, index ID 1, partition ID 72057594157203456, alloc unit ID 72057594154844160 (type In-row data): Page (1:3605) could not be processed.  See other errors for details.

        The repair level on the DBCC statement caused this repair to be bypassed.
Msg 8939, Level 16, State 98, Line 2
Table error: Object ID 814625945, index ID 1, partition ID 72057594157203456, alloc unit ID 72057594154844160 (type In-row data), page (1:3605). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12584969 and -4.

        Repairing this error requires other errors to be corrected first.
Msg 8976, Level 16, State 1, Line 2
Table error: Object ID 814625945, index ID 1, partition ID 72057594157203456, alloc unit ID 72057594154844160 (type In-row data). Page (1:3605) was not seen in the scan although its parent (1:6481) and previous (1:8859) refer to it. Check any previous errors.

        Repairing this error requires other errors to be corrected first.

...

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;

Как восстанавливать поврежденные страницы писать не буду. Статья рассчитана на простое администрирование и поможет даже при модели Simple. Те, кто делают бэкапы логов журнала транзакций очень-очень часто, сюда заходить не будут.  Единственное условие - нам потребуется резервная копия (будем надеяться, что по теории вероятности самые свежие данные мы спасли без повреждений и бэкапы хоть иногда делали).

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

Обращаем внимание на сообщенную таблицу 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.

Проверяем: запрос Select top 1915 * From DT3311 выполняется, а Select top 1916 * From DT3311 - уже нет.

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

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

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

Создаем временную базу test, в ней создаем такую же таблицу DT3311 (для тех, кто не знает как это сделать быстро - картинки ниже на примере создания индексов) и выполняем запрос:

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

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

Msg 8978, Level 16, State 1, Line 2
Table error: Object ID 1685581043, index ID 6, partition ID 72057594149928960, alloc unit ID 72057594147569664 (type In-row data). Page (1:17191) is missing a reference from previous page (1:19106). Possible chain linkage problem.

        Repairing this error requires other errors to be corrected first.
Msg 8928, Level 16, State 1, Line 2
Object ID 1685581043, index ID 6, partition ID 72057594149928960, alloc unit ID 72057594147569664 (type In-row data): Page (1:19106) could not be processed.  See other errors for details.

        The repair level on the DBCC statement caused this repair to be bypassed.
Msg 8939, Level 16, State 98, Line 2
Table error: Object ID 1685581043, index ID 6, partition ID 72057594149928960, alloc unit ID 72057594147569664 (type In-row data), page (1:19106). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 62916617 and -4.

        Repairing this error requires other errors to be corrected first.
Msg 8976, Level 16, State 1, Line 2
Table error: Object ID 1685581043, index ID 6, partition ID 72057594149928960, alloc unit ID 72057594147569664 (type In-row data). Page (1:19106) was not seen in the scan although its parent (1:20741) and previous (1:15201) refer to it. Check any previous errors.

        Repairing this error requires other errors to be corrected first.
CHECKDB found 0 allocation errors and 4 consistency errors in table 'SC59729' (object ID 1685581043).
CHECKDB found 0 allocation errors and 4 consistency errors in database 'Acc'.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (Acc, repair_rebuild).

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

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

ALTER DATABASE Acc
SET MULTI_USER;

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

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

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

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

 

Оригинал статьи

См. также

Чистка данных Корректировка данных Программист Пользователь Платформа 1С v7.7 Конфигурации 1cv7 Абонемент ($m)

Архив различных обработок 1С 7.7 с открытым исходным кодом для работы с данными при свертке, выгрузке, исправлении, модификации информационной базы. Можно использовать любую обработку в качестве заготовки для добавления собственных функций.

1 стартмани

13.05.2021    8192    12    etmarket    0    

3

Корректировка данных Акт сверки Программист Платформа 1С v7.7 Платформа 1С v8.3 1С:Управление торговлей 10 1С:Комплексная 7.7 1С:Торговля и склад 7.7 Россия Бухгалтерский учет Управленческий учет НДС Абонемент ($m)

Пример реализации сверок между базами и исправления расхождений в обе стороны, из 7.7 -> в 8.3 и из 8.3 -> в 7.7 на обычных формах. Фундаментальные обработки, которые работают на постоянной основе и поддерживают идентичность данных между базами основных поставщиков и основных покупателей (их соответствие прописано в модуле). Используется Новый COMОбъект("V77.Application"), пример использования внешнего источника данных. Реализация в поступление. Поступление в поступление. Корректировка поступления в корректировку отгрузки. СчФ выданный в СчФ полученный. Исправление СчФ полученного в исправление СчФ выданного. Перенос документа Реализация 7.7 в Поступление 8, Перемещение 7.7 в Поступление 8. Акт сверки взаиморасчетов (несколько организаций). Все обработки запускаются в базе 1С Предприятие 8 (обычные формы).

1 стартмани

03.10.2019    15006    31    ksnik    6    

4

Корректировка данных Программист Пользователь Платформа 1С v7.7 Конфигурации 1cv7 Абонемент ($m)

Универсальная обработка 7.7, представленная здесь, до сих пор почему-то по функционалу гораздо беднее, чем общеизвестная типовая "Универсальный подбор и обработка объектов" (UNIREPS82\UniversalSelection) 8.2-8.3", мне не хватило возможности выполнить произвольный код обработчика объектов. Данная обработка "UChoice.ert" является полным аналогом "UniversalSelection", представляет собой консоль выполнения произвольного кода, позволяет делать с объектами информационной базы 1С 7.7 абсолютно все, что угодно, а не узкий, сложно настраиваемый набор команд, на мой взгляд, она существенно превосходит имеющиеся аналоги, поэтому ничем другим кроме нее я не пользуюсь.

1 стартмани

04.04.2019    16809    31    ksnik    9    

4

Корректировка данных Бухгалтер Бухгалтерский учет 7.7 1С:Упрощенное налогообложение 7.7 Россия Бухгалтерский учет НДС Абонемент ($m)

Для 1С:Предприятия 8 переход на НДС 20% сделан, а для 7.7 я не нашел. Выкладываю.

1 стартмани

24.12.2018    18811    34    pentanom    25    

5

Корректировка данных Программист Бухгалтер Платформа 1С v7.7 Конфигурации 1cv7 Абонемент ($m)

Обработка, исправляющая ситуацию с отрицательными номерами строк в табличной части

1 стартмани

31.08.2017    13514    1    C0mmander_Alex    1    

3

Корректировка данных Платформа 1С v7.7 Конфигурации 1cv7 Россия Абонемент ($m)

1. Обработка позволяет совершать следующие действия над объектами: а. СПРАВОЧНИКИ: удаление; пометка на удаление; снятие пометки на удаление. б. ДОКУМЕНТЫ: удаление; пометка на удаление; снятие пометки на удаление; проведение; отмена проведения; выключить проводки; включить проводки. 2. Действия могут быть ограничены некоторыми условиями. 3. Существует отбор по видам объектов. 4. Есть возможность обработать подчиненные справочники.

1 стартмани

30.04.2017    22643    82    DUH    0    

5

Корректировка данных Программист Пользователь Платформа 1С v7.7 Конфигурации 1cv7 Россия Абонемент ($m)

Обработки можно использовать в любой конфигурации 1С-Предприятия 7.7. Обработки позволяют просмотреть/изменить значения любого реквизита документов/справочников, существующих в базе. В обработках реализован множественный отбор по значениям реквизитов (для табличной части документов тоже). В обработке документов реализованы следующие действия: Перенумерация; проведение; отмена проведения; пометка на удаление; непосредственное удаление; снятие пометки удаления; изменение реквизитов; очистка реквизитов; удаление строк табличной части; вывод на печать и в файлы *.xls,*.csv,*.dbf,*.xml реквизитов шапки и табличной части. В обработке справочников реализованы следующие действия: Перенумерация; пометка на удаление; непосредственное удаление; снятие пометки удаления; изменение реквизитов; очистка реквизитов; очистка истории значений периодического реквизита; перенос справочника в другую базу подобной конфигурации по OLE; вывод на печать реквизитов и истории значений периодических реквизитов; вывод реквизитов в файлы *.xls,*.csv,*.dbf,*.xml; отчет по структуре справочников, вывод и обработка ссылок на выбранные элементы.

1 стартмани

23.11.2016    38941    227    SanchoD    15    

13

Корректировка данных Системный администратор Программист Платформа 1С v7.7 Конфигурации 1cv7 Абонемент ($m)

База данных помечается Suspect, когда SQL Server не может читать файлы данных, связанные с базой данных с жесткого диска. В этом случае сделать бекап базы нельзя, но можно попробовать образ диска. После того как возможность читать файлы данных восстановлена, вы можете перезапустить службу SQL Server, и если возможно, произойдет автоматическое восстановление. Что делать, если информационная база 1С7.7 на SQL Server 2000 перешла в состояние suspect? Если это произошло утром и бекап сделан, Вы, конечно, можете грохнуть и раскатать базу заново (вечером это проблематичнее), но не торопитесь - возможно, поможет detach+attach или другие методы, изложенные в данной публикации.

1 стартмани

08.11.2016    23322    ksnik    5    

5
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. astraborz 6 06.11.14 04:34 Сейчас в теме
Спасибо очень помогло
2. maksa2005 551 01.01.16 12:08 Сейчас в теме
Решила мои проблема!!!!!!!!!СПАСИБО!
3. rudnitskij 30.06.21 21:52 Сейчас в теме
"сдвигаем ТА на самый первый документ" - что такое ТА ?
4. doronin70 06.11.21 23:16 Сейчас в теме
(3) ТА - точка актуальности. Это документ, на котором остановилось восстановление последовательности документов.
6. rudnitskij 08.11.21 17:57 Сейчас в теме
(4) Странно, что при работе с последовательностью не используется термин "граница последовательности", рудименты из семерки сбивают с толку граждан
5. doronin70 06.11.21 23:18 Сейчас в теме
Спасибо автору!
Скрипт с параметром "REPAIR_REBUILD" показал что есть несколько десятков ошибок в одной таблице.
А с параметром "REPAIR_ALLOW_DATA_LOSS" - исправил эти ошибки
7. Вадимко 156 09.11.21 02:16 Сейчас в теме
(6) какие же это рудименты когда это жизнь моя… каким боком та к гп??
Оставьте свое сообщение