Сообщение «Файл базы данных 1Cv8.1CD поврежден» характерно для файловых баз данных 1С 8.3 и 8.2. Повреждение может происходить в результате повреждения оборудования, или, чаще всего, в результате неожиданного отключения электроэнергии.
Перед тем, как начать исправлять данную ошибку, нам необходимо сделать резервную копию базы 1С. Перед тем, как делать копию базы, необходимо, чтобы все пользователи, которые работают в ней, вышли из 1С.
Сделать копии можно двумя способами.
Способ №1
Нам необходимо нажать на ярлык 1С, выбрать в списке базу, в которой появилась ошибка, и далее войти в Конфигуратор, нажав соответствующую кнопку.
Далее идем в Администрирование и в выпадающем меню выбираем Выгрузить информационную базу.
Далее выбираем папку, в которую мы сделаем резервную копию нашей базы. Имя файла заполняем так, чтобы в дальнейшем мы смогли найти сделанную копию базы. Ждем окончания сохранения нашей базы.
Способ №2
Используется только если мы не смогли выгрузить нашу базу через Конфигуратор. Сделать копию самой папки, где непосредственно находится наша база 1С.
Для этого запускаем ярлык 1С и в окне выбора баз 1С выделяем базу, в которой появилась ошибка. В нижнем левом углу окна мы видим путь, по которому находится папка с нашей базой.
Ищем на вашем компьютере данную папку и из нее копируем в новую папку, которую нам надо создать в другом месте, файл 1Cv8.1CD
После того, как мы сделали резервную копию нашей базы, нам необходимо протестировать базу утилитой CHDBFL.EXE, которая находится в папке с установленной платформой 1С. Как правило, есть два места расположения платформы, если была сделана стандартная установка.
1. C:\Program Files\1cv8\номер платформы\bin
2. C:\Program Files (x86)\1cv8\номер платформы\bin
Запускаем данный файл и в открывшемся окне указываем расположение файла базы данных 1С, в котором у нас ошибка. Также не забываем поставить галочку Исправлять обнаруженные ошибки, чтобы наша утилита сразу же исправляла их. Далее нажимаем кнопку Выполнить и ожидаем результата. После выполнения проверки и исправления ошибок пробуем открыть нашу поврежденную базу.
Если все хорошо, то продолжаем работу в 1С. Если ошибка осталась, то пробуем почистить кэш данных. Статью вы можете найти в нашем F.A.Q.
chdbfl.exe – утилита для тестирования и исправления файловой информационной базы 1С 8.3 (8.2). Программа производит проверку физической целостности БД, это упрощенный аналог тестирования и исправления в конфигураторе. для тех ситуаций, когда система не запускается даже в режиме конфигуратор. Рассмотрим где расположена утилита chdbfl.exe и как ей пользоваться.
Тестирование и исправление ошибок
Перед проведением любых операций необходимо сделать резервную копию базы данных!
Обратите внимание! Утилиту не нужно нигде скачивать, он находится в папке с установленной программой. Если вы скачаете chdblf.exe из интернета есть вероятность получить вовсе не программу для исправления ИБ, а нанести вред вашему компьютеру и информации компании.
Пользоваться программой очень просто. После запуска отобразится вот такое окно:
Где в форме необходимо указать путь к файлу базы данных и указать нужно ли сразу исправлять обнаруженные ошибки (если флаг не установлен – утилита только продиагностирует ИБ). Путь к файлу базы данных можно узнать из списка доступных конфигураций:
Если у вас не получилось найти программу, то можно у нас!
Если готовы сотрудничать или появились вопросы — звоните 8(4812) 60-33-39!
Важнейшая информация, критичная для работы всей организации, часто хранится и обрабатывается в базах данных. Каждый день, и даже каждый час, недоступности базы данных может приводить к большим финансовым потерям. Восстановление поврежденных данных — одна из специализаций ЕПОС.
Специалисты Центра восстановления информации ЕПОС не понаслышке знают, что при восстановлении баз данных очень важно выполнить все работы максимально быстро. Для этого разрабатывается специальное программное обеспечение, позволяющее в полуавтоматическом режиме извлечь максимум данных из поврежденных баз. Например, утилита EPOS DBF Studio, созданная для восстановления файловых баз данных 1С, обеспечивает успех даже в случае повреждения или отсутствия файловых таблиц. Восстановление производится по внутренней структуре и содержимому файлов БД.
Инженеры ЕПОС имеют опыт успешного восстановления баз данных различных форматов:
|
|
Решающее значение для быстрого и успешного восстановления баз данных имеет точное определение причин и обстоятельств сбоя. Методы восстановления информации выбираются в результате оценки ситуации – так, например, при отказе накопителя, на котором хранилась БД, и при логическом повреждении структуры БД из-за программных ошибок подходы будут существенно отличаться.
Типичные причины отсутствия доступа к базам данных:
- случайное или преднамеренное удаление файлов БД
- форматирование носителя с БД
- поврежденные или неполные SQL файлы (в том числе возможно восстановление SQL БД без файла лога .LDF)
- отсутствующие или недостающие файлы БД
- поврежденные таблицы в БД
- неправильный размер файлов БД
- отказы HDD, выход из строя Flash и SSD накопителей, разрушение RAID массивов, повреждение виртуальных серверов
В некоторых случаях значительно ускорить работы по восстановлению баз данных может наличие резервных копий (даже старых и неактуальных). Такие копии используются в качестве образца структуры и содержимого поврежденной БД, по которому восстанавливается оригинальная база.
Содержание
1. Спасти рядовую пятницу
2. Конфигуратор, у нас проблемы
3. Что делать, шеф?
4. Второй шаг – круг задач
5. Попытки решения
5.1. Попытка 1 — тестирование-исправление ИБ через директиву командной строк
5.2. Попытка 2 — копирование таблиц Config, Configsave, Params и DBSchema из работоспособной копии ИБ средствами MS SQL
5.3. Попытка 3 — очистка таблицы configsave средствами MS SQL
5.4. Попытка 4 — копирование разрушенных таблиц из работоспособной копии ИБ средствами MS SQL
6. Решение, которое помогло:
6.1. Подключение
6.2. Перенос справочников 1С
6.3. Перенос документов 1С
6.4. Проведение документов 1С
7. Выводы. Как избежать поломки структуры данных базы 1С
Спасти рядовую пятницу
Пятница – это не только друг Робинзона. Это – почти выходной. Должен же быть в рабочем календаре день, когда можно подумать о горячих выходных и прохладных напитках. Как минимум, стоит остерегаться резких движений, чтобы сберечь настоящие выходные для команды и пользователей. Во многих софтверных компаниях считается дурным тоном выпускать новые релизы в конце недели. К примеру, Apple «катит» по вторникам. В Яндексе запрещено «катить» по пятницам и перед Новым Годом.
Но однажды пятнице не повезло. Когда сроки горят, а дедлайны давят, всегда найдется чему пойти не так. И дальнейшее развитие событий сильно зависит от компетенций вашей uber-команды.
Конфигуратор, у нас проблемы
Это было обычное обновление конфигурации. Структура данных не поменялась, бизнес-логика тоже. По «большой просьбе» одного из пользователей, решили обновить рабочую базу.
Одно «но»: технологическое окно уже закончилось и основные изменения конфигурации уже были запущены в работу.
«Надо!» – пользователь просит. Что ж, надо – значит надо: программист привычно нажал F7 и согласился с предложением Конфигуратора «обновить динамически».
Через пару часов стало понятно, что база умерла: попытка войти в режиме «1С:Предприятие» отправляло систему «в дамп» после исполнения нескольких строк модуля приложения. Конфигуратор открывался и работал, но попытки внести изменения также приводили к краху без подробностей в журнале регистрации и технологическом журнале.
В результате база перестала открываться. Совсем.
Попытки войти в «1С:Предприятие» не пускали пользователей дальше окна авторизации. Конфигуратор открывался и работал, но без толку для решения задачи: попытки обновить информационную базу и/или выполнить восстановление также приводили к краху.
Анализ СУБД показал, что динамическое обновление разрушило структуру таблиц. Теперь-то каждый разработчик в команде знает, что «динамические обновления» – это зло. И все знают неформальное название – «демоническое обновление». Да, с этого момента динамические обновления в компании для рабочей базы запрещены. Но «фарш невозможно провернуть назад» и утерянная база не запускается.
Утеряно несколько сотен документов реализации, с сотнями товарных позиций.
Что делать, шеф?
Сначала мы оценили, чем в итоге располагаем.
Не так много, но не безнадежно:
* Слепок информационной базы, который делается регулярно по расписанию каждые два часа. Нам «повезло» и восстанавливать потребуется 1 час 53 минуты работы пользователей.
* База, работоспособна на уровне СУБД.
* На уровне COM-соединения работоспособность также сохранилась,
* Проектная команда собралась из разных проектов. (Да, специалист в фирме франчайзи – это универсальный боец и швец, и тд. Пожалуй, это главное, что помогло решить вопрос оперативно).
С этим понятно. Какие потери?
* Примерно два часа работы нескольких сотен пользователей. В основном – документы реализации и заказы покупателей.
* Да, можно восстановить данные по первичке. Но! Представьте себе пару часов работы сотен пользователей в разгар рабочего дня.
* На календаре конец первого квартала – это годовая бухгалтерская, налоговая отчетность. Плюс квартальная отчетность перед партнерами.
* Плюс скоро начислять зарплату и вознаграждения по договорам.
Второй шаг – круг задач
Оценив масштаб последствий, стало очевидно, что ситуация исправима. Как выяснилось позже – это оптимистичный вывод, но оптимистам везет.
Итак, утерян относительно небольшой по времени период – чуть меньше двух часов работы пользователей.
Это сотни документов с табличными частями до сотен строк. Несколько сотен элементов справочников.
И надо было определить, какие из потерь критичны для результата, а что можно пропустить и решить в дальнейшем другими путями.
Например, очень непросто восстанавливать записи (а тем более, итоги) регистров бухгалтерии по двум причинам. Первая – это низкая производительность по сравнению с другими структурами данных. Вторая – сложность организации как в СУБД, так и на уровне объектной модели «1С:Предприятие».
Но так как за эти два часа ручные корректировки регистров бухгалтерии не выполнялись, то можно записи отдельно от документов не восстанавливать. Все движения, подчиненные регистраторам, можно восстановить перепроведением восстановленных документов.
Попытки решения
Попытка 1. Тестирование-исправление ИБ через директиву командной строки Конфигуратора. Примерно так:
1cv8.exe config /IBCheckAndRepair -Rebuild
А также тестирование/исправление СУБД
dbcc checkdb(‘<db_name>’, REPAIR_ALLOW_DATA_LOSS )
Конфигуратор стартовал, висел в списке процессов некоторое время и дальше падал без объяснения причин. Технологический журнал при этом с упорством Капитана Очевидность сообщал о разрушении таблицы с планом обмена.
Попытка 2. Копирование таблиц Config, Configsave, Params и DBSchema из работоспособной копии ИБ средствами MS SQL
insert into .. select * from ..
Это помогло – удалось пройти дальше окна авторизации. Но модуль приложения все равно падал с исключением при попытке опросить планы обмена. Отключить проверку в этом куске кода не удалось, так как попытки сохранить конфигурацию приводили к падению Конфигуратора на этапе анализа структуры ИБ
То есть мы продвинулись дальше, но какая разница – перепрыгнул ты пропасть на четверть или наполовину? Как говорится, go fish.
Попытка 3. Очистка таблицы configsave средствами MS SQL
Примерно так:
DROP TABLE
CREATE TABLE ( (128) NOT NULL, NOT NULL, NOT NULL, NOT NULL, NOT NULL, NOT NULL)
INSERT INTO ConfigSave SELECT * FROM Config
Тоже помогло, Но с тем же эффектом, что и предыдущая попытка.
Попытка 4. Копирование разрушенных таблиц из работоспособной копии ИБ средствами MS SQL
Оценив количество модифицированных таблиц, мы прикинули сколько SELECT’ов придется написать… и решили, что несколько дней без базы компания не выдержит
Решение, которое помогло
1. Была восстановлена база из «слепка», снятого за два часа до разрушения таблиц.
2. Дальше немного магии: код на 1С, который помог восстановить данные, накопленные пользователями со времени снятия крайнего слепка.
3. Так как платформа в режиме COM-соединения гораздо легче и более прозрачно оперирует с СУБД, то система успешно стартует и дает выполнить запросы.
Итак, код решения, которое сработало:
Подключение
1. Из копии подключаемся к разрушенной рабочей базе через COM-соединение. В отличие от обычного подключения, сеанс стартует успешно
Перенос справочников 1С
2. Загружаем те справочники, которых еще нет в копии
Перенос документов 1С
3. Загружаем те документы, которых еще нет в копии
Проведение документов 1С
4. Чтобы восстановить движения, перепроводим проведенные документы, загруженные в копию
Выводы. Как избежать поломки структуры данных базы 1С?
Удалось ли нам спасти ту пятницу? И да, и нет.
У пользователей случился «сокращенный рабочий день» и тут, пожалуй, да – отдыхать полезно.
Большинство проектной команды получило свою порцию адреналина. И ушли с работы тоже вовремя.
Руководитель проекта и эксперт по технологическим вопросам крупных внедрений получили много интересной и поучительной работы на выходные 🙂
Успеху в этой ситуации способствовали регулярные бэкапы и быстрая диагностика. Бэкап облегчил восстановление. А диагностика «в восемь рук» позволила быстро найти тот вариант, который сработал. То ,что он оказался пятым по счету и его не было на Инфостарте, в школе или на форумах только подтверждает ценность проектного опыта команды.
Что делать в будущем во избежание подобных ситуаций? Всю округу соломкой не устелить, но вот чек-лист для критичных ситуаций.
• Диагностика
o Команде знать и уметь работать с:
— техническим журналом;
— подсистемой «Инструменты разработчика» (Сергей, привет и огромное спасибо за твой многолетний труд);
— Sql + инструменты администрирования субд;
— инструментом диагностики операционной системы и оборудования.
o Держать под рукой эти инструменты, желательно в виде коротких пошаговых инструкций и скриптов
• Лечение
— Будьте экспертом. Неважно в данном случае, лучший ты сыщик с дипломом или без диплома. Важен экспертный подход к решению задач
o Мыслить гибко
•Профилактика
— Бэкапы — регулярно
— Каждому знать, где лежат и как часто делаются
— Админам написать инструкции (а лучше скрипты) для оперативного восстановления.