При обслуживании информационных баз 1С:Предприятия часто возникает необходимость выполнять резервное копирование в формате .dt, а также управлять активными пользовательскими сеансами. Эти задачи особенно актуальны, когда требуется минимизировать время простоя системы или автоматизировать рутинные операции. Рассмотрим подробнее, как мы можем решить эти проблемы, используя различные подходы и инструменты.
Один из первостепенных вопросов, с которым сталкиваются системные администраторы и разработчики, заключается в возможности выгрузки информационной базы (ИБ) 1С в файл формата .dt без принудительного завершения всех активных пользовательских сеансов. Давайте проанализируем поведение утилиты ibcmd.exe infobase dump в этом контексте.
Утилита ibcmd.exe infobase dump является мощным инструментом для управления информационными базами 1С из командной строки. Ее синтаксис, как мы видим из исходного сообщения, позволяет указать все необходимые параметры для подключения и выгрузки:
С:\1CServers\8.3\8.3.22.1672\bin\ibcmd.exe infobase dump --db-server=%$DBServer% --dbms=MSSQLServer --db-user=%$DBUser% --db-pwd=%$DBPassw% --db-name=%$BaseName% --user=%$1CUser% --password=%$1CPassw% --data=%$DataPath% %$BackUpPath%%$FileName%
Для клиент-серверных информационных баз (MS SQL, PostgreSQL и др.):
Важно понимать, что утилита ibcmd.exe infobase dump, когда она работает с базами данных, расположенными на сервере (например, MS SQL Server или PostgreSQL), способна выгружать информационную базу в формат .dt даже при наличии активных пользовательских сеансов. Это одно из ключевых преимуществ использования серверного варианта 1С:Предприятия и соответствующего инструментария. Такой подход позволяет выполнять резервное копирование без полного отключения пользователей от системы, что крайне важно для компаний с круглосуточным режимом работы или высоким требованием к доступности.
Однако, несмотря на такую возможность, для обеспечения максимальной целостности и согласованности данных при выгрузке, мы всегда рекомендуем минимизировать или полностью исключить взаимодействие пользователей с базой данных на время выполнения операции. Если же это невозможно, то следует быть готовым к тому, что выгруженные данные могут не отражать самые последние несохраненные изменения, которые пользователи могли бы внести в момент выгрузки.
Для файловых информационных баз:
Ситуация меняется, если речь идет о файловой информационной базе. Для гарантированной целостности данных при выгрузке файловой ИБ, как правило, требуется монопольный режим. Это означает, что не должно быть активных пользовательских сеансов в момент выполнения операции выгрузки. Если пользователи присутствуют, мы рискуем получить некорректный или поврежденный файл .dt.
Автор вопроса справедливо отмечает, что запуск 1cv8.exe с параметром /C ЗавершитьРаботуПользователей для 14 баз одновременно может создавать значительную нагрузку и занимать много времени. Давайте рассмотрим альтернативные методы завершения сеансов, которые могут быть более эффективными для автоматизации и массового управления.
RAC – это консоль администрирования кластера серверов 1С:Предприятия. Она предоставляет широкие возможности для управления кластерами, рабочими серверами, информационными базами и сеансами. С ее помощью мы можем программно завершать сеансы.
Для завершения сеансов (включая спящие сеансы) через командную строку с помощью утилиты rac мы можем использовать следующую команду:
rac session terminate --cluster=<cluster_id> --session=<session_id>
Прежде чем использовать эту команду, нам необходимо получить список активных сеансов и их идентификаторы. Это можно сделать с помощью команды rac session list:
rac session list --cluster=<cluster_id>
Данный подход является наиболее "штатным" и контролируемым для клиент-серверных баз, поскольку он взаимодействует непосредственно с кластером серверов 1С. Однако, как было отмечено в сообщении (1), это не всегда укладывается в "одну строчку", так как требует предварительного получения cluster_id и session_id, что подразумевает создание скрипта.
Утилита ibcmd.exe, помимо функций дампа базы, также имеет функционал для управления сеансами. Мы можем рассмотреть использование ее методов, таких как SessionCommandBuilder session(), для выполнения операций с сеансами. Точный синтаксис и возможности зависят от версии платформы 1С:Предприятие, но этот инструмент предоставляет более интегрированный способ управления базой, чем низкоуровневые системные утилиты.
PowerShell является мощным инструментом для автоматизации задач в операционной системе Windows. Мы можем использовать его для управления сеансами, особенно если пользователи работают через удаленные рабочие столы (RDP).
Для получения списка активных RDP-сеансов:
Get-RDUserSession
Для завершения конкретного RDP-сеанса (принудительный выход пользователя):
Invoke-RDUserLogoff -UnifiedSessionID <ID_сеанса> -HostServer <Имя_сервера_терминалов>
Также мы можем использовать встроенные утилиты Windows query session и logoff:
Получение списка сеансов:
query session
Завершение сеанса по ID:
logoff <ID>
или более принудительно:
reset session <ID>
Эти команды завершат весь пользовательский сеанс Windows, что приведет к закрытию всех запущенных в нем приложений, включая 1С.
taskkill для принудительного завершения процессов 1cv8.exe (для тонкого/толстого клиента) или rphost.exe (для рабочих процессов сервера 1С).
Пример использования taskkill:
taskkill /IM 1cv8.exe /F
taskkill /IM rphost.exe /F
Мы настоятельно предостерегаем от использования taskkill для принудительного завершения сеансов пользователей, которые активно работают с информационной базой. Это может привести к потере несохраненных данных, повреждению индексов базы данных или другим проблемам с целостностью данных.
В типовых конфигурациях 1С:Предприятия предусмотрена функция блокировки работы пользователей через интерфейс. Обычно ее можно найти в разделе "Администрирование" → "Обслуживание" → "Блокировка работы пользователей". Эта функция позволяет нам установить время начала и окончания блокировки, а также сообщение для пользователей. После установки блокировки все активные сеансы будут завершены, а новые пользователи не смогут войти в систему до истечения срока блокировки. Этот метод является наиболее "дружелюбным" по отношению к пользователям, так как предусматривает их оповещение.
Сообщение (8) предлагает элегантное и надежное решение для получения целостного файла .dt, которое минимизирует риски и нагрузку на рабочую базу. Этот подход комбинирует преимущества резервного копирования средствами СУБД и выгрузки в .dt.
Почему SQL-бэкапы важны?
Для клиент-серверных баз мы всегда рекомендуем использовать средства резервного копирования самой СУБД (например, MS SQL Server Management Studio для MS SQL Server). Это позволяет выполнять резервное копирование без необходимости переключения базы в монопольный режим, обеспечивая максимальную доступность для пользователей. Бэкапы средствами СУБД часто выполняются быстрее и позволяют восстановить базу даже при наличии определенных ошибок в ней, которые могли бы помешать выгрузке в .dt.
Однако, как справедливо замечено в сообщении (7), иногда нужен именно файл .dt для быстрого развертывания на локальной машине или в другой конфигурации.
Это первый и самый важный шаг. Мы используем встроенные возможности нашей СУБД (например, MS SQL Server) для создания полного бэкапа рабочей информационной базы. Эта операция обычно выполняется быстро и не требует остановки работы пользователей. Созданный файл .bak (для SQL Server) или аналогичный файл для другой СУБД будет являться нашей точкой восстановления.
-- Пример SQL команды для создания бэкапа (для MS SQL Server)
BACKUP DATABASE [ИмяБазы] TO DISK = N'C:\Backup\ИмяБазы.bak' WITH NOFORMAT, NOINIT, NAME = N'ИмяБазы-Полное резервное копирование', SKIP, NOREWIND, NOUNLOAD, STATS = 10
GO
На следующем шаге мы восстанавливаем созданный SQL-бэкап в новую, временную базу данных на том же или другом сервере SQL. Эту копию базы мы будем использовать исключительно для выгрузки .dt. Критически важно, что в этой копии базы никто из пользователей не работает. Мы можем также отключить в ней все регламентные и фоновые задания сразу после восстановления, чтобы они не мешали и не создавали дополнительную нагрузку.
-- Пример SQL команды для восстановления бэкапа (для MS SQL Server)
RESTORE DATABASE [ИмяКопииБазы] FROM DISK = N'C:\Backup\ИмяБазы.bak' WITH FILE = 1, MOVE N'ИмяЛогическогоФайлаДанных' TO N'C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\ИмяКопииБазы.mdf', MOVE N'ИмяЛогическогоФайлаЛога' TO N'C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\ИмяКопииБазы_log.ldf', NOUNLOAD, REPLACE, STATS = 5
GO
Теперь, когда у нас есть копия базы, в которой гарантированно нет активных пользователей и фоновых процессов, мы можем безопасно выгрузить ее в формат .dt. Для этого мы используем ту же утилиту ibcmd.exe infobase dump, но указываем параметры подключения к нашей временной базе-копии:
С:\1CServers\8.3\8.3.22.1672\bin\ibcmd.exe infobase dump --db-server=%$DBServer% --dbms=MSSQLServer --db-user=%$DBUser% --db-pwd=%$DBPassw% --db-name=%$NameOfCopyBase% --user=%$1CUser% --password=%$1CPassw% --data=%$DataPath% %$BackUpPath%%$FileName%
Этот подход обеспечивает нам идеальный .dt файл: он будет целостным, согласованным и полученным без какого-либо влияния на работу основной информационной базы.
При реализации любых стратегий резервного копирования и управления сеансами мы должны учитывать следующие аспекты:
.dt: После выгрузки .dt файла мы рекомендуем периодически проверять его целостность, загружая его в тестовую базу. Это убедит нас в работоспособности резервной копии и возможности ее восстановления в случае необходимости..dt) мы можем использовать планировщик задач Windows, скрипты на PowerShell или командные файлы (батники). В скриптах мы можем комбинировать команды для завершения сеансов и выгрузки базы.Таким образом, комбинируя различные подходы и инструменты, мы можем эффективно управлять резервным копированием и сеансами пользователей 1С, обеспечивая стабильность работы системы и надежность хранения данных.