Как правильно удалить базу 1С с сервера SQL

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

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

Операция требует прав администратора: в консоли кластера 1С нужны права администратора кластера, а на SQL Server — роль sysadmin или право DROP DATABASE на конкретную базу. Если у вас нет этих полномочий, не пытайтесь обойти ограничения — передайте задачу администратору сервера.

Подготовка: что проверить до удаления

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

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

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

Резервное копирование перед удалением

Даже если база признана ненужной, сделайте финальную резервную копию средствами SQL Server. Полная копия (FULL backup) занимает немного времени и позволяет восстановить базу в любой момент. Хранить такую копию разумно на отдельном диске или сетевом ресурсе, а не на том же томе, где лежали файлы базы.

Копию можно создать через SQL Server Management Studio: правый клик по базе — «Задачи» — «Создать резервную копию», тип «Полная». Либо выполните команду T-SQL. Важно дождаться завершения операции и увидеть сообщение об успешном создании копии.

BACKUP DATABASE [MyBase1C] TO DISK = N'D:\Backups\MyBase1C_final.bak' WITH FORMAT, COMPRESSION, CHECKSUM;

Критически важно не просто создать файл, а проверить его пригодность. Минимальная проверка — команда RESTORE VERIFYONLY, идеальная — тестовое восстановление на другом сервере или под другим именем базы. Файл бэкапа, который нельзя восстановить, не является резервной копией.

Завершение сеансов и блокировка базы

Удалить базу данных, к которой есть активные подключения, SQL Server не даст — команда DROP DATABASE завершится ошибкой, если с базой работают пользователи или висят фоновые соединения. Поэтому сначала отключите всех.

Откройте консоль администрирования серверов 1С, перейдите в свойства информационной базы и установите блокировку начала сеансов с сообщением пользователям. Затем на вкладке «Сеансы» завершите активные сеансы. Дождитесь, пока список сеансов по этой базе станет пустым — соединения с SQL Server могут закрываться с небольшой задержкой.

Дополнительно проверьте подключения на стороне SQL Server: в SSMS откройте «Монитор активности» или выполните запрос к sys.dm_exec_sessions с фильтром по имени базы. Оставшиеся процессы можно завершить командой KILL по номеру сессии, но делайте это осознанно — принудительное завершение обрывает незавершённые транзакции.

Удаление записи в консоли кластера 1С

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

Рекомендуемый порядок — выбрать «Оставить базу данных без изменений» (вариант может называться «Не удалять базу данных» в зависимости от версии платформы), а саму базу данных удалить отдельно через SSMS. Так вы контролируете каждый этап и можете проверить результат на каждом шаге. Вариант с удалением через консоль тоже рабочий, но при ошибке на стороне SQL вы получите менее информативное сообщение.

После удаления записи убедитесь, что база исчезла из списка информационных баз и из списков баз у пользователей. Если база добавлялась пользователям через общий список (файл ibases.v8i или публикация на веб-сервере), удалите её и оттуда.

Удаление базы данных на SQL Server

Откройте SQL Server Management Studio, подключитесь к нужному экземпляру, найдите базу в списке «Базы данных». Правый клик — «Удалить». В окне удаления отметьте опцию «Закрыть существующие соединения» (Close existing connections), если уверены, что все сеансы уже завершены, и подтвердите операцию.

Альтернатива — команда T-SQL. Сначала переведите базу в однопользовательский режим с откатом незавершённых транзакций, затем удалите её. Этот способ удобен для автоматизации и гарантированно сбрасывает оставшиеся подключения.

ALTER DATABASE [MyBase1C] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DROP DATABASE [MyBase1C];

После удаления проверьте файловую систему: файлы .mdf и .ldf должны быть удалены вместе с базой. Если файлы остались на диске (такое бывает при сбоях или если база была в состоянии OFFLINE), удалите их вручную, предварительно убедившись, что они относятся именно к удалённой базе — сверьтесь с записанными ранее путями.

Проверка результата и очистка хвостов

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

Отдельно проверьте план обслуживания SQL Server: если для базы существовали задачи резервного копирования, реиндексации или проверки целостности, удалите эти шаги, иначе задания начнут завершаться с ошибкой и засорять логи. То же относится к скриптам обслуживания, запускаемым через планировщик Windows или агент SQL Server.

Типичные ошибки и как их избежать

Самая частая ошибка — удаление базы данных на SQL Server до удаления записи в консоли кластера. В результате в списке баз остаётся «мёртвая» запись, при обращении к которой пользователи видят ошибку соединения. Обратный порядок тоже проблемен, если забыть про саму базу данных: она остаётся на диске и годами занимает десятки гигабайт.

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

Альтернативы полному удалению

Если база не нужна в ежедневной работе, но данные могут понадобиться, полное удаление — не единственный вариант. Можно перевести базу в режим OFFLINE или сделать её резервную копию, а саму базу удалить, храня только файл .bak. При необходимости база восстанавливается из копии за несколько минут.

Другой вариант — выгрузить базу в файл .dt через конфигуратор и хранить его в архиве. Такой файл компактнее и не привязан к версии SQL Server, хотя восстановление из него занимает больше времени и требует создания пустой базы. Выбор зависит от того, насколько вероятно обращение к архиву и какие ресурсы есть для хранения.

Частые вопросы