Здравствуйте!

База УПП 1.3.70.1, релиз платформы 8.3.6.2421. База РИБ (Центральная), в Периферийной все работает нормально.
База на SQL 2012, Сервер 1С 64-х разрядный.

так вот вылетает ошибка при проведении Требовании-накладной или Возврат переданных товаров и вылетает программа:

Ошибка СУБД:
Microsoft OLE DB Provider for SQL Server. Внимание! Произошла неустранимая ошибка 824. Запомните ошибку и время, когда она произошла, и обратитесь к системному администратору.
HRESULT=80004005, SQLSrvr=HY000, state = 1, severity=18, native=21, line=1


Такую ошибку нигде не нашла, что означает, перечитала много форумов прежде, чем здесь написать.

Опишу подробно:
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"

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

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

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

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

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

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

(7) http://catalog.mista.ru/public/192648/
Только кластеризованный не трогайте

(8) я читала такую ссылку. в конце ссылки приводится две картинки.

Нахожу таблицу "_AccumRg23823", раскрываю ее, нахожу "Индексы" - далее нажимаю "Создать скрипт для индекса" - Используя CREATE - Новое окно редактора запроса

При этом открывается окно запроса с текстом запроса:

USE [UPP]
GO

/****** Object:  Index [_Accum23823_ByDims23843_RTRN]    Script Date: 16.12.2015 10:05:44 ******/
CREATE UNIQUE NONCLUSTERED INDEX [_Accum23823_ByDims23843_RTRN] ON [dbo].[_AccumRg23823]
(
    [_Fld23825RRef] ASC,
    [_Period] ASC,
    [_RecorderTRef] ASC,
    [_RecorderRRef] ASC,
    [_LineNo] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO

Дальше что я должна сделать?

(9) Дальше удаляйте, а потом пересоздавайте по скрипту.

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

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

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

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

Сделала, как по ссылке Создала скрипты для индексов, просто вышло много окон с текстами запросов для 6 некластеризованных индексов и все. затем удалила эти 6 индексов. А как теперь их создать?

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

Что это значит? Как сделать?

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

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

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


Это хорошо или нет?

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

(18) как это сделать?

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

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

(20) Спасибо большое за помощь!

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

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

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

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

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

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

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