Configsave 1c где найти
Обновлено: 03.07.2024
Все админы делятся на две категории:
1) те, которые делают бэкапы
2) те, которые будут делать бэкапы.
Как 2я категория становиться 1й категорией :).
В стандартной документации 1С не сказано про нештатную работу 1С:Предприятия. Во многих статьях рекомендуется использовать сервера с различными механизмами резервирования устройств, использовать источники бесперебойного питания и ДЕЛАТЬ РЕЗЕРВНЫЕ КОПИИ, храня их на отдельном носителе (от данных).
В действительности же, каждый из нас считает своим гражданским долгом сначала довести базу до невосстанавливаемого состояния и только потом (когда петух клюнет) что-то делать.
Методика
Ниже обобщил свой опыт помощи в таких случаях.
1. Зафиксируйте время возникновения ошибки на бумаге. (Это в дальнейшем поможет локализовать место изучения различных логов)
Вот некоторые возможные варианты текста ошибки:
Ошибка SDBL:
Разрушена структура базы данных 1С:Предприятия. (pos=0)
Произошла неизвестная ошибка на сервере 1С предприятие (80010108)
В MS SQL Server база данных может оказаться со статусом «Suspect».
Решить эту ситуацию можно созданием новой базы с таким же именем и такими же по именам и расположению .mdf и .ldf файлами, укажите параметр базы autoclose = true, чтобы можно было не останавливать сервер целиком.
Теперь подменяем файл .mdf . Можно также использовать проверку физической целостности базы командой DBCC CHECKDB.
Если останавливали сервер, Стартуем, не обращаем внимания на статус базы
и в Query Analyzer выполняем:
alter database <db_name> set emergency –- для 2005
go
После рестарта SQL Server (в командной строке):
Net stop mssqlserver
Net start mssqlserver
база должна быть видна (в emergency mode).
7.5 Вариант отката к конфигурации базы данных. Ошибка устраняется открытием конфигуратора данных ключами запуска /RollbackCfg.
7.6 Проверенное лекарство для тяжелых случаем, когда не запускается конфигуратор или не открывается конфигуруция (только для СУБД MS SQL Server 2005):
Аварийное завершение обновления конфигурации базы данных
Проблема, которой посвящена статья, возникает при аварийном завершении работы конфигуратора в тот момент, когда происходит реструктуризация базы данных, то есть - на одном из последних этапов обновления конфигурации. Решение, описанное в статье, относится к клиент-серверной версии платформы "1С: Предприятие", использующей в качестве СУБД "MS SQL Server".
Симптомами могут служить следующие предупреждения системы:
1) При попытки запуска базы в режиме конфигуратора:
2) При попытки запуска базы в режиме предприятия:
3) При входе в конфигуратор система может также предложить следующее решение:
На данный вопрос мы можем ответить утвердительно. И часто таким способом проблема решается. Но не всегда.
Или же потребовать монопольного доступа, что не всегда удобно в системах с большим количеством пользователей, а иногда и просто невозможно.
В этом случае нам поможет MS SQL Server. Для решения нашей проблемы достаточно последовательно выполнить следующие скрипты (разумеется в контексте проблемной БД).
1) Сначала создадим копии таблиц Config и ConfigSave (впоследствии, их можно удалить).
INTO Config _ copy
В данных таблицах, как раз, и хранится информация о конфигурациях и ходе обновления. В первой таблице хранится информация о конфигурации БД, в том числе, и данные последнего обновления. Вторая таблица содержит данные новой, ещё несохраненной конфигурации. Анализируя содержание этих таблиц, система получает данные о том, насколько успешным (или неуспешным) было последнее обновление.
2) Удаляем все записи из таблицы ConfigSave (хранит накатываемую конфигурацию)
DELETE FROM [ConfigSave]
3) Удаляем три записи из таблицы Config (именно они хранят информацию о незаконченном процессе обновления конфигурации)
DELETE FROM [Config]
WHERE FileName IN ( 'commit' , 'dbStruFinal' , 'dynamicCommit' )
Далее следует обновить конфигурацию в штатном режиме, то есть через конфигуратор.
В таблице Config должны появиться записи о нашем последнем обновлении, что легко проверить обычным «селектом».
Предистория
Два дня назад осуществили переход с 8.1 на 8.2 - меняли конфу УПП 1.2. на 1.3.22.1. Соответственно куча отличий от типовой конфигурации, которые накатывали - повлекло за собой кучу ошибок. Два дня, не ночуя, меняем конфигурацию в режиме нон-стоп. Конфигуратор сохраняется раз 15 в час. Следовало ожидать, что при сохранении, конфигурация может вылететь, что собственно и произошло. Такие проблемы, в конфе 8.1 - всегда разрешались выходом пользователей, которые еще работали в базе, но уже не могли повторно войти и монопольным доступом. В нашей же новой конфигурации 8.2 база сказала нам "Я устал. Я ухожуй" ), в общем проблема описана в анонсе.Что было предпринято из правильного и неправильного. И совет о том что делать первым делом.
Первым делом мы в суматохе начинаем искать способы решения возникшей проблемы в интернете. Гугл дает буквально 3 статьи на текущий момент по тексту возникающей ошибки.
В общем во всех трех статьях ответ на решение текущий проблемы один - "Восстанавливайте базу из бэкапа".
Не стоит говорить о важности бэкапов их регулярности и прочем. Считаю что в плане нас это было хорошим предупреждением, хотя у нас и был бэкап базы после ее сохранения в конфигурации 1.3 но за их регулярностью и тем что они делаются (а винчестер не чистится и прочее) , за этим мало кто следит. Соответственно простите за "капитана очевидность", но если у вас есть свежий бэкап - первым делом и займитесь восстановлением базы из него, не теряйте драгоценное время, за простой которого руководство вас не поблагодарит. Однако можно попытаться оживить "упавшую" базу, что благодаря моей настырности было и предпринято. Отмечу, что другим программистом также были приняты попытки как то оживить базу 1с-вскими способами, но они были безуспешны. Не знаю всего что он делал, но видел попытки запуска 1С в командном режиме сразу с запуском Тестирования и исправления ИБ, которые собственно ничего не запускали.
Требования и непосредственно само восстановление базы
Итак все что было выше, читать, в случае возникшей проблемы, может и интересно, но необязательно.(Внимание. Посмотрите обязательно сноску снизу, если хотите попробывать оживить и саму конфигурацию. Сегодня (18.04.2012) путем экспериментов мне это удалось ибо стало жалко недельный труд который был проделан над ней. Таким образом получилось базу оживить оставив старый конфигуратор без всяких копий)
Исходные данные - SQL база 1С 8.2, конфигурация УПП 1.3.22.1 (полагаю описанный способ подойдет для любой эскюэльной базы 8.2). SQL сервер 2005. Ошибка описанная в анонсе и ошибка возникшая в момент сохранения конфигурации! Самое важное и обязательное требование. Копия SQL базы с ТАКОЙ ЖЕ КОНФИГУРАЦИЕЙ(!) У нас настроен авто-обмен с другой базой и конфигурации их совпадают. Кроме этого, так как нас трое программистов 1С - у каждого есть выгруженный и относительно свежий файл конфы. По факту подойдет любая база, неважно с какими данными, главное чтобы конфигурация в ней соответствовала структуре метаданных базы. Отмечу тот факт, что конфигурация даже немного отличалась от той, с которой база вылетела. Самое основное, на мой взгляд, требование, чтобы отличия в конфигурации не затрагивали метаданные. Не стоит забывать тот факт, что если конфигурация отличается, то в итоге вы получите рабочую базу но с конфигурацией из вашей копии.
Сам процесс восстановления не займет у вас много времени - буквально пару минут, но крайне рекомендую предварительно сделать бэкап даже "упавшей" базы, а он может занять время. Например у вас будет возможность восстановить базу откатом из log-файла (который у нас к сожалению в суматохе восстановления "грохнули") или еще какой способ. Итак, напомню что где то должна быть SQL база неважно какими данными но с такой же конфигурацией. Если у вас конфигурация представляет из себя "нетроганную" типовую (что подразумевает, что данная проблема возникла в процессе наката новой типовой конфигурации) - можете создать новую пустую базу и залить туда типовую конфу, которая у вас была до этого. В случае, если конфигурация, которую вы нашли, не такая уж свежая - подумайте и примите решение, возможно те отличия с копией конфигуратора, которые вы будете вынуждены повторить в вашей базе, займут много больше времени и ресурсов, нежели потеря информации самой базы данных 1С. Своеобразная палка о двух концах ) Итак.
1. Делаем бэкап рухнувшей базы средствами SQL.
2. Очищаем таблицу dbo.config нашей базы в которой лежит наша порушенная конфа. Это можно сделать из SQL- Profiler, к примеру запустив в нем команду:
Delete From [DBO].[Config]
где Base2009 имя рухнувшей базы.
Примечание: где-то в сети читал непроверенную инфу, что иногда помогает очистка таблицы dbo.ConfigSave, в которой, якобы, лежит накатываемая конфа. В нашей базе она оказалась пустая, поэтому чистить пустую таблицу, понятно не стал. Возможно - можно как-нибудь обмануть и оживить базу 1С, используя данную таблицу но, не зная механизм работы 1С с этой таблицей, ничего не буду говорить в плане действий, применительно к ней.
3. Копируем таблицу из базы с целой конфигурацией, в нашу порушенную базу. В моём случае обе базы были на одном сервере поэтому команда копирования в SQL-Profiler выглядела так.
insert into [base2009].[Dbo].[Config] select * from [BaseCopy].[Dbo].[Config]
где base2009 - имя рухнувшей базы, BaseCopy имя базы с копией конфигуратора
4. Запускаем 1С, и в случае успеха - прыгаем, как я от радости, что удалось оживить базу без каких-либо потерь информации.
5. (Капитан очевидность) проверяем отлаживаем и следим за системой создания бэкапов базы и очень ответственно подходим к процессу обновления конфигурации (делаем это не по сети, а желательно на сервере, по возможности сделав предварительно бэкап). Особенно если версия вашей 1С стала 8.2. Насколько я понял из статей в сети и превых двух дней работы с ней, что она более чувствительна и капризна, по сравнению 8.1 с которой таких проблем не было.
5а. Если конфигурация базы с которой вы будете копировать таблицу конфы - все-таки отличается, (не имея при этом отличий в метаданных, о чем я уже говорил), и где-то лежит ваш относительно свежий cf-файл с выгруженной конфой - накатываем его на ожившую базу. В противном случае Вам придется повторить все те отличия, которые были с копией конфигуратора. Так что еще раз хорошо подумайте и проанализируйте - что важнее - ваша работа по изменению конфигурации (и сколько времени вы на это потратите) или работа пользователей базы до момента последнего бэкапа. В моем случае это была работа 2-х программистов в течении 3-х часов против работы порядка 100 пользователей в течении 1.5 дней, так что выбор был очевиден.
З.Ы. Еще раз напомню, что данная функция восстановления является недокументированным 1С-овцами способом восстановления базы (в конкретном случае обрушения базы, произошедшего в процессе сохранения конфы) и все что вы делаете - вы делаете на свой страх и риск, но конкретно в моем случае других путей оживить базу с минимальной потерей существующей информации не было (лог файл потерли и самый свежий бэкап представлял потерю 1.5 дня работы порядка 100 пользователей), поэтому, как говорится мосты были сожжены )
З.Ы.Ы. Это моя первая публикация тут т.к. трусь на других 1С форумах, но нахожу этот ресурс одним из самых полезных в плане выложенных разработок и публикаций, поэтому не судите строго за много ЕСЛИ в данной публикации). Буду очень рад, если реально помог кому-нибудь с восстановлением порушенной базы ибо страшнее этого только ядерная война )
З.Ы.Ы.Ы. Спустя 3 недели проблема повторилась ) На этот раз на решение было потрачены какие-то секунды (если не учитывать время создания бэкапа), и даже пользователей не пришлось выгонять.
Сегодня прибежал коллега. Та же самая беда. Только база тестовая а не рабочая и сама база ему поскольку постольку - а вот конфигуратор ему важен. Неделю он краптел над ним ни разу не выгрузив в cf файл и не накатив изменения в рабочую базу. Ну что ж - почему бы не поковырятся уже с таблицей?! На этот раз все еще проще. Открываю SQL Managment Studio. Формирую запрос по таблице на поля с текущей датой изменения и временем когда у него вылетела база - результат дает 2 записи. Первая - Поле FileName = "commit" Ну что же - грохнуть эту запись - и у меня все получилось! Конфигуратор ожил и база опять работает. Что же нужно сделать?!
Поводом к написанию данной статьи, послужило падение базы во время сохранения конфигурации, при динамическом обновлении. Казалось бы сколько уже раз предупреждали - «Не делайте динамическое обновление на 8.2!», но иногда, без него просто не обойтись.
«Внимание. При обновлении данных, после последней реструктуризации, произошла ошибка. Повторить обновление?» «Да, Нет»
«Обнаружена незавершенная операция сохранения конфигурации. Для продолжения работы необходимо завершить операцию.»
И после нажатия на кнопку «Ок» это окно закрылось вместе с конфигуратором. Вот тут-то я и начал подозревать, что все будет не так просто.
Бэкап, конечно же имелся, но с одним нюансом - больше чем за половину дня, 2000 пользователей, сделали кучу документов и прочей полезной работы, а бэкап был только по состоянию на утро, да и восстановление базы, размером более 100 Гб, занимает ну очень продолжительное время.
Продолжая копать глубже, я узнал, что все дело в "испортившихся" таблицах dbo.Config и dbo.ConfigSave .
Итак, отставить панику!Проверяем есть ли у нас конфигурация идентичная рухнувшей. В моем случае, их было целых 4, так как работаем через Хранилище Конфигурации. Можно использовать и не совсем идентичную конфигурацию, но будьте готовы к тому, что тогда все изменения придется вносить заново (если конечно у вас нет Хранилища Конфигурации).
Далее заходим в SQL Management Studio и очищаем таблицы dbo.Config и dbo.ConfigSave рухнувшей базы с помощью нехитрого запроса (для того чтобы его написать, нажмите "New Query" или "Новый Запрос", ну а чтобы выполнить - "Execute" и "Выполнить" соответственно):
Все, теперь осталось "залить" эти же таблицы из хорошей конфигурации. Как я уже написал выше, способ предложенный VanDiesel1 мне не помог, так как рабочая база и все базы с хорошими конфигурациями, находились в разных кластерах. Почитав мануал к SQL Management Studio, я наткнулся на такую возможность, как импорт таблиц из одной базы в другую и незамедлительно решил ей воспользоваться. Итак в SQL Management Studio становимся на испорченную базу и щелкаем правой кнопкой мыши, далее Tasks -> Import Data.
Откроется визард в котором:
- На второй странице указываем сервер и базу из которой мы будем брать данные.
- На третьей указываем базу приемник.
- На четвертой выбираем "Копировать данные из таблиц".
- На пятой отмечаем галками таблицы dbo.Config и dbo.ConfigSave.
- На шестой смотрим, чтобы не было ошибок и процесс загрузки прошел успешно.
Вот собственно и все, можно пробовать запускать 1С.
P.S. В ходе поиска решения узнал, что этот способ восстановления, является недокументированным 1С и все действия, вы выполняете на свой страх и риск, а документированный способ - это восстановление из бэкапа.
Надеюсь эта статья, кому-нибудь поможет сэкономить время и нервы. Также напоминаем что в нашем облаке 1С имеется бесплатное резервное копирование, которое защитит Вас от потери данных.
Читайте также: