Что делать, если сервер 1С:Предприятие не видит базу данных после восстановления файлов MDF и LDF в SQL?

Системный администратор 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

При аварийных сбоях операционной системы, выходе из строя серверного оборудования или случайном повреждении системных разделов администраторы часто сталкиваются с необходимостью экстренного восстановления работоспособности баз данных «1С:Предприятие». Одним из наиболее распространенных способов спасения информации является копирование физических файлов базы данных MS SQL Server — файлов данных с расширением .mdf и файлов журнала транзакций с расширением .ldf. Однако после успешного прикрепления этих файлов к СУБД администраторы нередко обнаруживают, что сервер приложений 1С упорно отказывается «видеть» базу, выдавая ошибку о том, что база данных не обнаружена.

В этой статье мы подробно проанализируем причины этой проблемы, разберем архитектурные различия между базой данных в СУБД и информационной базой в кластере 1С, а также пошагово восстановим работоспособность всей системы, исключая типичные ошибки администрирования.

Различие понятий: база данных в SQL и информационная база в 1С

Для начала проанализируем ключевое недоразумение, с которым часто сталкиваются начинающие специалисты. База данных в системе управления базами данных (СУБД) MS SQL Server и информационная база в кластере 1С:Предприятие — это два абсолютно разных объекта, хоть они и тесно связаны между собой.

База данных SQL представляет собой набор физических файлов на диске (.mdf и .ldf), в которых хранятся таблицы, индексы, хранимые процедуры и сами данные. СУБД управляет доступом к этим файлам, обеспечивает транзакционность и целостность данных.

Информационная база 1С в кластере — это логическое описание подключения, которое хранится в служебных файлах сервера 1С (в файле конфигурации кластера 1CV8Reg.lst). Сервер приложений 1С выступает посредником между клиентом (пользователем) и базой данных SQL. Когда пользователь запускает 1С, клиентское приложение обращается к кластеру серверов 1С, тот считывает параметры подключения к SQL-серверу из своего реестра, авторизуется в СУБД под технической учетной записью и начинает транслировать запросы платформы в SQL-команды.

Если вы просто скопировали файлы .mdf и .ldf и прикрепили их к MS SQL Server через процедуру Attach (Присоединить), кластер серверов 1С ничего об этом не узнает. Для него этой базы просто не существует в его внутреннем реестре. Поэтому при попытке запустить клиентское приложение вы увидите сообщение о том, что информационная база не найдена. Нам потребуется явно связать эти две сущности.

Шаг 1. Восстановление и корректное прикрепление базы в MS SQL Server

Давайте разберем по шагам, как правильно перенести и прикрепить файлы базы данных на новом или восстановленном сервере СУБД. Прежде всего, необходимо скопировать файлы .mdf и .ldf в целевой каталог на сервере СУБД. Лучше всего использовать стандартную директорию хранения данных SQL Server, так как на нее уже настроены все необходимые права доступа операционной системы.

После копирования файлов откройте среду администрирования SQL Server Management Studio (SSMS), подключитесь к вашему серверу СУБД, нажмите правой кнопкой мыши на раздел Databases (Базы данных) и выберите пункт Attach (Присоединить). В появившемся окне нажмите кнопку Add (Добавить) и укажите путь к вашему файлу .mdf.

Иногда при аварийном завершении работы операционной системы файл журнала транзакций .ldf оказывается поврежден или утерян. Если вы попытаетесь подключить базу стандартным способом при поврежденном файле .ldf, MS SQL Server выдаст ошибку и прервет операцию. Выясним, как поступить в такой ситуации. Мы можем прикрепить базу данных, имея на руках только исправный файл .mdf. Для этого в окне Attach Databases в нижней табличной части выделите строку с файлом журнала транзакций .ldf (обычно он будет помечен предупреждением о ненайденном файле) и нажмите кнопку Remove (Удалить). После подтверждения операции СУБД автоматически перестроит структуру и создаст абсолютно новый, чистый файл журнала транзакций.

Также эту операцию можно выполнить с помощью выполнения T-SQL запроса в окне New Query. Рассмотрим пример такого запроса:


CREATE DATABASE [MyDatabase] 
ON (FILENAME = 'C:\SQLData\MyDatabase.mdf') 
FOR ATTACH_REBUILD_LOG;

Этот способ гарантирует создание работоспособной структуры базы даже при полном отсутствии оригинального лога транзакций.

Шаг 2. Разрешение проблем с правами доступа и выбор режима авторизации

После успешного прикрепления базы данных в SSMS очень важно настроить безопасность доступа. По умолчанию служба «Агент сервера 1С:Предприятие» работает под локальной системной учетной записью Windows, которая обычно называется USR1CV8 (или USR1CV82, USR1CV83 в зависимости от версии платформы). Если у этой учетной записи нет прав доступа к каталогу с физическими файлами базы данных или нет прав внутри самой СУБД SQL Server, то сервер приложений 1С не сможет подключиться к базе данных.

Рассмотрим два варианта решения этой проблемы:

Вариант 1. Использование Windows-авторизации (авторизация операционной системы). Если вы решили использовать этот метод, вам потребуется выполнить следующие действия:

  1. Откройте свойства папки, в которой лежат файлы .mdf и .ldf вашей базы данных. Перейдите на вкладку «Безопасность» и добавьте пользователя USR1CV8 (или ту учетную запись, под которой запущена служба сервера 1С). Предоставьте этому пользователю права «Полный доступ».
  2. Запустите SSMS, перейдите в раздел Security (Безопасность) -> Logins (Имена входа). Добавьте учетную запись \USR1CV8 вашего сервера в список разрешенных пользователей СУБД. В свойствах этого пользователя на вкладке User Mapping (Сопоставление пользователей) установите флажок напротив вашей базы данных и назначьте роль db_owner (владелец базы данных).

Вариант 2. Использование смешанной авторизации (SQL Server Authentication) — рекомендуемая практика. Практика показывает, что настройка прав для системных учетных записей Windows часто вызывает сложности при обновлении платформы, смене доменной структуры или переносе серверов. Намного надежнее и проще использовать смешанный режим авторизации SQL Server. Проанализируем алгоритм настройки смешанного режима:

  1. В SSMS нажмите правой кнопкой мыши на имя вашего сервера, выберите Properties (Свойства), перейдите в раздел Security (Безопасность) и установите переключатель Server authentication в положение SQL Server and Windows Authentication mode (Смешанный режим). После этого перезапустите службу SQL Server.
  2. Перейдите в раздел Security -> Logins, нажмите правой кнопкой мыши и выберите New Login (Создать имя входа).
  3. Задайте имя пользователя (например, db_1c_user) и выберите тип проверки подлинности SQL Server authentication. Укажите надежный пароль и снимите галочку «Enforce password expiration» (Требовать смену пароля при следующем входе), чтобы избежать внезапной блокировки работы пользователей.
  4. На вкладке User Mapping выберите вашу базу данных 1С и в нижней части окна отметьте для нее роль db_owner. Нажмите ОК.

Использование выделенного SQL-пользователя полностью изолирует права службы 1С от операционной системы и позволяет безболезненно переносить базу на любые другие серверы СУБД.

Шаг 3. Регистрация информационной базы в консоли администрирования 1С

Теперь, когда база данных подготовлена в MS SQL Server и для нее настроены учетные данные, перейдем к финальному этапу — связыванию базы с сервером приложений 1С:Предприятия.

Запустите утилиту «Администрирование серверов 1С:Предприятие». Разверните дерево вашего кластера, нажмите правой кнопкой мыши на раздел Информационные базы и выберите пункт Создать -> Информационная база. Заполните открывшуюся форму следующими параметрами:

После заполнения всех полей нажмите кнопку «ОК». Процесс подключения может занять от нескольких секунд до пары минут, пока сервер 1С проверяет соединение и считывает конфигурацию таблиц СУБД. После успешного завершения база появится в списке консоли 1С, и вы сможете добавить ее в список баз на компьютерах пользователей, указав адрес сервера приложений 1С и имя информационной базы.

Шаг 4. Решение сопутствующих проблем и аварийных ситуаций

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

1. База перешла в состояние SUSPECT или RECOVERY PENDING. Если при аварийном завершении работы ОС структура базы была нарушена, при прикреплении в SSMS она может отображаться серым цветом с пометкой SUSPECT. Обычный перевод базы в режим онлайн не решит проблему. В этом случае базу необходимо принудительно восстановить с помощью выполнения пакета T-SQL команд. Выполните следующий скрипт в SSMS:


ALTER DATABASE [MyDatabase] SET EMERGENCY;
ALTER DATABASE [MyDatabase] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DBCC CHECKDB ('MyDatabase', REPAIR_ALLOW_DATA_LOSS);
ALTER DATABASE [MyDatabase] SET MULTI_USER;
ALTER DATABASE [MyDatabase] SET ONLINE;

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

2. Проблема несоответствия кодировки (Collation/Сортировка). При восстановлении файлов на новый SQL-сервер вы можете столкнуться с ошибками несопоставимости кодировок при проведении документов или выполнении сложных запросов 1С. Для корректной работы баз 1С системная кодировка сервера MS SQL и параметры сортировки базы данных должны строго соответствовать стандартам платформы. Рекомендуемая сортировка для кириллических баз данных — Cyrillic_General_100_CI_AS или Cyrillic_General_CI_AS. Если на новом SQL-сервере по умолчанию установлена латинская кодировка (например, Latin1_General), то при попытке работы с временными таблицами 1С будет выдавать критические ошибки СУБД из-за конфликта кодировок основной базы и системной базы tempdb.

3. Необходимость очистки кэша сервера 1С. Даже после успешного выполнения всех процедур при подключении базы пользователи могут продолжать получать ошибки вроде «База данных не обнаружена» или «Ошибка формата потока». Это связано с тем, что кэш сервера приложений 1С хранит старые уникальные идентификаторы (UID) метаданных базы данных.

Чтобы исправить это, выполните очистку серверного кэша:

  1. Остановите службу «Агент сервера 1С:Предприятие» через консоль управления службами Windows (services.msc).
  2. Перейдите в каталог служебных файлов сервера по умолчанию: C:\Program Files\1cv8\srvinfo\reg_1541\
  3. Найдите и удалите все папки с длинными буквенно-цифровыми именами (UID-идентификаторами баз), например, 1467a14e-e11b-4171-8b21-4f7f6f91f7a0. При этом категорически запрещено удалять или изменять файл описания баз 1CV8Reg.lst, так как в нем прописаны настройки регистрации всех баз кластера.
  4. Запустите службу «Агент сервера 1С:Предприятие» заново.

Следуя этим подробным инструкциям, вы сможете успешно восстановить доступ к базам данных «1С:Предприятие» даже после самых серьезных сбоев операционной системы.

← На главную