Checkdb обнаружил 2 ошибок размещения

Делимся опытом, как исправить ошибки в логической целостности в базе 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

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».

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

	 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С и идём молиться настраивать планы обслуживания баз данных.

09.08.13 — 08:36

1 — 09.08.13 — 08:38

2 — 12.08.13 — 06:51

3 — 12.08.13 — 07:10

(2) sql server agent работает?

4 — 12.08.13 — 07:10

(3) да, на скрине показано.

5 — 12.08.13 — 07:12

(4) сорри, не увидел. Поставьте сервиспак 4-й, в RTM всякие чудеса возможны.

6 — 12.08.13 — 07:14

и когда поставите — проверьте снова расписание для шага — галка «Включено» должна стоять, у вас это поле вообще не активно.

7 — 12.08.13 — 07:21

8 — 12.08.13 — 07:42

(7) не знаю. А почему вы СП не хотите ставить?

9 — 12.08.13 — 08:54

(8) Я просто никогда не ставил его, как-то не охото навредить, как-то ссыкатно)) Если что пойдет не так, меня порвут)))

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

10 — 12.08.13 — 09:42

11 — 12.08.13 — 10:28

(9) ну потренируйтесь на копии, что ли, перед тем как на боевом сервере обновляться. В принципе, можно обновиться и без перезагрузки, для этого все службы SQL Server должны быть остановлены, ЕМНИП.

(10) да, можете, 1-3 ставить не надо.

12 — 12.08.13 — 10:40

(11) Спасибо !

13 — 13.08.13 — 15:09

Обновил до СП4, картина не измнилась, все то же самое, как на скрине…

Подскажите, может кто сталкивался, как быть?

(13) создайте новый план обслуживания. На вашем скрине достаточно странный план, не хватает выделенных красными овалами элементов http://s018.radikal.ru/i502/1308/a8/43794759bd99.png

и покажите скрин окна из Manage Connections.

Плюс, убедитесь что в SQL Server Agent -> Jobs создались job’ы вида ИмяПланаОбслуживания.ИмяСубПлана, что их расписания соответствуют созданному вами расписанию в плане и стоит галка Enabled в свойствах job’a.

My first question would be do you have latest valid backup or not. Since database size is just 6G and also because minimum repair suggested by checkdb is repair_allow_data_loss , which can cause data loss and could also remove business constraints from database, it would be good to restore database from valid backup.

Before restoring the backup you need to check validity of the backup. You can do it using below

restore verifyonly from disk='Backup location'

If it comes out clean you can restore the backup to get back the database. The data loss also depends upon the recovery model of database if it is simple you can only restore full and differential backup if it is bulk logged and Full you can restore full ,differential and log backups to get minimum data loss.

Are you able to take backup of current database with continue after error. Please see if below command works, I guess it would

backup database db_name to disk='Location' with continue_after_error

This would generate corrupt backup of database now restore this backup file ON DIFFERENT SERVER using continue after clause normal restore wont be possible see TSQL Restore for restore command.

After above is done run checkdb within transaction like below on above restored database.

Begin transaction
dbcc checkdb('db_name', repair_allow_data_loss)
--commit

After this you can have look into database how much data checkdb has deleted to recover database. Please note checkdb also removes constraints so I would not ask you to run it. Please read Books Online Document before proceeding

At last please see SQL Server errorlog and event viewer to see why database got corrupted

!Рекомендую сначала сделать физическую копию файлов БД (mdf,ldf)!
Как вариант определить битые таблицы по ID, и попробовать Checktable на конкретных таблицах сначала Repair_rebuild, если СУБД ответит что минимальный уровень — REPAIR_ALLOW_DATA_LOSS , значит сделать Checktable(<ПутьКТаблице>,REPAIR_ALLOW_DATA_LOSS ). Покоцанные страницы таблиц будут очищены, но те, что не покоцаны, должны стать доступны для работы (часть данных потеряется, но БД должна стать доступна для работы).
Если определить битые таблицы по ID — проблематично (по каким-то причинам) можно сразу на БД зарядить :
DBCC CheckDB (<ИМЯБД>, REPAIR_ALLOW_DATA_LOSS).
Т.е. скрипт примерно такой:

USE ИмяБД;
GO  
--(Далее выполнять поочереди)
EXEC sp_resetstatus 'ИмяБД'
GO

ALTER DATABASE 'ИмяБД' SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO

--Попробовать:
DBCC CHECKALLOC (ИмяБД, REPAIR_REBUILD) WITH NO_INFOMSGS
GO

--Если СУБД сообщит, что для исправления ошибок - минимальный уровень 
--REPAIR_ALLOW_DATA_LOSS тогда:
DBCC CheckDB (ИмяБД, REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS
GO

ALTER DATABASE ИмяБД SET MULTI_USER
GO

Добрый день! Имеется сервер Sharepoint 2013, Server SQL 2014 и Active Directory. Все на Windows Server 2012. После обновления Windows на сервере Sharepoint в центре администрирования появилась ошибка «База данных в диапазоне совместимости.
Рекомендуется произвести обновление». Обновление завершилось ошибкой и теперь ферма Sharepoint не «видит» сервер баз данных (и сами базы соответственно). При запуске Центра Администрирования Sharepoint выдает ошибку:

Ошибка выполнения

Описание:
На сервере возникла ошибка приложения. Текущая особая настройка ошибок для

этого приложения не позволяет отобразить сведения об ошибке данного приложения.

Сведения: Для разрешения просмотра сведений данного сообщения об

ошибке на локальном сервере создайте тег <customErrors> в файле
конфигурации «web.config», который находится в корневом каталоге текущего

веб-приложения. В теге <customErrors> следует задать атрибут «mode» со

значением «RemoteOnly». Для разрешения просмотра сведений об ошибке на удаленных

компьютерах задайте для «mode» значение «Off».

<!-- Файл конфигурации Web.Config -->

<configuration>
    <system.web>
        <customErrors mode="RemoteOnly"/>
    </system.web>
</configuration>

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

страницу ошибок, изменив атрибут «defaultRedirect» тега конфигурации

<customErrors> приложения таким образом, чтобы он содержал URL-адрес

пользовательской страницы ошибок.

<!-- Файл конфигурации Web.Config -->

<configuration>
    <system.web>
        <customErrors mode="On" defaultRedirect="mycustompage.htm"/>
    </system.web>
</configuration>

При запуске мастера настройки Sharepoint выдает: Сбой при определении присоединения этого сервера к ферме серверов…

Служба кэша AppFabric не стартует.

В журнале приложений такая ошибка: База данных «SharePoint_Config» в экземпляре SQL-сервер «SVPLKDB» не пуста и не соответствует текущей схеме базы данных

Подскажите как восстановить связь с базой данных.