Друзья. Случилось горе-беда, упала база ТиС на SQL. Сразу оговорюсь: База была файловая, но т.к. один из регистров был слишком огромный (известное ограничение 1с 7.7) с июня сего года базу я экспортировал в SQL и всё бы ничего, если бы не моя лень, лень сделать бэкап...
И вот попал: SQL Server обнаружил логическую ошибку ввода-вывода, связанную с согласованностью: неверная контрольная сумма (ожидаемая 0x207589f9; фактическая: 0x21f589f9). Она произошла при прочитать страницы: (1:25392) в базе данных с идентификатором 5 по смещению: 0x0000000c66000 файла: c:\skladsql\skladsql.mdf
Ну и предварительно сделав бэкап, я давай её лечить разными снадобьями:
DBCC CHECKDB ('skladsql', REPAIR_FAST)

автор
Сообщение 7985, уровень 16, состояние 2, строка 1
Предварительная проверка системных таблиц: объект с идентификатором 5. Не удалось

прочитать страницу (1:25392) и заблокировать ее кратковременной блокировкой типа SH.

Инструкция проверки прервана из-за неустранимой ошибки.
Результаты DBCC для "skladsql".
Сообщение 5233, уровень 16, состояние 98, строка 1
Ошибка таблицы: идентификатор единицы размещения 327680, страница (1:25392). Выполнить

тест (IS_OFF (BUF_IOERR, pBUF->bstat)) не удалось. Значения равны 12584969 и -6.
CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности, не связанных ни с

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

"skladsql".

DBCC CHECKDB ('skladsql', REPAIR_REBUILD)

автор
Сообщение 7985, уровень 16, состояние 2, строка 1
Предварительная проверка системных таблиц: объект с идентификатором 5. Не удалось

прочитать страницу (1:25392) и заблокировать ее кратковременной блокировкой типа SH.

Инструкция проверки прервана из-за неустранимой ошибки.
Результаты DBCC для "skladsql".
Сообщение 5233, уровень 16, состояние 98, строка 1
Ошибка таблицы: идентификатор единицы размещения 327680, страница (1:25392). Выполнить

тест (IS_OFF (BUF_IOERR, pBUF->bstat)) не удалось. Значения равны 12584969 и -6.
CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности, не связанных ни с

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

"skladsql".


DBCC CHECKDB ('skladsql', REPAIR_ALLOW_DATA_LOSS)
автор
Сообщение 7985, уровень 16, состояние 2, строка 1
Предварительная проверка системных таблиц: объект с идентификатором 5. Не удалось

прочитать страницу (1:25392) и заблокировать ее кратковременной блокировкой типа SH.

Инструкция проверки прервана из-за неустранимой ошибки.
Результаты DBCC для "skladsql".
Сообщение 5233, уровень 16, состояние 98, строка 1
Ошибка таблицы: идентификатор единицы размещения 327680, страница (1:25392). Выполнить

тест (IS_OFF (BUF_IOERR, pBUF->bstat)) не удалось. Значения равны 12584969 и -6.
CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности, не связанных ни с

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

"skladsql".


DBCC checkdb('skladsql')
ALTER DATABASE skladsql SET SINGLE_USER WITH ROLLBACK IMMEDIATE

автор
Сообщение 7985, уровень 16, состояние 2, строка 1
Предварительная проверка системных таблиц: объект с идентификатором 5. Не удалось

прочитать страницу (1:25392) и заблокировать ее кратковременной блокировкой типа SH.

Инструкция проверки прервана из-за неустранимой ошибки.
Результаты DBCC для "skladsql".
Сообщение 5233, уровень 16, состояние 98, строка 1
Ошибка таблицы: идентификатор единицы размещения 327680, страница (1:25392). Выполнить

тест (IS_OFF (BUF_IOERR, pBUF->bstat)) не удалось. Значения равны 12584969 и -6.
CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности, не связанных ни с

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

"skladsql".


DBCC CHECKALLOC ('skladsql')

автор
Сообщение 5233, уровень 16, состояние 98, строка 1
Ошибка таблицы: идентификатор единицы размещения 327680, страница (1:25392). Выполнить

тест (IS_OFF (BUF_IOERR, pBUF->bstat)) не удалось. Значения равны 12584969 и -6.
Сообщение 7985, уровень 16, состояние 2, строка 1
Предварительная проверка системных таблиц: объект с идентификатором 5. Не удалось

прочитать страницу (1:25392) и заблокировать ее кратковременной блокировкой типа SH.

Инструкция проверки прервана из-за неустранимой ошибки.

_____________________========================________________________
Ничего это не дало вообщем...  на соседнем форуме: https://www.sql.ru/forum/1330120/pomogite-podnyat-bazu
Всыпали конечно пинка, местами даже правильный маршрут дали.
Что сосбна я сделал: Создал пустую БД и с помощью встроенной утилиты: "Мастер импорта и экспорта данных" я перетащил живые таблицы в чистую базу.
Поле запуска этой новой базы, и проверив что же я потерял.... а потерял я только таблицу: Номенклатура, да это печально, но это уже не так и плохо, ведь могло быть гораздо всё хуже...
Перечень повреждённых таблиц:
_1SCONNECT
_1SCONST
_1SCRDOC
_1SSTREAM
DH1731
DH2051
DH2695
DH3504
DH4389
DH9054
DH9125

DT1611
DT1774
DT2051
DT3614
DT4389
DT5292
DT9054
DT9125

RA2351
RA2964
RA351
RA4314
RA4335
RA438
RA4480

RG2351
RG2964
RG351
RG4314
RG4335
RG438
RG4480

SC131
SC84
SC9246
SC9249
___===__
Регистры я так понял фиг бы с ними, их можно будет через Тестирование и исправление восстановить...

Перейдём к делу: Все повреждённые базы, я так понял входят в диапазон повреждённой страницы данных: (1:25392), однако не малый...
Я пытаюсь сделать выборку в одной из повреждённых таблиц:
select * from skladsql.._1sconnect
На что получаю:
Сообщение 829, уровень 21, состояние 1, строка 1
Страница (1:25392) в базе данных с идентификатором 5 помечена RestorePending, что может означать повреждение диска. Чтобы вернуться к обычному состоянию, выполните операцию восстановления.

Возможно ли как-то снять пометку с этой страницы и аккуратно построчно выдернуть данные из повреждённых таблиц?
ps. На удивление диск живее все живых, SMART в идеале, также прогонял Victoria, всё гуд...

у тебя же население просило вывод dbcc page

(0)
https://www.mssqltips.com/tipprint.asp?tip=1645

Хотя не.. у тя ж нема архивов, :))

И таки да, забей месяц ручонками, по первичке, делов-то

какая  модель восстановления ?

(4)

вот еще, почитай
https://habr.com/ru/post/137301/

+5 * это к (0)

на скл.ру есть решение) "hex редактором скопировал страницу (1:1204298) (sysrowsets) из old в bad"

(7) дык..откуда он её возьмёт то ? old ?

Ну, разве что опять из старой базы дбф подымет скуль базу и че-нить состряпает

Что за напасть - желание работать в SQL?.. Мода? Не вижу необходимости..
С 2001 года 7-ка трудится на сервере в файловом варианте - и нет претензий, ни у кого. Трудится исправно, бекап еженедельно, не считая моих копий ежедневно, на случай падения.. так и не падала ни разу за 19 лет.
(0) сколько у тебя пользователей? У меня 23. И не урчат, скорость вполне подходящая, висяков нет.

ЗЫ. админы делятся на 2 группы:
1. те, что делают бекап, и
2. те, что будут делать бэкап..

Традиция..

(0) Диск то какой? ssd? У них бывает такое (из-за ошибок в прошивке) что и смарт в порядке, и любое тестирование проходит, а сектора сыпятся.
Если ssd - либо гугли бывает ли на нем проблема и на какой прошивке, либо меняй от греха подальше.
И то что РАНЬШЕ в dbf база не падала тоже не показатель.
У меня Crucial отработал какое то количество часов, потом стал портить файлы. Перезагрузка помогала, на пару дней, а потом опять.
Новая прошивка вроде бы должна была это исправить, но я его забраковал и забрал домой под не сильно нужную хрень.
Прошил на новую версию, но не сильно удивился, когда он однажды обнунлился целиком...

(3) +1 единственно верное решение.

(10) Что за напасть работать в dbf?
Одна переиндексация чего стоит. Уже давно всех на 7.7 по возможности перетаскиваю на скуль. Все довольны.

(13) с 2002 база на дбф. ваще без хозяина была. с конца 2007 - крутится под моим присмотром. бэкапы еженощные, днем получасовые инкрементные или разностыне хз, админ делал

(13) Ну да, тоже ДБФ работает, порядка 40 пользователей, база порядка 10 ГБ. При переводе на скуль обнаружил кучу тормозов в работе отчетов особенно ну и при групповом проведении документов раз в 10 медленне чем на ДБФ, скуль пробовал 2008.

(14) Бекапы чем делаешь? Мы кобианом. Вполне надежно и почту отправляет с инфой о результатах бэкапа. Но мы вечером раз в сутки. Еще ж периферийки. Тогда надо и обмен запускать раз в 30 минут а смысл? Но вот это бэкапы через каждые полчаса интересный вариант конечно

(4) Полная
(5) Читал, не помогло, база окончательно рухнула в "восстановление"...
(10) У меня 2 машины работают в этой базе, и когда вторая начинает работать с документами, или делает какую-нибудь реализацию, операции выполняются крайне долго, каждая форма висит по 1-2 минуты перед тем как открыться...
(11) Диск HDD, комп ровестник этой базы)))
(3) в БД есть остатки за прошлые годы, а сколько и чего и почём было неведомо.. в бамажных доках нет инфы...
(15) Я не могу такую производительность объяснить никак, разве что если вы под терминалом народ загоняете...

ДРУЗЬЯ.
Решил всё же отчитаться, а то есть куча тем безо всяких решений.
Я решил это кривовато, но более-менее со временем всё устаканилось.
Развернул файловую версию полугодовой давности, выгрузил её в SQ и с помощью операции: ЭКСПОРТ, которая в SMSS, каждую таблицу экспортировал и какие таблицы не давал скопировать, те я выдернул из старой базы.
По остаткам всё красиво, потерялся десяток строк номенклатуры, но это мелочи....
Ну и по регистрам остатков тоже немного были расхождения... но более-менее удалось выровнялось черед дополнительный ввод остатков и замена карточек на.... благо с июня доки надо было поднять, а не 10 летней давности...

(17) а можете специально для тупых (для меня лично) обьяснить фразу " Я не могу такую производительность объяснить никак, разве что если вы под терминалом народ загоняете.."