Добрый день.
Есть база данных в режиме фулл. Иногда на тесте требуется восстановить из бекапа рабочей базы. Обычно связку фулл бекап + дифф. Сегодня попросили на определенное время.
И вот тут при накатке очередного лога за 8 утра, получаю ошибку:
Msg 824, Level 16, State 2, Line 10
SQL Server обнаружил логическую ошибку ввода-вывода, связанную с согласованностью: неверный идентификатор страницы (ожидаемый 1:3105792; фактический 2:0). Она произошла при прочитать страницы (1:3105792) в базе данных с идентификатором 28 по смещению 0x000005ec800000 файла "E:\Data\TEST_DB.mdf". Дополнительные сведения см. в журнале ошибок SQL Server и журнале системных событий. Это серьезная ошибка, которая угрожает целостности базы данных и должна быть немедленно исправлена. Выполните полную проверку базы данных на согласованность (DBCC CHECKDB). Эта ошибка может быть вызвана многими причинами; дополнительные сведения см. в электронной документации по SQL Server.

Делаю проверку рабочей базы - ошибок не обнаружено.
CHECKDB found 0 allocation errors and 0 consistency errors in database 'Prod_DB'.

Из связи фулл + новый ночной дифф восстановление без ошибок. А вот попробовал добавить сегодняшние логи и опять ошибка, теперь на логе в 9 утра
Msg 824, Level 16, State 2, Line 12
SQL Server обнаружил логическую ошибку ввода-вывода, связанную с согласованностью: неверный идентификатор страницы (ожидаемый 1:3105792; фактический 1:3491112). Она произошла при прочитать страницы (1:3105792) в базе данных с идентификатором 29 по смещению 0x000005ec800000 файла "E:\Data\test1234.mdf". Дополнительные сведения см. в журнале ошибок SQL Server и журнале системных событий. Это серьезная ошибка, которая угрожает целостности базы данных и должна быть немедленно исправлена. Выполните полную проверку базы данных на согласованность (DBCC CHECKDB). Эта ошибка может быть вызвана многими причинами; дополнительные сведения см. в электронной документации по SQL Server.

Сломанная рабочая база вроде сама чиниться не может. Так на что больше похоже и что можно сделать? Насколько может быть проблема с созданием бекапа логов (получаются утром битые почему-то)?

Yasha123,

Похоже на правду. Проверил вроде бы нормально восстанавливающие фулл+бекап за вчера - есть ошибки. Но прям с ошибками восстановления падало только на 7-8 лог файле.
Прошлый раз checkdb прошел без ошибок, фулл от 2 числа тоже нормальный, текущая база и бекапы из неё сейчас без ошибок, а вот несколько дней 4 утро-5 утро проблемные.

При этом база на 04.02.2020 01:00 нормальная, на 07:30 уже битая.
На 05.02.2020 01:00 и после 15:00 нормальная, на 08:20 битая.

Жалоб никаких нет, с проблемами не обращались. В ошибках checkdb номера разных объектов. 1С что-ли создают и дропают битые таблицы, и не признаются... Странно как-то.

Yasha123,

Спасибо всем за ответы!

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

База хотя бы небольшая, можно быстро проверять восстановление. Бекапы от сегодня фулл+ночной дифф+логи восстановилиссь на тесте без проблем, checkdb ошибок не нашёл.

Восстановил на продуктиве в новую базу "проблемный" бекап от 04.02.2020, опять падает на логе в промежутке 7-8 утра.

Msg 824, Level 16, State 2, Line 11
SQL Server обнаружил логическую ошибку ввода-вывода, связанную с согласованностью: неверный идентификатор страницы (ожидаемый 1:3105792; фактический 0:0). Она произошла при прочитать страницы (1:3105792) в базе данных с идентификатором 16 по смещению 0x000005ec800000 файла 'G:\Data\Test1234.mdf'. Дополнительные сведения см. в журнале ошибок SQL Server и журнале системных событий. Это серьезная ошибка, которая угрожает целостности базы данных и должна быть немедленно исправлена. Выполните полную проверку базы данных на согласованность (DBCC CHECKDB). Эта ошибка может быть вызвана многими причинами; дополнительные сведения см. в электронной документации по SQL Server.

А не может быть проблема в записи\копировании бекапа лога? Бекап создаётся на диск на другом сервере через планы обслуживания, опции проверять чексумму и целостность бекапа включены, но не факт, что проверяет нормально это. Хотя у других баз в это же время проблем нет с бекапами логов.

1C Developer,

Я верю в коллег:)

Как-то привык, что или база нормальная или битая и начинаются танцы с бубнами: починки с потерей данных\восстановление последнего нормального состояния базы с заливкой данных заново\экспорт данных в другую таблицу.

Текущая ситуация с бекапами прода удивляет: База нормальная - спустя 7 часов - База битая - спустя ещё 10 часов - База нормальная - спустя 8 часов - база битая - спустя 5 часов нормальная. При этом жалоб нет, если бы не запрос на восстановление на определенное время о происходящем и не узнали бы. А вот то, что если сломают на проде что-то ещё, а восстановиться на время может и не удастся - очень плохо. Причём пока не понятно - то ли проблема в базе бывает(бекапы нормально создаёт), то ли база всегда нормальная, а начало часть бекапов битыми делать, но нигде это не отмечает сервер.

Yasha123,

Я уже вообще не понимаю, что творится.

Проверял сегодня ещё раз старые бекапы. Фулл от 02 + дифф от 03. На тесте вчера восстанавливал из этих бекапов и ошибок checkdb не находил. Сегодня из этого же бекапа пробовал на рабочем сервере в новую базу и ошибки были. Восстанавливаю ещё раз на тесте - нормально. Ради проверки восстановил вообще на другой машине с другими дисками - те же ошибки. Проверяю скрипты на тесте и других серверах. Похожие. Пример скрипта:



На очередной проверке начались ошибки и на тестовом сервере, где до этого было нормально (из всё тех же файлов бекапа).
Но хотя бы уже появились какие-то числа и ссылка на таблицу.
Msg 8998, Level 16, State 2, Line 11
Ошибки на страницах GAM, SGAM или PFS блокируют проверку целостности распределения в базе данных с идентификатором 29 на страницах от (1:3105792) до (1:3113879). Чтобы обнаружить причину, просмотрите другие сообщения об ошибках.
Msg 8909, Level 16, State 1, Line 11
Ошибка в таблице. Объект с идентификатором 2100970611, идентификатором индекса 1, идентификатором секции 72057595576844288, идентификатором единицы распределения 72057595815723008 (тип In-row data), идентификатором страницы (1:3105792) содержит в заголовке страницы неверный идентификатор страницы. PageId в заголовке страницы = (1:3491112).
CHECKDB обнаружил 1 ошибок размещения и 1011 ошибок согласованности в таблице "_Reference83" (идентификатор объекта 2100970611).
CHECKDB обнаружил 2 ошибок размещения и 1011 ошибок согласованности в базе данных "DB_proverka".

Несколько раз восстанавливал после появления и на тесте ошибок - в проверке всё та же таблица. Но этим бекапам уже несколько дней, их явно не менял никто. На тестовый сервер файлы копировал для проверки, но из основного хранилища тоже с ошибками получается. Было упоминание возможных проблем с дисками на сервере, где восстанавливаю, но пробовал уже на абсолютно другую дисковую полку восстанавливать и не помогло.

Yasha123,

Проверкой в ОС, для более полной проверки коллеги говорят, что останавливать работу системы нужно. Но как возможная проблема с этими дисками может мешать восстановлению абсолютно на другой машине со своими дисками?