Как восстановить базу данных MSSQL без остановки сервера приложений 1С

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

В процессе администрирования систем на базе 1С:Предприятие часто возникает необходимость восстановить одну из информационных баз из резервной копии (файл .bak). Если на сервере крутится несколько рабочих баз, полная остановка службы 1C:Enterprise 8.3 Server Agent недопустима, так как это прервет работу всех пользователей. Однако при попытке восстановления через SQL Server Management Studio (SSMS) администраторы часто сталкиваются с ошибкой "Exclusive access could not be obtained because the database is in use". Это происходит потому, что сервер 1С постоянно держит открытые соединения (пул соединений) и запускает фоновые задания.

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

Способ 1: Блокировка сеансов и регламентных заданий через консоль 1С

Проанализируем ситуацию: основной источник "мешающих" соединений — это активные пользователи и планировщик регламентных заданий. Чтобы освободить базу, нам нужно запретить новые подключения и завершить старые. Разберем этот процесс по шагам:

  1. Откроем Консоль администрирования серверов 1С:Предприятия.
  2. Перейдем в ветку нужной информационной базы и откроем её Свойства.
  3. Установим галочку Блокировка установки соединений включена.
  4. В поле Код разрешения введем произвольную комбинацию (например, 123). Это позволит нам самим зайти в базу, если это потребуется, но отсечет остальных.
  5. Установим галочку Блокировка регламентных заданий включена.
  6. Нажмем "ОК". После этого новые сеансы создаваться не будут.
  7. Теперь перейдем в раздел Сеансы этой базы. Выделим все текущие сеансы (кроме своего, если он есть) и выберем пункт "Удалить".
  8. Важно также проверить раздел Соединения. Если там остались "фантомные" подключения от рабочих процессов rphost, их также следует завершить.

Примечание: После установки блокировки рекомендуется подождать 2–5 минут, чтобы сервер 1С успел корректно закрыть все транзакции на уровне SQL-сервера.

Способ 2: Принудительный разрыв соединений через T-SQL

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

Рассмотрим выполнение следующего скрипта в SSMS:


USE [master];
GO
-- Разрываем все активные соединения и переводим в SINGLE_USER
ALTER DATABASE [Имя_Вашей_Базы] 
SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO

-- Выполняем восстановление из файла
RESTORE DATABASE [Имя_Вашей_Базы] 
FROM DISK = N'C:\Backup\your_backup.bak' 
WITH REPLACE, 
MOVE 'Logical_Data_Name' TO 'C:\SQLData\Data.mdf', 
MOVE 'Logical_Log_Name' TO 'C:\SQLData\Log.ldf';
GO

-- Возвращаем базу в многопользовательский режим
ALTER DATABASE [Имя_Вашей_Базы] 
SET MULTI_USER;
GO

Использование команды SET SINGLE_USER WITH ROLLBACK IMMEDIATE гарантирует, что SQL Server мгновенно закроет все коннекты от rphost, позволяя процессу восстановления получить монопольный доступ.

Способ 3: Метод Side-by-Side (Восстановление в новую базу)

Если вы хотите минимизировать риск повреждения текущей конфигурации или избежать "зависаний" сервера 1С, проанализируем метод создания копии-дублера. Это самый безопасный способ для "горячего" восстановления.

  1. Восстановим бэкап в SQL-сервер под новым именем, например, Base_Restore_Temp.
  2. В консоли администрирования 1С зайдем в свойства существующей информационной базы.
  3. Изменим поле Имя базы данных (в блоке параметров СУБД) с Old_Base на Base_Restore_Temp.
  4. Нажмем "ОК".

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

Работа с серверным кешем после восстановления

Часто после успешного восстановления базы "поверх" старой, пользователи начинают получать ошибки Сеанс завершен администратором или сообщения о несоответствии структуры данных. Это происходит из-за того, что сервер 1С кэширует метаданные в файлах snccntx.

Выясним причину: сервер "думает", что работает со старой версией объектов, хотя в SQL таблицы уже изменились. Чтобы решить эту проблему без перезагрузки всего сервера, выполним следующие действия:

После включения базы в консоли 1С, сервер заново вычитает структуру данных и сформирует актуальный кеш, что устранит ошибки "фантомных" сеансов.

Автоматизация через утилиту RAC

Для продвинутых администраторов разберем способ автоматизации через Remote Administration Client (rac). Это позволяет исключить человеческий фактор при ручном кликанье в консоли. Мы можем создать скрипт, который будет выполнять последовательность действий:


-- Блокируем базу
rac session --cluster={ID} terminate --infobase={ID}
rac infobase --cluster={ID} update --infobase={ID} --sessions-deny=on --scheduled-jobs-deny=on --permission-code=123

-- (Здесь запускается SQL Restore)

-- Снимаем блокировку
rac infobase --cluster={ID} update --infobase={ID} --sessions-deny=off --scheduled-jobs-deny=off

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

Синхронизация учетных записей (Orphaned Users)

Проанализируем ситуацию, когда после восстановления 1С пишет "Ошибка аутентификации пользователя СУБД". Это может случиться, если база восстанавливалась из другого экземпляра SQL. Учетная запись внутри базы может потерять связь с логином сервера SQL. Чтобы это исправить, выполним команду:

ALTER USER [имя_пользователя_1с] WITH LOGIN = [имя_логина_sql];

Это восстановит связку, и сервер приложений 1С снова сможет авторизоваться в базе данных под своей технической учетной записью.

← На главную