Checkdb обнаружил ошибок размещения и ошибок согласованности - ErrorsMaster.ru

Делимся опытом, как исправить ошибки в логической целостности в базе 1С, размещенной на Microsoft SQL Server.

Поступила жалоба от бухгалтера о проблемах с проведением документов в 1С.

Из скриншота выяснилось, что 1С «ругается» на проблемы с согласованностью «внутри» базы данных и предлагает провести проверку на согласованность.

Переходим в SQL Server Management Studio и, сделав, на всякий случай, бэкап текущего состояния, выполняем проверку:

Для начала переводим нужную нам БД в однопользовательский режим

Запускаем Окно запросов (CTRL+N). Выбираем Новый запрос и вводим запрос Transact-SQL (T-SQL) в этом окне:

	 ALTER DATABASE KA
	 SET SINGLE_USER
	 WITH ROLLBACK IMMEDIATE

Далее, вводим запрос на сканирование базы данных:

	 USE [ka]
	 GO
	 DBCC CHECKDB(N'ka') WITH NO_INFOMSGS
	 GO

Проверка продлилась около 15 минут, после чего выдала следующее:

CHECKDB обнаружил 0 ошибок размещения и 766 ошибок согласованности, не связанных ни с одним объектом.

CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности в таблице «sys.sysdbfiles» (идентификатор объекта 20).

CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности в таблице «sys.sysxmlcomponent» (идентификатор объекта 91).

CHECKDB обнаружил 0 ошибок размещения и 49 ошибок согласованности в таблице «_AccRg1025» (идентификатор объекта 1778313595).

CHECKDB обнаружил 0 ошибок размещения и 3 ошибок согласованности в таблице «_AccRgAT21046» (идентификатор объекта 1826313766).

CHECKDB обнаружил 0 ошибок размещения и 1783 ошибок согласованности в таблице «_AccRg1051» (идентификатор объекта 1906314051).

CHECKDB обнаружил 0 ошибок размещения и 2603 ошибок согласованности в базе данных «KA».

Вариант решения №1: восстановление из бэкапа выявило накопительный характер ошибки: чем раньше сделан бэкап – тем меньше в базе ошибок, вплоть до самого «дальнего» (14 дней). Примерно на третьем бэкапе количество ошибок перестало уменьшаться – стало ясно, что этим путём мы придём только к потере актуальности базы и проблему не решить

Вариант решения №2: В
справочной информации описаны три возможных варианта исправления этих ошибок, рассмотрим каждый:

REPAIR_FAST

Синтаксис поддерживается только для обеспечения обратной совместимости. Действия по восстановлению не выполняются.

REPAIR_REBUILD

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

REPAIR_ALLOW_DATA_LOSS

Пытается устранить все обнаруженные ошибки. Эти исправления могут привести к частичной потере данных.

Аргумент REPAIR_FAST нам не подходит, REPAIR_ALLOW_DATA_LOSS оставим на крайний случай — пробуем REPAIR_REBUILD:

	 DBCC CHECKDB(N'ka', REPAIR_REBUILD) WITH NO_INFOMSGS

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

	 ALTER DATABASE KA
	 SET MULTI_USER

На всякий случай, я попробовал провести обслуживание базы данных и перепроверил – результат тот же.

Решил провести тестирование и исправление информационной базы средствами 1С, на что получил ошибку

Выгрузить базу данных в *.dt файл тоже не удалось:

Что ж, стало понятно, что часть потерянных данных – меньшее зло, по сравнению с «развалившейся» базой данных, пробуем REPAIR_ALLOW_DATA_LOSS:

	 DBCC CHECKDB (N'KA', REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS

И, наконец, после нескольких прогонов, количество ошибок немного уменьшилось:

CHECKDB обнаружил 0 ошибок размещения и 733 ошибок согласованности, не связанных ни с одним объектом.

CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности в таблице «sys.sysdbfiles» (идентификатор объекта 20).

CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности в таблице «sys.sysxmlcomponent» (идентификатор объекта 91).

CHECKDB обнаружил 0 ошибок размещения и 1783 ошибок согласованности в таблице «_AccRg1051» (идентификатор объекта 1906314051).

CHECKDB обнаружил 0 ошибок размещения и 2518 ошибок согласованности в базе данных «KA «.

Ситуацию это не спасло: база, по-прежнему не выгружалась и не «лечилась» средствами 1С.

Дальнейшие попытки (по очереди несколько раз запускал REPAIR_REBUILD и REPAIR_ALLOW_DATA_LOSS) не увенчались успехом: количество ошибок не уменьшилось, база, по-прежнему, не выгружалась и не «лечилась».

Коллеги подсказали попробовать очистить (именно очистить, без удаления самой таблицы) «проблемную» таблицу в MS SQL.

Больше всего ошибок в таблице «_AccRg1051» – ей и было принято решение заняться:

Вводим запрос

	 TRUNCATE TABLE _AccRg1051

И, после успешного выполнения, прогоняем проверку еще раз:

	 DBCC CHECKDB(N'ka') WITH NO_INFOMSGS

15 минут ожидания и, о чудо – все ошибки исчезли, в том числе и в остальных таблицах.

Перевожу базу в многопользовательский режим, выгружаю в *.dt файл и загружаю обратно.

Звоню бухгалтеру – прошу проверить проблемные документы: всё работает нормально. Пускаю остальных пользователей в базу.

Через час снова ошибка:

Делаем вывод, что выгрузка в *.dt – не панацея. Выгоняем Вежливо просим пользователей выйти и ещё немного потерпеть и тестируем базу с исправлением ошибок в режиме конфигуратора 1С со следующими параметрами

Видим, что всё ОК

Пускаем обратно пользователей в 1С и идём молиться настраивать планы обслуживания баз данных.

Источник

ЛЭРС УЧЁТ

Загрузка…

Источник

Kleo

16.12.15 — 06:18

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

База УПП 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» — это регистр накопления «НДС по партиям запасов»

И как и что исправить не знаю? Подскажите, пожалуйста!

Kleo

1 — 16.12.15 — 06:22

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

los_hooliganos

2 — 16.12.15 — 06:28

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

zva

3 — 16.12.15 — 06:30

«repair_allow_data_loss — это минимальный уровень исправления для ошибок, найденных DBCC CHECKDB (UPP, repair_rebuild)»

Запуститу на копии DBCC CHECKDB (‘UPP’, REPAIR_ALLOW_DATA_LOSS) для начала…

Kleo

4 — 16.12.15 — 06:35

(2) данные не потеряются, если удалить индексы?

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

Kleo

5 — 16.12.15 — 06:39

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

los_hooliganos

6 — 16.12.15 — 06:48

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

Kleo

7 — 16.12.15 — 06:50

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

zva

8 — 16.12.15 — 06:51

(7) http://catalog.mista.ru/public/192648/

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

Kleo

9 — 16.12.15 — 07:04

(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

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

los_hooliganos

10 — 16.12.15 — 07:08

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

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

Kleo

11 — 16.12.15 — 07:13

(10) нужно запускать запрос в (9) «Выполнить» или нет?

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

Ёпрст

12 — 16.12.15 — 07:23

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

Ёпрст

13 — 16.12.15 — 07:25

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

Kleo

14 — 16.12.15 — 07:35

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

Затем пишут:

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

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

los_hooliganos

15 — 16.12.15 — 07:52

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

Kleo

16 — 16.12.15 — 08:02

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

Kleo

17 — 16.12.15 — 08:36

Сделала, запускаю повторно запрос проверки, выдает следующее:

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

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

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

los_hooliganos

18 — 16.12.15 — 08:47

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

Kleo

19 — 16.12.15 — 09:02

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

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

los_hooliganos

20 — 16.12.15 — 09:20

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

Kleo

21 — 16.12.15 — 09:32

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

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

Kleo

22 — 16.12.15 — 10:47

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

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

los_hooliganos

23 — 16.12.15 — 11:24

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

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

Kleo

24 — 16.12.15 — 11:31

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

Necessitudo

25 — 16.12.15 — 11:42

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

Kleo

26 — 16.12.15 — 13:06

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

Источник

Добрый день,

в общем проблема возникала после остановки виртуального хоста из за нехватки места (Hyper-V).

Возникли проблемы с двумя базами — одна SharePoint 2013 (контента), вторая 1С — бухгалтерия (в общем то, что надо не какая нибудь база поиска)… SQL 2015

Базы в статусе — «ожидание восстановление»

По базе 1С — администратор настраивал резервное копирование ежедневное и ежемесячное. Однако удалил часть файлов старых из за того, что они занимали место. Остались 4 BAK файла, за последние 4 дня и один за месяц.

Копирование производилось полное (установлено опция). При попытке восстановить, выдает ошибку «Не может проверить хранилище».

Когда я выбираю — восстановить из файла, указываю файл и нажимаю просмотреть содержимое возникает ошибка:

ЗАГОЛОВОК: Microsoft.SqlServer.Smo
System.Data.SqlClient.SqlError: RESTORE HEADERONLY прервано с ошибкой.
Чтобы получить справку, щелкните: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=11.0.3000.0+((SQL11_PCU_Main).121019-1325+)&LinkId=20476

И ТАК НА ВСЕХ файла BAK 5 шт … кстати их объем достаточно велик, база 5 Гб — BAK файлы по 9 Гб

По базе SharePoint — бэкапа никакого и не было.

Прогонял через DBCC CHECKDB (‘DB’, repair_allow_data_loss) — выдает ошибки

Пробовали способ:

Создание чистой базы

и подмена старой (кроме журналов (остаются новые)), затем выполнение проверки повторной. Не принесло результатов.

Сообщение 7984, уровень 16, состояние 1, строка 2
Предварительная проверка системных таблиц: объект с идентификатором 3. Страница (1:740808) имеет непредвиденный тип 2. Инструкция проверки прервана из-за неустранимой ошибки.

В журнале приложений:

«Ошибка при попытке выборки логической страницы (1:741667) в базе данных 5. Она принадлежит единице распределения 72057663922765824, а не 562949956960256.»

Прошу помогите, что можно придумать еще с бэкапами и что посоветуете сделать в такой ситуации если их вовсе нет.

Спасибо

Изменено

10 марта 2016 г. 21:18
Изменен тип
Иван ПродановMicrosoft contingent staff, Moderator
25 марта 2016 г. 6:10

Источник

<!-- wp:paragraph -->
<p>Сбой выполнения запроса "DBCC CHECKDB(N'Buh2') WITH NO_INFOMSGS</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>" со следующей ошибкой: "Ошибка в таблице. Идентификатор объекта 1147151132, идентификатор индекса 6, идентификатор секции 72058313950232576, идентификатор единицы распределения 72058369575026688 (тип In-row data). Нижнее значение ключа на странице (1:154545) (уровень 0) меньше значения ключа в родительском объекте (1:154496), слот 52.</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>Ошибка в таблице. Идентификатор объекта 1147151132, идентификатор индекса 6, идентификатор секции 72058313950232576, идентификатор единицы распределения 72058369575026688 (тип In-row data). Верхнее значение ключа на странице (1:154544)</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>..</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>CHECKDB обнаружил 0 ошибок размещения и 130 ошибок согласованности в таблице "_Reference147" (идентификатор объекта 1147151132).</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>CHECKDB обнаружил 0 ошибок размещения и 130 ошибок согласованности в базе данных "MKVerumBuh2".</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>repair_rebuild - это минимальный уровень исправления для ошибок, найденных DBCC CHECKDB (Buh2).". Возможные причины сбоя: проблемы с этим запросом, свойство "ResultSet" установлено неправильно, параметры установлены неправильно или соединение было установлено неправильно.</p>
<!-- /wp:paragraph -->

Переходим в SQL Server Management Studio и, сделав, на всякий случай, бэкап текущего состояния, выполняем проверку:

Для начала переводим нужную нам БД в однопользовательский режим

Запускаем Окно запросов (CTRL+N). Выбираем Новый запрос и вводим запрос Transact-SQL (T-SQL) в этом окне:

ALTER DATABASE Buh2
SET SINGLE_USER
WITH ROLLBACK IMMEDIATE

Сканируем базу на ошибки:

USE [Buh2]
DBCC CHECKDB(N'Buh2')

Есть 2 варианта решения:

Восстановиться из копии базы до ошибки
Тестировать базу и исправлять ошибки. Есть 3 варианта:

REPAIR_FAST

REPAIR_REBUILD

REPAIR_ALLOW_DATA_LOSS

Пытается устранить все обнаруженные ошибки. Эти исправления могут привести к частичной потере данных.

Первый и второй вариант в нашем случае не помогло. Пробуем последний вариант:

USE [Buh2]
DBCC CHECKDB(N'Buh2', REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS

Возвращаем базу в многопользовательский режим

ALTER DATABASE MKVerumBuh2
SET MULTI_USER

На всякий случай тестируем базу в режиме конфигуратора.

Источник