Ошибка СУБД HRESULT=80004005, тестирование SQL через DBCC CHECKDB, как исправить #760874

Здравствуйте! База УПП 1.3.70.1, релиз платформы 8.3.6.2421. База РИБ (Центральная), в Периферийной все работает нормально. База на SQL 2012, Сервер 1С 64-х разрядный. так вот вылетает ошибка при проведении Требовании-накладной или Возврат переданных товаров и вылетает программа: Ошибка СУБД: Microsoft OLE DB Provider for SQL Server. Внимание! Произошла неустранимая ошибка 824. Запомните ошибку и время, когда она произошла, и обратитесь к системному администратору. Такую ошибку нигде не нашла, что означает, перечитала много форумов прежде, чем здесь написать. Опишу подробно: 1) Рестарт сервера 1С и SQL ничего не дает, или дает временно. 2) далее по поводу cf-к и т.д. в том, что памяти не хватает  - это тоже не по теме, т.к. сервер 64-х разрядный. 3) далее сделала следующие манипуляции, которые мне посоветовали: - сделала бэкап с клиент-серверной рабочей базы; - загрузила бэкап в другую клиент-серверную базу-копию; - из этой копии выгрузила dt-ник; - далее загрузила этот dt-ник в файловую базу; - протестировала 1CD (нет ошибок), сделала тестирование из конфигуратора - Тестирование и исправление (проверка логической и ссылочной целостности) - затем из файловой базы выгрузила dt-ник и загрузила его в рабочую клиент-серверную базу. Делала до этого тоже самое помогло, но не надолго, только отличие было в том, что dt-ку выгружала и загружала снова в копию клиент-серверного варианта. Сейчас сделала через файловую, как описала выше, жду результата, что будет. А тем временем попробовала на копии клиент-серверного варианта запустить проверку в SQL с помощью следующего запроса: ALTER DATABASE UPP SET SINGLE_USER WITH ROLLBACK IMMEDIATE; GO DBCC CHECKDB ('UPP', REPAIR_REBUILD) WITH NO_INFOMSGS GO Проверка выдала следующее: ообщение 8928, уровень 16, состояние 1, строка 1 Идентификатор объекта 279945065, идентификатор индекса 3, идентификатор секции 72058135223271424, идентификатор единицы распределения 72058134132817920 (тип In-row data). Не удалось обработать страницу (1:2541984).  Подробные сведения см. в других сообщениях об ошибках.         Уровень исправлений для данной инструкции DBCC вызвал обход данного исправления. Сообщение 8939, уровень 16, состояние 98, строка 1 Ошибка в таблице. Идентификатор объекта 279945065, идентификатор индекса 3, идентификатор секции 72058135223271424, идентификатор единицы распределения 72058134132817920 (тип In-row data) страница (1:2541984). Проверка (IS_OFF (BUF_IOERR, pBUF->bstat)) не пройдена. Значения равны 2057 и -4.         Для исправления данной ошибки необходимо сначала исправить другие ошибки. Сообщение 8976, уровень 16, состояние 1, строка 1 Ошибка в таблице. Идентификатор объекта 279945065, идентификатор индекса 3, идентификатор секции 72058135223271424, идентификатор единицы распределения 72058134132817920 (тип In-row data). Страница (1:2541984) не обнаружена при просмотре, хотя на нее ссылаются родительская страница (1:2539467) и предыдущая страница (1:2541983). Проверьте наличие предыдущих ошибок.         Для исправления данной ошибки необходимо сначала исправить другие ошибки. Сообщение 8978, уровень 16, состояние 1, строка 1 Ошибка в таблице. Идентификатор объекта 279945065, идентификатор индекса 3, идентификатор секции 72058135223271424, идентификатор единицы распределения 72058134132817920 (тип In-row data). На страницу (1:2702132) отсутствует ссылка с предыдущей страницы (1:2541984). Возможна ошибка связывания цепочек.         Для исправления данной ошибки необходимо сначала исправить другие ошибки. CHECKDB обнаружил 0 ошибок размещения и 4 ошибок согласованности в таблице "_AccumRg23823" (идентификатор объекта 279945065). CHECKDB обнаружил 0 ошибок размещения и 4 ошибок согласованности в базе данных "UPP". repair_allow_data_loss - это минимальный уровень исправления для ошибок, найденных DBCC CHECKDB (UPP, repair_rebuild). таблица "_AccumRg23823"  - это регистр накопления "НДС по партиям запасов" И как и что исправить не знаю? Подскажите, пожалуйста!

Причина найдена, а вот как исправить это средствами SQL - не знаю. Впервые сталкиваюсь с прямыми запросами SQL. Подскажите, пожалуйста, что нужно сделать с индексами таблицы регистра накопления "НДС по партиям запасов" -  "_AccumRg23823"

Сделайте бекап. Удалите все индексы данного регистра. Пересохраните конфигурацию. Сделайте реиндексацию.

"repair_allow_data_loss - это минимальный уровень исправления для ошибок, найденных DBCC CHECKDB (UPP, repair_rebuild)" Запуститу на копии DBCC CHECKDB ('UPP', REPAIR_ALLOW_DATA_LOSS) для начала...

данные не потеряются, если удалить индексы? Открыла ветку с индексами - там их 6 уникальных некластеризованных и 1 кластеризованный. Их просто удалить???

да, хотела попробовать так сделать на копии. а данные не потеряются, если запустить такую проверку?

Потеряются только если кластерезованный индекс удалите напрямую :))

так а как удалить правильно в SQL? Если можно, то пошагово, пожалуйста

Только кластеризованный не трогайте

я читала такую ссылку. в конце ссылки приводится две картинки. Нахожу таблицу "_AccumRg23823", раскрываю ее, нахожу "Индексы" - далее нажимаю "Создать скрипт для индекса" - Используя CREATE - Новое окно редактора запроса При этом открывается окно запроса с текстом запроса: GO /****** Object:  Index [_Accum23823_ByDims23843_RTRN]    Script Date: 16.12.2015 10:05:44 ******/ CREATE UNIQUE NONCLUSTERED INDEX [_Accum23823_ByDims23843_RTRN] ON [dbo].[_AccumRg23823] ( GO Дальше что я должна сделать?

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

нужно запускать запрос в "Выполнить" или нет? что значит пересохранить конфу? можно подробнее?

Че паритесь ? Просто truncate table _AccumRg23823 и дальше пересчет итогов этого регистра

А блин, це же табличка с движениями.. Ну, тогда не выйдет с очисткой е1ё.

Сделала, как по ссылке Создала скрипты для индексов, просто вышло много окон с текстами запросов для 6 некластеризованных индексов и все. затем удалила эти 6 индексов. А как теперь их создать? Затем пишут: "Затем выполним поочередно скрипты по созданию индексов в открытых окнах, попутно закрывая их (чтобы ничего не забыть)." Что это значит? Как сделать?

Выполнить запрос написанный в скрипте

Т.е. по описанию в ссылке я должна сначала создать скрипты по 6 индексам, сохранить себе их данные, затем индексы удалить и создать их снова, скопировав запросы созданных скриптов, и нажать по каждому индексу выполнить. А при создании нового индекса выбирать те поля, которые указаны в скрипте? Так?

Сделала, запускаю повторно запрос проверки, выдает следующее: Неуточненные транзакции проходят откат. Предварительно выполнение отката: 0%. Неуточненные транзакции проходят откат. Предварительно выполнение отката: 100%. Это хорошо или нет?

Проверьте что коннект стоит к нужной базе.

как это сделать? все делала на копии. при загрузке базы провела документ, на котором вылетала база - провелся!

Там в отдельном поле видно название БД с которой вы работаете

Спасибо большое за помощь! А еще вопрос: какая может быть причина, что полетели индексы регистра накопления? Что могло послужить причиной?

А можно было по сути запустить реиндексацию таблиц информационной базы (по сути это и есть манипуляции с dt-ником)? И можно еще спросить здесь же: эта проблема возникла в Центральной базе, а в Периферийной базе вообще можно запускать реиндексацию таблиц информационной базы? И вообще какое еще тестирование можно проводить в Периферийной базе?

Канешна можно. Индексы строго говоря не зависят от базы. Кроме кластерного индекса, тн Прайм Кей. Кластерный индекс это сортировка самой таблицы, столбец который сортируется и есть кластерный индекс. Но в каждой БД, даже если 2 БД одинаковые с точки зрения 1С, сортировка внутри таблиц может быть разной.

а в Периферийной какое тестирование можно запускать в  режиме Конфигуратора?

Зачем периферийную трогать?

Я имею ввиду на будущее потом, вообще ее нужно тестировать? И если да, то какие проверки можно задавать?