Полетела база : УТ (снятая с поддержки)
win serv 2008R2, SQL 2005, платформа 8.2.13.219
При динамическом обновлении (были внесены след изменения
1) открытие конфигуратора на локальной машине пользователя под логином администратора,
2) в плане обмена открытие раздела "состав",
3) установка у документа "СчетФактураПолученный" галочки "Авторегистрация" в режим "Разрешить",
4) Сохранение и динамическое обновление конфигурации.
ВСЕ!)

выдал после обновления  и авторизации ошибку "Тип не определен'a087679...."
после чего всем активным пользователям выдал ту же ошибку и прервал сеанс.

Сама база не маленькая (более 100 гигов).
Вечер и ночь пытались реанимировать с учетом личного опыта и того что нашли в инете
1) почистили кэш сервера 1С
2) выгрузка/загрузка средствами 1С в поверх
3) выгрузка загрузка в новую базу(пустую)
4) откат платформы до 205 релиза
5) бета 8.2.14 в которой упоминается о такой ошибке и о том что проблему пофикисли
6) между 1п. и 2п. пытались выловить ошибку при запуске системы (модуль внешнего соединения. проц. ПриНачалеРаботыСистемы, модуль сеанса проц. УстановкаПараметровСеанса, гл. модуль "ПолныеПрава" проц. УстановитьПараметрыСеанса)
7) не дает откатить внесенные изменения - экстренное завершение работы программы. в журнале ошибок след инфа
Имя сбойного приложения: 1cv8.exe, версия: 8.2.13.219, отметка времени: 0x4d80c789
Имя сбойного модуля: basic.dll, версия: 8.2.13.219, отметка времени 0x4d80c048
Код исключения: 0xc0000005
Смещение ошибки: 0x000ac9a0
Идентификатор сбойного процесса: 0xa5c
Время запуска сбойного приложения: 0x01cc361feecbdd66
Путь сбойного приложения: C:\Program Files (x86)\1cv82\8.2.13.219\bin\1cv8.exe
Путь сбойного модуля: C:\Program Files (x86)\1cv82\8.2.13.219\bin\basic.dll
Код отчета: 429550bb-a214-11e0-b91e-78e3b508de6f
8) не дает  провести реструктуризацию таблиц через тестирование и исправление

Что делаем не так? Что можно еще предпринять?
Заранее спасибо всем откликнувшимся (ситуация полный ахтунг!)

PS: бэкап есть только 10-ти дневной давности - не вариант(отдельные слова благодарности админам, но сейчас не об этом)

Предлагаю:
3) выгрузка загрузка в новую базу(пустую) - (файловую) и chdbfl.exe

не указал - в файловую не пролазит(срабатывает ограничение по объему таблиц для файловой)

все перечисленное уже проделано. Что еще можно предпринять.

backup не сделал естественно?

"PS: бэкап есть только 10-ти дневной давности - не вариант(отдельные слова благодарности админам, но сейчас не об этом)"

демоническое обговление это зло, одноэсы писали уже официально

(5) очень захотелось нарушить п.1 Правил.. если база большого размера, то какого х.. вообще используете динамику???

за 10 дней так много изменений? База распределенка?

Перед обновлением всегда делаю контрольный бекап. На админа не надеюсь. Если даже что-то сделаете база будет кривая с плавающими обортомаи. ОБновлять динамически без бекапа ...

как обычно всё сводится к ССЗБ

Как вариант на чистой машине раскрути серваки Win, SQL и сервер предприятия. И попробуй там поднять базу. Если не поможет, досвидос.

объем реально очень большой(понятно что времени ковырять битую базу не так много - максимум до вечера сегодняшнего дня)
дальше берем последний бэкап и вперед!!!
Но при целых то   файлах  БД SQL  *.mdf (объемом в 115 гиг) мне кажется правильней будет не попробовать восстановить

*.CF пробовали  из бекапа 10 дневной давности  выгрузить и загрузить без сравнения?

(13) он же сказал, "не вариант" почему-то

(9) изменений в структуре никаких.
Была определенная срочность с настройкой обменов (рабочий процесс прервать не было возможности )

Все ошибки понятны. Прошу реальных идей по восстановлению.
Что такого могло произойти при динамическом обновлении, что придется хоронить базу(данные то все целы, это очевидно)

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

(13) (14) при попытке обновить конфигурацию вылетает  с ошибкой (описание п.7)

>  это очевидно
Мне это не очевидно. Данные и повредились, скорее всего.

Пробовали загрузить cf-ник с рабочей копии? Если грузится, накатывается, и вызывает ошибку - это битте данне.

(18) пробовали, вылетает с ошибкой

DBCC CHECKDB
DBCC CHECKALLOC

Звоните в 1С, они уже проснулись.

(21) Там скажут что юзеры деляться на 2 вида: те кто делает бэкапы и те кто ещё не делает

(21) Они упп на облачную переводят, не надо им мешать.

(22) +100500, собственно то же, что было сказано и здесь)) Вопрос: чем 1С отличается от мисты?))

Как производить проверку, переиндексацию базы на SQL Server

Проверку логической целостности нужно выполнять штатными средствами 1С:Предприятия (Тестирование и исправление ИБ). В случае, если такую проверку не удается выполнить, следует проверить физическую целостность БД средствами MS SQL. Для проверки целостности средствами MS SQL нужно выполнить следующую команду: DBCC CHECKDB ('<имя базы>',REPAIR_REBUILD) Перед выполнением этой команды нужно базу данных перевести в режим "single user": sp_dboption '<имя базы>','single user',true. В процессе работы DBCC CHECKDB могут быть обнаружены ошибки и часть может быть сразу же исправлена. Если ошибки остались, то по всей видимости их нельзя восстановить без потери некоторых данных. В этом случае нужно запустить DBCC CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS (перед запуском желательно сделать копию файлов базы данных). DBCC CHECKDB ('<имя базы>',REPAIR_ALLOW_DATA_LOSS) После выполнения DBCC CHECKDB нужно не забыть вернуться в нормальный режим (выйти из режима "single user"): sp_dboption '<имя базы>','single user',false Переиндексацию базы данных на MS SQL не нужно делать так часто, как в случае с DBF-версией 1С:Предприятия (например, при аварийном завершении работы пользователя). MS SQL автоматически поддерживает индексы в актуальном состоянии. Пересоздавать индексы имеет смысл в одном из следующих случаев:
1) Индекс физически поврежден. Это случается довольно редко и для восстановления нужно использовать вышеупомянутый DBCC CHECKDB.
2) Страницы индекса сильно фрагментированы и требуется их упорядочить.
3) Нужно изменить степень заполнения индексных страниц (fill factor).
4) Требуется изменить тип индекса (кластерный/некластерный). При использовании 1С это обычно неактуально.

Для пересоздания индексов следует воспользоваться командой: DBCC DBREINDEX ('<имя таблицы>') или запустить хранимую процедуру, которая переиндексирует все таблицы в базе данных: EXEC _1sp_DBReindex

http://www.1csql.ru/materials/faq/admin.html?pagenumber=2

тем что 1С будет отвечать дольше и не факт что адекватней - поэтому здесь.
Вся надежда на коллективный разум\опыт

запустил пока DBCC CHECKDB  - т.к. объемы внушительные займет какоето время (есть еще одна копия базы - если есть еще соображения скидывайте)

Тут реально у тебя могут внутренний гуайды слететь в базе и при обмене может пойти "каша". Мысли в слух...

(27) при динамике с учетом порочного кэша могло произойти что угодно.

(28)там транзакции должны быть, если конечно тинейджеры 1С о них знают

(0) есть какие-то проги сервисы по проверки файла базы данных, не помню название, по-гугли, она проверят файл на ошибки, меня спасало

Восстановить нормальный архив и перенести инфу за 10 дней из битой базы

(29) Обновление накатили уже. Поэтому пофигу - должны они быть или не должны.

(29) при динамическом не спасает даже святая вода

(26)
"3) установка у документа "СчетФактураПолученный" галочки "Авторегистрация" в режим "Разрешить",
"
сделать обратное и обновить, перед эти перепрописать базу (очистить кеш)

+(30) причем тоже тестирование и исправление тупо затыкалось 1с-ное, а прога помогла, плюс у тебя SQL-вариант, попробуй запустить проверку базы оттуда

поднять базу 10 дневной давности и запустить ТИИ, посмотреть как пройдет

(31) опыта такого переноса нет - есть что почитать на эту тему?

(33) типун тебе, пару раз выходил из ситуации))) напугаешь сейчас человека

(33) Перед тем, как нажать Да для запуска динамического обновления, надо перекреститься, трижды сплюнуть через левое плечо, вспомнить всю свою прошлую жизнь (лучшие ее моменты) и на всякий случай приготовить баку вазелина и шаблон заявления об увольнении по собственному без отработки двух недель.

(0)ну ладно переставили бы. но зачем это:
"4) откат платформы до 205 релиза "
?

(33) валится конфигуратор при обновлении (писал изначально)
пробовали перепрописывать базы в том числе

(41)а если выгрузить конфигурацию БД и загрузить её?

"8) не дает  провести реструктуризацию таблиц через тестирование и исправление " - это в чем выражается?

тех. журнал что пишет?

(0) Послушай совета, сделай реструкуризацию и тестирование базы через скуль, выручает

Кто против (31)? Почему способ плохой? Вдруг у меня тоже будет трындец

(42) п.2 и п.3 - не помогло
п.8 - валится так же как и при п.7

(45) А он войти в базу не может. Что ему переносить? По памяти?

(45) а как ты себе это представляешь?? Данные как вырезать будешь, а если задним числом доки проводят.

(0) Ну ты тип, перед обнов копию не сделал и на админа косит!!!

Автор, с момента последнего бэкапа и до текущего состояния базы, вносились ли изменения влияющие на структуру таблиц?

(47) Мда, я не внимателен. Но если бы можно было запустить, то решение хорошее

1. сделайте бекап текущей базы
2. восстановите в отдельную базу старый бекап
3. в текущей базе очистите таблицы Config, DBSchema, Params
4. перенесите содержимое этих таблиц из старого бэкапа

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

(50) Нет. Изменений не вносилось.

(0) http://aco.org.ua/howto/winhowto/38-faq-po-administrirovaniyu-1s-i-ms-sql-server.html
пункты 9,10

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

(0) А вообще в режим конфигуратора входит?? появилась идея.

(56) входит же, конфу выгружал загружал

В общем народ, на обсуждение.
А если в такой ситуации попробовать восстановить 10-ный архив, создать хранилище конфигурации, потом подключить крякнутую базу к данному хранилищу, конфигурация откатится на состояние бекапа. По моему вариант.

почему меня все игнорируют??))

(59) Вы хотите об этом поговорить ? ))

(56) В конфигуратор входит без проблем. Даже дает сохранить изменения в конфигурации, но в дальненйшем при нажатии на "Обновить конфигурацию базы данных" программа падает на этапе "Обработка структуры базы данных..."

(52) есть ли смысл перенести последовательно  Config, DBSchema, Params или с большой долей вероятности они все битые
Если да, то в какой последовательности?

(60) да, доктор, меня это беспокоит))) обычно ко мне прислушиваются, а тут аномалия

(58) Пробовали откатить конфигурацию с помощью загрузки cf-ника 10 дневной давности. Вроде бы физически это тоже самое что загрузить конфигурацию из хранилища, нет? Проблема в том, что сохранить не получается.

(0)1.Восстанови бэкап.
2.Зайди в конфигуратор, создай хранилище конфигурации(Конфигурация->Хранилище конфигурации -> Создать хранилище)
3. В хранилище, через администрирование создаёшь ещё одного пользователя хранилища
4. Заходишь под конфигуратором в сломанную базу
5. Подключаешь к хранилищу(Конфигурация->Хранилище конфигурации -> Подключится к хранилищу) Там указываешь путь илогин с паролем ранее созданный.
6. Конфигурация откатится на состояние бекапа, возможно (!!!, велика вероятность) что поможет

А что за архив 10 дневной давности?
Может есть архивы сделанные средствами SQL и журнал логов с той даты цел?

я пропустил может? что CHECKDB скуля дало?

(64) по идее нет. советом (54) тпак и не хочешь попробывать воспользоваться??

(67) крутится до сих пор - база очень неповоротливая (((

(+68) не весь пост прочитал, понял, ждёмс

(0) В отладку вообще заходит модуль обычного\управляемого приложения - ПередНачаломРаботыСистемы или сразу падает?
На сервере отладка вклчена (/debug)?
Смысл отладку на модуль внешнего соединения ставить...

а почему такой объём, реально такой объем, или тестирование у вас делается так же как и бэкапы?? 100 гигов это охренеть как много для базы, я работал навод железобетонных шпал, так вот у нас 9 заводов и центральный офис, единая аза занимала 40 гигов, но это РЖД и потоки ИНфы там достаточно серъезные(УПП)

v8: Как получить Уникальный идентификатор базы?

возможно проблема в длине УД инфБазы, если даже сф старая не работает

(73) причем тут "
тип не определён"??

вот тьфу тьфу - пользуюсь динамическим обновлением и ни разу не влетал. База на скуле. На скуле сделано все согласно рекомендациям 1С прописанным на ИТС, ну и перезапуск сервера 1С предприятия - каждую ночь.

ИМХО, если в описании 14 платформы говорят, что исправили
<<При выполнении некоторых запросов может происходить ошибка вида
Тип неопределен f04256af-e4b4-4d0a-8a65-baaa878d4c6de
и аварийное завершение работы программы.
>>
то сам запрос искать нужно...

(75) 100 гигов обновлять динамически, без бекапа это...

(77) Я на этой неделе такое делал (права надо было обновить).
(но бакапы есть)

(78) 1с не рекомендует...

(78) бекапы есть и то хлеб, скульный бекап сделать 10-20 минут делов..

У меня такое ощущение, что дело не только в динамическом обновлении, автор так и не ответил почему такая база большая, но судя по размерам, там тупо запущенная база, ошибки копились, 100Гб скорее всего, потому что тестирование и исправление своевременно не делалось

(79) Ссылочку можно?
(81) У нас всё сжимается, но тоже до 100 Гб доросли.

(82) то есть все сжимается?? свёртку что ли делаете??

http://gilev.blogspot.com/2010/02/1-81.html

Динамическое обновление в 1С:Предприятие 8.1
В 8.1 есть такая функция как динамическое обновление.

Практика показала: ЧТО НЕ НАДО ВООБЩЕ ИСПОЛЬЗОВАТЬ ДИНАМИЧЕСКОЕ ОБНОВЛЕНИЕ!

Слишком много всяких неприятных нюансов может возникнуть, которые заранее фактически не прогнозируются.

1. Например можно словить:
Ошибка СУБД:
ERROR:  relation "_reference5029" does not exist

2. Если изменилась (или удалилась) функция - будет фатальная ошибка или отсутствие контроля целостности данных.

3. Еще одна неприятная ситуация возникает при некорректной работе с кэшем методанных.
Кэш метаданных расположен в папке \<Имя пользователя OS>\Local Settings\Application Data\1C\1Cv81\
В нем необходимо стереть подпапки Config, ConfigSave, DBNameCache, SICache.
В результате легко получить ошибку "Ошибка потока формата".

Примечание.
UUID информационной базы можно посмотреть в файле
C:\Documents and Settings\<Имя пользователя>\Application Data\1C\1Cv81\ibases.v8i.

(82) сеть гипермагов у вас??

(84) там дата 10 февраля 2010 года. Релиз платформы уже энное количество раз обновился.

(84) Это не официальная позиция. Практика-то известна :)
(85) Да обычный опт (до 5000 накладных в день).

(62) последовательность пофиг. главное все 3 таблицы

(65) не помогло

DBCC CHECKDB ('trade',REPAIR_REBUILD)
Ошибок не нашел
но и результата  не дал - та же ошибка
Запустил пока REPAIR_ALLOW_DATA_LOSS на копии базы
(не вижу правда особого смысла, но за неимением лучшего варианта)

Объем большой т.к. база от 2007 года, при среднем кол-ве документов  день около 3000(большая часть документов с большим кол-вом движений по регистрам/углубленной аналитикой, большими ТЧ)
Это сеть, но не гипер, а мини (1500 розничных точек)
Это если коротко.

Тестирование и исправление средствами 1С не делалось. Все регламенты на уроне  SQL.

Приступаю к (52) варианту

(90) таблицу Files можно еще почистить

(91) ?

(92) забей пока.

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

(90) так и планируете растить базу, почему свёртку не делаете?? в бекапах храните не свёрнутые варианты и всё, работоспособность возрастёт

Попробуйте заменить содержимое таблички ConfigSave данными из Config.
Попробуйте заменить эти таблички на таблички из бекапа + DBSchema

(0) cf в пустую базу нормально заргужается?

(97) да

(98) таблички заменили? или в процессе.

(98) "Конфигурация" или "конфигурация БД"?

где-то встречал...
<<пример ошибки когда база открывается в режиме конфигуратора но при открытии в режиме предприятия выдаёт ошибка типа "тип bf3eefc5-26ac-4bb2-bec0-33a82e49a0c5 не найден"

вариант лечения создать для пользователя новый интерфес.
>>

(101) автор ждм результата пробы

http://www.nigma.ru/index.php?fs=plugin.ie&s=0xc0000005

к (103) предотвращение выполнения данных...

use ИмяАктуальнойБазы
go

truncate table [dbo].[Config]
truncate table [dbo].[ConfigSave]
truncate table [dbo].[DBSchema]
truncate table [dbo].[Params]
--truncate table [dbo].[Files]
go

insert into [dbo].[Config] select * from [СтараяБазаИзБекапаНаЭтомЖеСервере].[dbo].[Config]
insert into [dbo].[DBSchema] select * from [СтараяБазаИзБекапаНаЭтомЖеСервере].[dbo].[DBSchema]
insert into [dbo].[Params] select * from [СтараяБазаИзБекапаНаЭтомЖеСервере].[dbo].[Params]

(105) скриптики к (52)

http://2291520.kiev.ua/Ustranenie-opredelennyx-sistemnyx-oshibok/Chto-oznachaet-kod-0xc0000005-v-soobschenie-ob-oshibke.html

Автор, ну как успехи то? Уже расстреляли что ли ((

Нет пока жив)) Сказывается бессонная ночь

(101) не сработало
Что касается (52) (105) уперлись в то, что архивная база находится на другом сервере и просто так перетащить таблицы Config и остальные перечисленные не получается
Загружаем на сервер локально

(109) ну так написал бы. я бы тебе запрос давно кинул. там вариантов масса как перенести.

можно запрос к прилинкованному серверу. а можно эти 3 таблички на удаленном сервере перекинуть с помощью(105) в новую пустую базу где созданы эти 3 таблички. эту базу забекапить и перекинуть куда надо.

давай!

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

(111)
1. на удаленном сервере создайте пустую базу.
2. далее на архивной копии на каждой из таблиц щелкнуть правой мышью и выбрать Script Table As - CREATE TO - New Query Editor
3. Это скрипты создания таблиц. В заголовке каждого из них замените USE [ИмяВашейАрхивнойБазы] на [ИмяВашейПустойБазы]
4. Далее для пустой базы выполнить (105)
5. У вас получиться база с 3-мя конфигурационными таблицами.
6. бекапте ее. Перекидывайте на сервер с больной базой.
7. Разворачивайте и опять (105) но уже для больной базы

Внимательней с выполнением скриптов. Проверяйте для какой бызы запускается скрипт

(113)
после выполнения п.4 выдал

(6326 row(s) affected)

(1 row(s) affected)

(23 row(s) affected)

переносил сразу 5 таблиц как в скрипте(в том числе и  Files)

я к тому , что affected - не внушило оптимизма

В 1С послать не вариант?
Вызвать специалиста за деньги по восстановлению баз не вариант?

(116)они хотят сеть (торговую в смысле) опустить )))

Ещё извиняюсь опять же за оффтоп, должен крутиться скрипт, ежедневно проверяющий делались ли бэкапы, если нет то автоматически отправить письмо всем заинтересованным лицам: так и так мол, бекап сделан не был.

(115) наоборот. это количество обработанных строк. судя по количеству все нормально. так примерно и должно быть.

И каковы результаты после (114)?
Есть подвижки к улучшению?

Спасибо всем за содействие! Особенно тем, кто высказывался по существу.
Особая благодарность  rs_trade - именно перенос конфигурационных таблиц и помог.

(118) если не сложно поделитесь таким скриптом(думаю для многих он окажется полезным)

MISTA -  СИЛА!!!

В базу знаний надо только подробно описать ниже, по-этапно.

метка

(122) а нечего описывать. заменили файлы конфигурации и все.

(124) а почему в скрипте дергается пять баз, а вставляется только 3??

truncate - очистка базы.
Чистим файл кофигурации конфигурации БД параметров (files и dbschema не помню, искать лениво, правда files закоменчено)
и потом вставляем

126 to 125

(126) спс за пояснение, это на самом скуле же скрипт пишется, правильно понял??

(128) Да.
Помниться было описание структуры для SQL ссылок не дам

(128) значит остальные 2 таблицы были пустые.

ConfigSave это конфигурация разработчика. В ней хранятся внесенные изменения вплоть до того момента пока не накатишь изменения на конфигурацию БД. Происходит перенос строк из ConfigSave в Config. Потом ConfigSave очищается.

Ну а Files вообще фигня какая то. Можно забить на нее.

(130) Вxера тоже хотел подсказать про перенос таблиц на уровне SQL, ушел, но уже помогли. Прекрасно! Будем знать.

эта тема мне интересна

зы: база 100 гигов, демоническое обновление.. мндаа....

(121) У нас для бекапа отдельный сервер, я захожу на него и вижу файлы бекапа с датой, если дата бекапа меньше текущей - бекап не сделался и никакого скрипта не надо.
У нас бекап делается автоматически каждую ночь + два раза разностные, в 12.00 и 16.00. При объеме 100 ГБ я бы не доверял сисадмину на слово. Пинайте себя или сисадмина :).
Я думаю навсегда забудешь про динамическое обновление :) на рабочей базе.

(133) да урок очень хороший - что касается динамического обновления!   (с этого момента - демонического, кстати отдельная тема зачем его вообще реализовали в 1С, оно актуально только для баз с большим кол-вом пользователей, читай большого объема)

Что касается бэкапов - вопрос чисто админский, т.к. речь идет о более чем 60 базах на 10 серверах (понятно что одна такая в 100 гиг но тем не менее). Админов целая армия, а спецов по 1С 2 человека( по большому счету один)
Проблема  с бэкапом т.к. перенесли на новый сервер и я не успел отследить выполнение(точнее сообщил админу, о том, что бэкапы не делаются за 2 часа до аварии !!!)

Поэтому еще раз - если (118) сбросит инфу по оповещению на  email средствами SQL , буду крайне признателен

(118)(134) в msdb есть таблица backupset - в нее пишется информация о созданных бэкапах. Для отправки сообщений по электронке в SQL Server 2005 и старше используется Database Mail - в настройке очень проста.
Можете сделать job, который будет проверять наличие записей в этой таблице и отправляющий сообщения, если их там нет.
Информацию о всех бэкапах всех баз можно получить примерно так:

use msdb
select bs.database_name, backup_finish_date, physical_device_name, bs.type from backupset bs
inner join backupmediafamily bmf
on bmf.media_set_id = bs.backup_set_id
order by backup_finish_date desc

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

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

PS: админам будет приходить полный отчет со всем списком баз
А мне только сбои.

еще вопрос - можно ли автоматизировать восстановление backup-ов  SQL в  резервную БД?
Восстановление баз большого объема занимает очень много времени, что не всегда приемлемо

(136) можно. Проверьте запросом - есть запись о бэкапе вашей базы за сегодняшний день или нет. Если нет - сообщение через database mail.  
(137) можно. job'ами. Владельцем job'a должен быть пользователь с достаточными правами на уровне SQL Server. SQL Server Agent должен быть запушен под учтекой, которой хватает прав на папку с бэкапами и папку куда будет производиться восстановление.

(137) Это решается на уровне SQL, SQL backup можно сделать в любое время. Нужно написать скрипты правильно и все.
Вообще напряги сисадминов, раз у вас их такая армия.
Можно также зеркалировать базы на другой сервер.

(137) ссылка тебе в помощь
http://msdn.microsoft.com/ru-ru/library/ms186865.aspx