Всем привет!
Проблема следующая: посыпался raid на сервере... На нем крутилось 2 базы 1с 7.7(Комплексная) на SQL. Сунулся в архивы - оказалось что они битые... То есть архивация была настроена неправильно - архив создавался сразу на сетевое хранилище, а не на локальную машину а потом копировался на хранилище... В результате - несоответствие контрольных сумм архива. ТО есть он вроде и есть и его нет (((. Всякие программы по восстановлению и исправлению архивов толком не помогли, архив распаковался после этого, но при подключения базы на SQL - она SUSPECT и выходить из этого состояния никак не хочет... SQL ругается на incorrect file size. В связи с этим вопрос: можно ли что-то сделать с данными базами или архивами, приму любые предложения, в том числе и на коммерческой основе... Только просьба - озвучить сколько, примерно, это будет стоить...

выстави ценник за восстановление - народ и потянется

думаю за 500-1500 usd

Вам softpoint.ru
помогут

а чего рейд прям так посыпался что нельзя перемонтировать?

(2) если "некорректный размер", то вряд ли что-то можно сделать
Ну и сумма полтора килобакса для софтпойнта - смешная....
унмножь на 3 минимум...

Да, с рейдом бился неделю - так и не смог ничего сделать...

(4) мне недавно слали файлы по 8ке с рейда, там размер нормальный но внутри ни одного байта от 1с...

а по поводу размера скуля - хз, может и выйдет...

тут 2 этапа
1. подключить файл
2. лечить базу

если подключить файл не удастся - то кирдык. Если удастся - то многое зависит от везения


по сабжу отписал, смотри почту

Файл, который вытащен из поврежденного архива приаттачить не получается - опять же из-за incorrect file size... База в suspect и выходить никак не хочет из этого состояния.... Есть еще старый рабочий архив полуторалетней давности, то есть часть информации и структура базы есть неповрежденные..

(6) А толку с ним биться. Для этого есть специальные конторки.

Вот про это можно поподробнее:
"архив создавался сразу на сетевое хранилище"
и
"Всякие программы по восстановлению и исправлению архивов толком не помогли"
Я правильно понял, что вы архивировали файлы базы при работающем скуле?

Да уж. Судя по описанию тут действительно все очень сильно зависит от везения. Если в битом файле не задета структура SQL то наверное что то можно сделать. Мы восстановлением БД занимаемся но либо когда совсем все просто(то есть можно гарантировать 100% результат и понятны трудозатраты).  Либо когда совсем все сложно и к сожалению 100% гарантиии в этом случае нет.

Нет, архив делался по принципу:

net stop mssqlserver
затем создание архива на сетевое хранилище сразу, без создания архива на локальной машине.
затем net start mssqlserver или reboot сервера...

Так вот, я уже потом это выяснил - когда создаешь архив по сети очень часто и возникает проблема в расхождении контрольных сумм архива (SRC) из-за чего архив оказывается поврежденным и инфа с него не достается...
Правильный порядок - Стоп Скуль - создание архива на ЛОКАЛЬНОЙ машине и затем уж копировать его куда угодно... Вот только узнал я об этом поздно((( Теперь-то так и делаю, конечно (с другими базами), архивы все получаются нормальными...

(10) за backup у вас расстреливают?

Да я понимаю что backup это святое... Но... тем не менее все так сложно.... Архивы (7z) делались отдельными, 1-й сама база, 2-й mdf файл и 3-й - log... И все оказались поврежденными... Они есть за неделю, но битые все одинаково...

(12) mdf база не архивированы?

Архивированы... Именно эти архивы и битые... Иначе бы проблем не было...

(12) ну вот ещё один пополнит ряды, которые уже делают backup

а вот это "при подключения базы на SQL - она SUSPECT" как?

так понимаю, что есть база и ее можете подключать. вот и вопрос, в самом файле есть данные? какой размер у mdf ldf(вроде так лог называется)?

можно данные восстановить (если в mdf есть что то), но гарантии, что будут все данные, нет

Когда пытаюсь сделать аттач базы - не дает... Создаю новую базу с этими файлами - цепляется, но при любом обращении к ней - она suspect... Это все с файлами (mdf и ldf), которые вытащены из поврежденных архивов с помощью разных прог типа ZIP repair. И все варианты, найденные в инете по поводу выведения ее из этого состояния не помогают - incorrect file size и все... В mdf и в ldf все данные точно есть - только вот как сами эти файлы достать без повреждения из архива? Я пробовал Recovery Toolbox For SQLServer (лицензия) она разбирает всю базу на составляющие и делает  SQL скрипты, в принципе, все данные в таблицах видны становятся, но толком потом в кучу собрать их не могу, не хватает знаний по этой теме.... Подробнее про нее можно здесь посмотреть: http://www.oemailrecovery.com/ru/faq-import-saved-scripts-into-database.html

nauandr, как базу после извлечения из архива подключаете?

а ну вот, уже сам все знаешь))) ну вот этот скрип и выполняй в новой базе

Не надо создавать новую базу и менять файлы!
Разархивируйте файлы в каатлог и используйте attach/

их вроде как по очереди нужно запускать (очень давно это было, все забыл), создай базу в консоли sql

(22) а чем отличает команда attach от контекстного меню? может что упустил...

(19) и что, после запуска Install.bat из http://www.oemailrecovery.com/ru/faq-import-saved-scripts-into-database.html не заработало

(24) Ничем.
Но замена файлов БД вроде как и должна породить статус suspect.
Ведь инфа о них храниться в master.

что то припоминаю, там потом нужно еще какие команды выполнять после восстановления что бы из этих статусов вывести, кажись вот http://www.gerixsoft.com/blog/mssql/recovering-mssql-suspect-mode-emergency-mode-error-1813

(12) Какой-то стремный вариант архива. А чем архивирование средствами скуля не устраивало?

После выполнения инсталла с этих скриптов получаю полунерабочую базу - то есть нет организаций и номенклатуры и части других объектов... Написано "Объект не найден\id объекта"... Попробовал запустить восстановление в рабочую, но полуторалетнюю базу - ненайденных объектов стало меньше - но они все равно есть... И много... В основном - номенклатура... ТО есть документы все есть, даже суммы по ним посмотреть можно - но вот их содержимое в виде номенклатуры и.т.д. порушено... При запуске ТИИ - не проходит говорит что 1sjournal порушена и затыкается на этом....

ну тут анализировать нужно. посмотри, вообще на скуле в этих справочниках есть данные? не в 1с

АНДР, не могу разархивировать нормально! Только через ZIP repair или подобные проги - но на выходе получаю инкоррект сайз файлов при аттаче... Как еще можно вытащить из архива без повреждения??? "SRC неверно" пишет при простом извлечении файлов из архива...

на sql сделай перестройку индексов

(12) прописать бэкап по расписанию гораздо проще. Можно даже с контролем целостности.
(29) как именно ругается на journ?

ну что, помогло _1sp_DBReindex

Я так понимаю у вас есть несколько архивов, пытайтесь из всех извлечь данные и потом собирайте в общую кучу, может повезёт. Но надежды мало.

А что с файлами БД на посыпавшемся рейде? Какова их судьба?

Архив полуторалетней давности можно применять только для вытаскивания недостающих данных, да своих доработок. Структуру БД брать из последнего дистрибутива.

Реиндексация тут не поможет :(

ну тогда только собирать из уцелевшего по кускам

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

(29) если база подцепилась в скуле - этого уже достаточно, только 1с не пытайся что-либо делать,

если база подцепилась - сделай средствами SQL бекап и отложи его!!!!

(38) сделай несколько вариантов баз из разных архивов, будет прозще

(10) "когда создаешь архив по сети очень часто и возникает проблема в расхождении контрольных сумм архива (SRC) из-за чего архив оказывается поврежденным и инфа с него не достается..."

Чушь какая-то, кто это бред вам сказал? С чего вдруг CRC должны поменяться? Может программа- архиватор корявой версии?
Вообще не понимаю - зачем останавливать скуль что бы сделать архив? MS-SQL сам прекрасно может сделать свой архив не останавливаясь, в любое время.

_1sp_DBReindex не помогло, 1SJOURN говорит "Ошибка блокировки при модификации или удалении записи"

(40) скорее всего автор под "архивом" понимает тупое копирование ldf и mdf на соседний комп.. вот скуль и стопарит :))

База в скуле подцепляется и открывается только та, которая средствами Recovery Toolbox For SQLServer была восстановлена из архива, который был восстановлен средствами ZIP repair... Вот такие сложные костыли... В результате, как и говорил уже, база открывается, но ссылки в ней на многие объекты потеряны... Архив - да, согласен, крайне неправильно делался, но просто уж так получилось, что это наследие от предыдущего админа было, я и не лез туда, к тому же перешли на 8-ку и скуль 2008 соответственно, там уже я сам настраивал средствами скуля как положено (там и работает все как положено), а эту архивацию, которая полетела - у меня и руки не дошли проверить толком - другой работы с 8-кой хватало...

(43) если охота и дальше время терять:

при востановлении ldf
1. кластерные индексы слетают
2. возможно задвоение и появление "фонтомов" (например двух разных версий одного обьекта)

по этому востановленая таким образом база напрямую не может быть использована.

единственное чего можно - это использовать ее как источник данных для заливки в пустую нормальную....

но перед заливкой нужно прибить дубли...


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

Востановить можно, но это геморой, а геморой должен оплачиватся :)

(5) Блок питания менял? Походу дела он глючит, потому как некорректная контрольная сумма - это явные глюки. Не должно так быть.

итого
полностью восстановить данные не получится
процесс восстановления долгий, муторный и не гарантированный
дальше либо сам, либо за бабло без гарантии восстановления

(10) Не должно так быть. У вас проблема либо с сетью, либо с сетевым хранилищем, либо с машиной, которая бэкап делает.

Проблема с сетью... И я ее знаю... Просто переубедить начальство что web видеокамеры (примерно 25 штук) перегружают сеть напрочь своим видеопотоком постоянным я никак не могу... Чем нагрузку на сеть замерить можно? Я ничего не нашел... А без цифр и доказательств мне говорят что это просто сам придумал и переделывать никто ничего не хочет...

(48) У вас что, все на хабах построено? Коммутатор изолирует поток с камер от сервера и сетевого хранилища. Или они широковещательные запросы используют? Да и по-любому 7z при превышении таймаута записи должен был ошибки сыпать...

своеобразно делался архив канечно , оригинально

(48) ping большими пакетами делов-то