Как правильно удалять базы 1С на SQL Server

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

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

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

Что проверить перед удалением базы

Прежде чем удалять базу, убедитесь, что она не используется. Откройте консоль управления сервером 1С (оснастка «Центральные серверы 1С:Предприятия») и посмотрите список сеансов для этой информационной базы. Активные сеансы означают, что кто-то работает прямо сейчас, и удаление оборвёт его работу с потерей несохранённых данных.

Также проверьте, не используется ли база в автоматических регламентных заданиях, обменах данными и интеграциях. База может выглядеть «пустой» по сеансам, но при этом быть источником или приёмником в обмене с другой системой. Удаление такой базы сломает обмен, и ошибка всплывёт только на стороне второй системы.

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

Резервное копирование: обязательный этап

Существует два независимых способа сохранить базу перед удалением, и лучше использовать оба. Первый — выгрузка в файл .dt через конфигуратор 1С («Администрирование» → «Выгрузить информационную базу»). Такой файл переносим между версиями платформы и даже между типами СУБД, но выгрузка требует монопольного доступа и может занять много времени на больших базах.

Второй способ — штатный бэкап средствами SQL Server: полная резервная копия (FULL backup) в файл .bak. Он создаётся быстро, не требует выгона пользователей и восстанавливается штатными средствами СУБД. Минус: восстановить такую копию можно только на SQL Server совместимой версии, а для загрузки в файловый вариант 1С она не подходит.

После создания копии проверьте её пригодность: для .bak выполните RESTORE VERIFYONLY или тестовое восстановление на отдельном сервере, для .dt убедитесь, что файл имеет адекватный размер и выгрузка завершилась без ошибок. Бэкап, который не проверен, нельзя считать существующим.

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

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

Перед удалением установите блокировку начала сеансов: в консоли кластера откройте свойства информационной базы и задайте блокировку с текущего момента, при необходимости с сообщением для пользователей. Это не даст никому войти в базу, пока вы выполняете операции. Альтернатива — параметр «Блокировка регламентных заданий», который отдельно останавливает фоновые задачи.

Затем завершите оставшиеся сеансы. В консоли кластера это делается через список сеансов конкретной базы — выделите все сеансы и удалите их. Учтите, что принудительное завершение обрывает работу пользователей без сохранения, поэтому предупредите их заранее.

Дополнительно проверьте соединения на стороне SQL Server. Даже после завершения сеансов 1С могут оставаться «спящие» соединения рабочих процессов кластера. Это не помешает удалению через SSMS с опцией закрытия подключений, но полезно знать, откуда берутся активные сессии в sp_who2.

Удаление регистрации базы в кластере 1С

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

В диалоге удаления доступны варианты: «Удалить базу данных» (база в СУБД будет уничтожена вместе с регистрацией), «Очистить базу данных» (структура останется, данные будут удалены) и «Оставить без изменений» (удаляется только регистрация, база в СУБД остаётся нетронутой). Если вы планируете удалять базу средствами SQL Server вручную и контролировать процесс, выбирайте «Оставить без изменений» — так вы разделите операции и сможете проверить каждую отдельно.

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

Через SQL Server Management Studio

Подключитесь к экземпляру SQL Server в SSMS под учётной записью с правами sysadmin или dbcreator. В обозревателе объектов найдите базу, щёлкните правой кнопкой и выберите «Удалить». В диалоге обязательно установите флажок «Закрыть существующие соединения» (Close existing connections) — иначе удаление завершится ошибкой, если к базе осталось хоть одно подключение.

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

Через T-SQL

Тот же результат достигается скриптом. Сначала база переводится в однопользовательский режим с немедленным откатом транзакций, затем удаляется:

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

Команда DROP DATABASE необратима. Перед выполнением перепроверьте имя базы в скрипте — типичная аварийная ситуация это удаление рабочей базы вместо тестовой из-за похожих имён вида Base и Base_copy. Хорошая практика — сначала выполнить SELECT name FROM sys.databases и сверить список.

1. 1
   Согласуйте удаление с владельцем данных и убедитесь, что база не участвует в обменах
2. 2
   Установите блокировку начала сеансов в консоли кластера и завершите активные сеансы
3. 3
   Сделайте выгрузку .dt и полный бэкап .bak, проверьте целостность копий
4. 4
   Удалите регистрацию информационной базы в консоли кластера (вариант «Оставить базу данных без изменений»)
5. 5
   Удалите базу в SSMS с опцией закрытия подключений или через DROP DATABASE
6. 6
   Проверьте, что файлы mdf/ldf удалены с диска и в списках баз пользователей не осталось записей

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

После удаления пройдитесь по контрольным точкам. В SSMS обновите список баз — удалённой базы быть не должно. На диске сервера проверьте каталог данных SQL Server: файлы с именем базы должны исчезнуть. Если остались — удалите их вручную, предварительно убедившись, что они не относятся к другой базе.

Проверьте планировщик заданий SQL Server (SQL Server Agent): задания бэкапа, обслуживания или реиндексации, настроенные под удалённую базу, начнут завершаться с ошибкой. Отключите или удалите их. То же касается планов обслуживания (Maintenance Plans) и внешних скриптов резервного копирования.

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

Типичные ошибки и ограничения

Самая частая ошибка — удаление базы только в одном месте. Если удалили регистрацию в кластере, но забыли про SQL Server, на диске годами лежат десятки гигабайт ненужных данных. Если удалили базу в SSMS, но не регистрацию — кластер 1С при обращении к записи выдаёт ошибку, а тестирование и исправление других баз может начать сообщать о проблемах связи.

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

Третья типичная ситуация — удаление базы, участвующей в распределённой системе (РИБ, обмены через EnterpriseData, веб-сервисы). Внешние системы продолжат обращаться к несуществующей базе и забьют журналы ошибками. Всегда сначала отключайте интеграции на стороне всех участников.

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