для каких задач можно использовать утилиту восстановления файловой базы данных
Восстановление работоспособности файловой базы. 0. Введение
Этап 0. Введение в проблематику.
С упрямой периодичностью на форумах по 1С появляются крики души «Помогите! Упала файловая база, бэкапов нет, что делать?». Лично я всегда при этом вспоминаю известную шутку «Админы делятся на два типа — тех, кто делает бэкапы, и тех, кто будет их делать». Но, отбросив шутки в сторону, постараемся серьёзно рассмотреть данную проблему, ведь ситуации бывают разные. Например, бэкапы делались на диск, на котором закончилось место, или бэкапы делались через выгрузку, и все такие выгрузки за последнее время оказались неработоспособны. К слову сказать, даже админы, считающие себя «бывалыми», прокалываются на подобных мелочах.
В качестве разминки, позвольте изложить несколько советов по правильной организации бэкапов файловых баз данных, несоблюдение которых может сыграть злую шутку:
Первоначальные действия для диагностирования таких случаев должны быть такими:
Итак, Вы решили починить базу своими руками, и окунуться в самые дебри загадочного содержимого файла 1Cv8.1CD. Какие же полезные статьи и инструменты мы имеем на текущий день?
Хочу заметить, что в следующих статьях цикла будет предполагаться, что читатели ознакомились хотя бы поверхностно с перечисленными статьями и утилитами, и на этом этап введения предлагаю считать законченным. Прошу высказывать свои мнения, замечания и дополнения в комментариях.
В следующей статье рассмотрим подробно этап обследования сбойной базы и выявления проблемных мест.
Опыт по восстановлению файловой версии базы после неудачной реструктуризации таблиц
Вступление
При повторном запуске программа выдавала сообщение
и после этого вываливалась в Windows. Наличие резервной копии позволило бы восстановить базу в два счета, но человеческая беспечноть сотрудницы, которая не потратила лишних пару минут для ее создания привела к тому, что исправление проблемы заняло около четырех дней, было сделано несколько неправильных шагов, которые не приводили к значимому результату. Ниже я описываю правильный путь.
Восстановление базы
Поиск по интернету привел к страницам с описанием данных проблем без наличия решения, однако вскоре были найдены две важные ссылки, которые явились отправной точной в восстановлении:
Шаг №1. Делаем резервную копию испорченной базы
Шаг №2. Делаем выгрузку конфигурации при помощи утилиты Tool_1CD
Помимо просмотра списка таблиц, там есть важная для нас функция выгрузки конфигурации. Запускаем утилиту, открываем базу. База открылась без сообщений об ошибок, это хороший знак!
Шаг №3. Анализируем структуру файла испорченной базы
Все адреса хранятся в абсолютной адресации, что затрудняет исправление в ручном режиме, в случае если испортилась какая-то таблица не первая по списку. С другой стороны это упрощает программистам 1С работу и ускоряет процесс заргузки нужных таблиц в память.
Итак взглянем на таблицу из HEX редактора:
Важное замечание awa :
1С обращается к таблицам по имени, и ей не важно, какая таблица находится в списке первой, какая второй и т.д. Просто при создании новой базы 1С создает нужные таблицы друг за другом в том порядке, в каком это создание написали программисты 1С. Поэтому всегда и получается, что CONFIG идет первой, CONFIGSAVE второй и т.д. Но если бы первой таблицей была бы какая-нибудь _REFERENCE152, а CONFIG была бы семнадцатой в списке, 1С спокойно бы работала с такой базой.
Шаг №4а. Загружаем в пустую конфигурацию выгруженную конфигурацию (извините за каламбур)
Загрузили. Записали. Смотрим в HEX-редакторе
Так-с, что-то не то, какая-то новая таблица добавилась. Отсюда вывод: Восстановление нужно делать на том же релизе платформы, что и испорченная база.
Шаг №5б. Загружаем в пустую конфигурацию выгруженную конфигурацию той же самой версии платформы
Да-а, результат тоже не очень. Таблица CONFIG заканчивается по адресу 0x10FFF, судя по всему она не реструктуризирована. Ладно попробуем скопировать рабочую таблицу Tool_1CD в нерабочую базу. Выделяем блок в рабочей базе и копируем с замещением по адресу 0x5000 в испорченную базу:
Открываем Tool_1CD, открываем испорченную базу, но увы Tool_1CD виснет при попытке посмотреть таблицу CONFIG. После нескольких не правильных шагов, мне пришла идея: а что если 1С структурирует таблицы при загрузке базы? Тогда остается сделать выгрузку и загрузку базы с рабочей конфигурацией.
Шаг №5в. Загружаем в пустую конфигурацию выгруженную конфигурацию той же самой версии платформы, делаем выгрузку и загрузку базы (не конфигурации!).
Посмотрим как сейчас выглядят смещения:
Уже лучше. Теперь CONFIGSAVE расположена по адресу 0x31FC000, что больше чем 0x31F1000. Как же скопировать больший блок таблицы CONFIG в рабочей базе на меньший блок в испорченной базе? Ответ прост: надо удалить метаданные в рабочей конфигурации, не влияющие на ее структуру: общие модули, картинки, отчеты, обработки и т.п. Нам важно запустить испорченную базу, конфигурацию мы потом восстановим.
Шаг 6. Итерация по удалению метаданных конфигурации, не влияющие на ее структуру, выгрузка и загрузка базы.
После нескольких итераций удаления, выгрузки и загрузки базы, я получил следующую картину:
Наконец-то: CONFIGSAVE начинается с 0x313B0000 0x31F1000. Теперь выделяем блок 0x5000- x313AFFF в рабочей базе и в адрес 0x5000 в испорченной базы копируем с замещением
Записываем. Открываем 1С. Отклично, все заработало.
Важное замечание awa
Как правило по смещению 0x4000, содержатся ссылки на файлы описания таблиц. А уже в файлах описания таблиц содержатся ссылки на таблицы записей, индексов и BLOB. В общем случае, если таблица CONFIG «начинается» с адреса 0x5000, а таблица CONFIGSAVE с адреса 0x31f1000 и нет никакой гарантии, что на промежутке от 0x5000 до 0x31f1000 не содержится ни одного блока, относящегося к любой другой таблице, помимо CONFIG. В большинстве случаев таблица CONFIG не фрагментирована, объясняется это, думаю, тем, что такое расположение файлов одной таблицы друг за другом, так, что вся таблица как бы находится в файле 1CD одним непрерывным куском, образуется в результате применения сжатия базы данных при тестировании и исправлении или при применении утилиты chdbfl.exe.
Осталось только загрузить в базу рабочую конфигурацию, чтобы восстановить рабочую базу. Все, База восстановлена.
Опыт восстановления файловой базы данных 1с 8.2 после неудачного обновления конфигурации
Опыт восстановления файловой базы данных 1с 8.2 после неудачного обновления конфигурации.
Главной причиной возникновения проблемы стало зависшее приложение при обновлении конфигурации информационной базы (это следует из текста ошибки в журнале событий системы – «Зависшее приложение 1cv8.exe, версия 8.2.18.96, зависший модуль hungapp, версия 0.0.0.0, адрес 0x00000000.»), запущенное на Microsoft Windows XP SP3 при работе с файловым вариантом базы данных, расположенной на другой (весьма нагруженном) машине (далее «Сервер») находящейся в том же домене, но фактически расположенной в другом месте (связь с которой обеспечивается через оптоволоконную линию одного из интернет-провайдеров). В качестве сервера используется Microsoft Windows Server 2003R2 Enterprise x64 Edition SP2 на процессоре Intel Xeon с 24 Гб ОЗУ. При этом на стороне сервера в этом промежутке времени никаких записей об ошибках или предупреждений не в системном журнале, не в журнале приложений нету.
Второй причиной послужило нежелание автора статьи сделать выгрузку информационной базы перед выполнением обновления в виду небольшого объема внесенных изменений в структуру данных, малого объема хранимой в базе информации.
Позже (путем намеренного повторения изложенных выше действий) удалось установить, что данная проблема возникает только при обновлении структуры таблиц (добавление/удаление новых структур данных), при обновлении только модулей, форм, отчетов и т.д. данной проблемы не возникает. Дополнительно данная ситуация сопровождается системным сообщением (рис.1).
После повреждения файла базы платформа перестала запускаться как в режиме предприятия так и в режиме конфигуратора. При этом выдавала ошибку о разрушении структуры базы данных (SDBL).
Первым шагом попытался восстановить работоспособность штатными средствами (утилита chdbfl.exe от «1С», расположенной в каталоге платформы), но данная утилита выдавала ошибку «неожиданного прерывания выполнения» с длинным текстом из которой следовало, что в структуре таблиц найдена таблица с повторяющимся именем. Как позже выяснилось – их было несколько. Данные таблицы были индексами к данным, структура которых должна была быть изменена (или уже была изменена). Трудно судить об этом.
Интерфейс (а это уже хорошо) у выбранной утилиты достаточно лаконичен и интуитивно понятен. Сообщения очень информативны, что помогает в работе.
Так же при тестировании формата потока данной утилитой выяснилось, что многие записи из таблицы «CONFIG» не соответствуют заявленному размеру. Это были записи со значениями поля «FILENAME», уже присутствующими в таблице и постфиксом «.new» (например «ffbed849-c70b-423a-80bc-aef8c9f22a75» и «ffbed849-c70b-423a-80bc-aef8c9f22a75.new»), что тоже косвенно указывало на некорректное обновление.
Первым шагом стал поиск последнего архива с базой (благо до этого данная конфигурация не изменялась ни разу в силу ряда причину)!
Важно брать именно вариант с абсолютно той же конфигурацией, т.к. если была произведена реструктуризация таблиц, то придется очень долго сопоставлять загруженную рабочую конфигурацию с наименованиями имеющихся таблиц и полей в них.
Таблицу «DBSHEMAOG» я удалил, а из последнего идентичного варианта конфигурации взял таблицы: «DBSHEMA», «CONFIG», «CONFIGSAVE» (проще было взять пустую, чем удалять записи из текущей), «FILES», «IBVERSION», «PARAMS». Далее удалил по одной из таблиц с повторяющимися именами, о которых писал выше.
После этого запустил утилиту chdbfl.exe, которая написала что некоторые индексы рассогласованы с таблицами данных. Потом включил исправление и запустил еще раз. Ответом было, что ошибки исправлены.
Запустил платформу в режиме конфигуратора, сразу открылась конфигурация. Далее сделал «Тестирование и исправление» в режиме «Только тестирование». Тестирование прерывалось почти сразу с ошибкой «Таблица _DocumentJournalXXXXX не обнаружена» (название одной из таблиц индексов). Из чего делаем вывод, что утилита chdbfl.exe просто удалила таблицы индексов, которые были рассогласованы.
Так как при обновлении конфигурации новых документов, справочников и т.д. не добавлял (только реквизиты), взял эти индексы из старой базы которую использовал в качестве источника конфигурации.
Запустил платформу в режиме конфигуратора, запустил «Тестирование и исправление» в режиме «Только тестирование». Тестирование прошло до конца, было только много информационных сообщений о том, что нет данных в таблица индексов по разным элементам справочников и документам (индексы старые). Запустил тестирование еще раз только уже в режиме «Тестирование и исправление» со всеми включенными флагами (переключатели для несуществующих объектов оставил в положении «Не изменять», т.к. при проверке chdbfl.exe ошибок о потере данных не было). Тест прошел полностью, получил сообщение что тестирование завершено.
Запустил базу в режиме предприятия. Все последние документы
Удачи всем, кто оказался в той же ситуации!
Восстановление файлов и файловых групп (SQL Server)
В этом разделе описывается восстановление файлов и файловых групп в SQL Server с помощью среды SQL Server Management Studio или Transact-SQL.
В этом разделе
Перед началом работы
Восстановление файлов и файловых групп с помощью следующих средств
Перед началом
Ограничения
Системный администратор, восстанавливающий файлы и файловые группы, должен быть единственным лицом, использующим восстанавливаемую базу данных в данный момент.
Инструкция RESTORE недопустима в явной или неявной транзакции.
При использовании простой модели восстановления файл должен принадлежать к файловой группе, находящейся в режиме только для чтения.
Перед началом восстановления файлов по модели полного восстановления или модели восстановления с неполным протоколированием необходимо выполнить резервное копирование активного журнала транзакций (который называется заключительным фрагментом журнала). Дополнительные сведения см. в статье Создание резервной копии журнала транзакций (SQL Server)).
Чтобы восстановить зашифрованную базу данных, необходимо иметь доступ к сертификату или асимметричному ключу, который использовался для шифрования базы данных. Без сертификата или асимметричного ключа восстановить базу данных нельзя. Поэтому сертификат, используемый для шифрования ключа шифрования базы данных, должен храниться в течение всего времени, пока есть необходимость в резервной копии. Дополнительные сведения см. в статье SQL Server Certificates and Asymmetric Keys.
безопасность
Permissions
Разрешения на выполнение инструкции RESTORE даются ролям, в которых данные о членстве всегда доступны серверу. Так как членство в предопределенной роли базы данных может быть проверено только тогда, когда база данных доступна и не повреждена, что не всегда имеет место при выполнении инструкции RESTORE, члены предопределенной роли базы данных db_owner не имеют разрешений RESTORE.
Использование среды SQL Server Management Studio
Восстановление файлов и файловых групп
После подключения к соответствующему экземпляру компонента Компонент SQL Server Database Engineв обозревателе объектов разверните дерево сервера, щелкнув имя сервера.
Разверните узел Базы данных. В зависимости от типа восстанавливаемой базы данных выберите пользовательскую базу данных или раскройте узел Системные базы данных и выберите системную базу данных.
Щелкните правой кнопкой мыши базу данных, укажите на пункт Задачи и щелкните Восстановить.
На странице Общие в списке В базу данных введите имя восстанавливаемой базы данных. Можно ввести новую базу данных или выбрать уже существующую из раскрывающегося списка. Список включает все базы данных на сервере кроме системных баз данных master и tempdb.
Чтобы указать источник и расположение восстанавливаемых резервных наборов данных, выберите один из следующих вариантов.
Из базы данных
С устройства
В сетке Выберите резервные наборы данных для восстановления выберите нужные резервные наборы. В этой сетке отображаются резервные копии, доступные в указанном месте. По умолчанию предлагается план восстановления. Чтобы переопределить предложенный план восстановления, можно изменить выбранные элементы в сетке. Если выбор каких-то резервных копий отменяется, то автоматически отменяется и выбор зависящих от них резервных копий.
Для просмотра или выбора дополнительных параметров нажмите кнопку Параметры на панели Выбор страницы.
На панели Параметры восстановления можно выбрать любой из следующих параметров, если он подходит к данной ситуации.
Восстановление файловой группы
Указывает, что восстанавливается вся файловая группа.
Перезаписать существующую базу данных
Указывает, что операция восстановления должна переписать все существующие базы данных и связанные с ними файлы, даже если база данных или файл с указанным именем уже существуют.
Выдавать приглашение перед восстановлением каждой резервной копии
Запрашивает подтверждение перед восстановлением из копии каждого резервного набора данных.
Этот параметр особенно полезен, когда для использования различных наборов носителей необходимо менять ленты (например, если на сервере существует одно ленточное устройство).
Ограничить доступ к восстановленной базе данных
Доступ к восстановленной базе данных будет только у пользователей db_owner, dbcreator или sysadmin.
В качестве значения параметра Состояние восстановления укажите состояние базы данных после операции восстановления.
Если выбран этот параметр, то параметр Сохранить настройки репликации недоступен.
При выборе этого параметра необходимо указать резервный файл.
Использование Transact-SQL
Восстановление файлов и файловых групп
Выполните инструкцию RESTORE DATABASE для восстановления резервной копии файлов и файловых групп, указав следующее:
Имя базы данных для восстановления.
Устройство резервного копирования, откуда будет восстановлена полная резервная копия.
предложение FILE для каждого восстанавливаемого файла;
предложение FILEGROUP для каждой восстанавливаемой файловой группы;
Предложение NORECOVERY. (если файлы не изменялись со времени создания резервной копии, укажите предложение RECOVERY).
Если файлы были изменены после создания резервной копии, выполните инструкцию RESTORE LOG для применения резервной копии журнала транзакций, указав следующее:
Имя базы данных, к которой будет применен журнал транзакций.
Устройство резервного копирования, с которого будет восстановлена резервная копия журнала транзакций.
Предложение NORECOVERY, если существует другая резервная копия журналов транзакций для применения после текущего; в противном случае укажите предложение RECOVERY.
В случае применения резервных копий журналов транзакций они должны охватывать время резервного копирования файлов и их групп вплоть до конца журналов (если только не восстанавливаются ВСЕ файлы базы данных).
Примеры (Transact-SQL)
Для каких задач можно использовать утилиту восстановления файловой базы данных
Запускаем утилиту вручную
1. Для начала сделайте резервную копию имеющейся базы. Дело в том, что тестирование и исправление это необратимые операции над базой данных, которые почти всегда делают ситуацию лучше, но в очень небольшом проценте случаев могут все испортить. Вот на этот самый редкий случай мы и должны сначала сделать резервную копию.
2. Зайдите в папку, в которую у вас установлена 1С. Обычно это ‘C:\Program Files\1cv8’. Здесь вы увидите папки в названии которых присутствуют цифры, обозначающие номера версий платформы. Выберите папку с самой старшей версией (в нашем случае 8.3.4.304):
3. Внутри этой папки вы найдете папку bin:
4. Зайдите в эту папку. Там много файлов. Найдите файл с названием chdbfl:
5. Запустите этот файл и перед вами откроется утилита для проверки физической целостности файла базы данных. Укажите имя файла базы данных, нажав кнопку с тремя точками:
6. Чтобы указать это имя зайдите внутрь папки той базы, которая не запускается и выберите там файл ‘1Cv8’:
7. Поставьте галку ‘Исправлять обнаруженные ошибки’. Бояться нечего, ведь у нас есть резервная копия. И нажмите кнопку ‘Выполнить’:
Запускаем утилиту через обновлятор
Для пользователей моего Обновлятора всё ещё проще.
Отметьте нужную базу в списке, а затем из пункта «Ещё» выберите пункт «6.16 Проверка физической целостности файла БД (chdbfl.exe)»:
При этом обновлятор:
С уважением, Владимир Милькин (преподаватель школы 1С программистов и разработчик обновлятора).
Подписывайтесь и получайте новые статьи и обработки на почту (не чаще 1 раза в неделю). |
Вступайте в мою группу ВКонтакте, Одноклассниках, Facebook или Google+ — самые последние обработки, исправления ошибок в 1С, всё выкладываю там в первую очередь.
Как помочь сайту: расскажите (кнопки поделиться ниже) о нём своим друзьям и коллегам. Сделайте это один раз и вы внесете существенный вклад в развитие сайта. На сайте нет рекламы, но чем больше людей им пользуются, тем больше сил у меня для его поддержки.
Нажмите одну из кнопок, чтобы поделиться: