Итак возможности скрипта:
- Установка блокировки соединений с базой данных (приводит к автоматическому завершению работы пользователей в типовых конфигурациях, как это сделать не в типовых - допишу позже),
- Если в течении периода ожидания (настраивается, по умолчанию 10 мин.) сеансы не завершатся - скрипт принудительно завершит их,
- Если в течении периода ожидания (настраивается, по умолчанию 10 мин.) не завершатся все ragent, rmngr, rphost - они будут завершены принудительно,
- Старт агента сервера (с блокировкой соединений),
- Обновление конфигурации базы данных,
- Опциональная выгрузка базы данных,
- Опциональное тестирование и исправление - с тестированием логической целостности и пересчетом итогов,
- Разрешение работы пользователей,
- Сохранение произведенных действий в лог на диске и в журнале регистрации,
- Зачистка старых выгрузок (по умолчанию старше 7 дней)
- Копирование лога на сетевой ресурс.
Можно сделать автоматическую генерацию этого скрипта из 1С и автоматический его запуск по регламентному заданию 1С.
Обновлено:
Особенности скрипта - для подключения к базе применяется Windows аутентификация (ну не хранить же пароль в открытом виде). Выложил шаблон - в нем параметры которые чаще всего нужно изменять в начале файла и в квадратных скобках.
Запуск файла в рабочем варианте осуществляю в процедуре приемки сообщения от главного узла УРБД.
Если КонфигурацияИзменена() Тогда
Ком = Новый COMObject("WScript.Shell");
Ком.Run("""" + ПолныйПутьКФайлуСкрипта + """");
КонецЕсли;
27/05/10 - Добавлена обработка для формирования файлов регламентного обслуживания на одном из двух языков: PowerShell или VBScript
Добавил функцию ресайклинга rphost.
Преимущество такого ресайклинга перед типовым механизмом платформы - что он может выполнятся по расписанию а не через определенное время.
Отдельного признака в настройке нет - если стоит галочка перезапуск агента -
перезапускается агент, если галочка снята - выполняется ресайклинг.
Для ресайклинга необходимо минимум 2 rphost, минимум один включенный и минимум один выключенный.
04/06/10 - Как лучше запускать скрипты. Полное обслуживание понятно - назначить по графику регламентное задание. А вот время для сокращенного скрипта выбирается автоматом в процедуре приемки сообщения:
Попытка
ПланыОбмена.ПрочитатьИзменения(ЧтениеСообщения, СтруктураНастроекОбменаДанными.КоличествоЭлементовВТранзакцииНаЗагрузкуДанных);
ЧтениеСообщения.ЗакончитьЧтение();
ЧтениеXML.Закрыть();
Исключение
СообщитьИнформациюОбОшибкеОбмена("Ошибка при чтении изменений при обмене РИБ: " + ОписаниеОшибки(), СтруктураНастроекОбменаДанными, Истина, Ложь);
// ошибка может быть связана с тем, что изменилась конфигурация информационной базы
Если ПланыОбмена.ГлавныйУзел() <> Неопределено
И КонфигурацияИзменена() Тогда
Ком = Новый COMObject("WScript.Shell");
Ком.Run("""" + ПутьККаталогуСкриптов + "confup_hh.vbs" + """");
Конецесли;
Возврат;
КонецПопытки;
В типовых это: ПроцедурыОбменаДанными.ЗагрузитьCообщениеСИзменениямиОтРИБУзла
По количеству скачиваний вижу в основном скачивают образец vbs, но он не обновляется и не содержит последних исправлений и всех функций. Пользуйтесь обработкой для формирования файлов vbs/ps1.
08/12/10 - Добавил версию на 8.2. Простой конвертации версии под 8.1 недостаточно. В версии на 8.2 изменилась работа с соединениями, теперь вместо соединений мы имеем сессии, сессии могут не исчезать после рестарта, поэтому добавлено повторную попытку разрыва соединений после рестарта. Также постарался избавится от регистрозависимости имени базы.
20/12/10 - Исправлена ошибка в обработке когда из-за служебных соединений могли не происходить выгрузка или обновление конфигурации. В платформе 8.2 почему-то соединения COM-администрирования или консоли сервера стали мешать получению монопольного доступа к базе.
