# Microsoft Windows Server # Создание и использование gMSA для запуска сервера 1С ### Введение Group Managed Service Account (gMSA) — это специальный тип сервисной учетной записи в Active Directory, который позволяет автоматически управлять паролем и использовать её для запуска служб без необходимости вручную вводить и обновлять пароль. Данная статья описывает процесс создания и настройки gMSA для запуска сервера 1С. --- ### Шаг 1. Создание корневого ключа KDS на контроллере домена На контроллере домена создаём корневой ключ службы распространения ключей (Key Distribution Service, KDS):
powershell
``` Add-KdsRootKey –EffectiveImmediately ```
> **Важно:** Ключ начинает работать через 10 часов. Для тестовых целей можно ускорить процесс: > >
powershell
``` > # For single-DC test environments only > Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10) > ``` > >
--- ### Шаг 2. Проверка создания корневого ключа KDS Проверяем, что корневой ключ KDS успешно создан:
powershell
``` Get-KdsRootKey Test-KdsRootKey -KeyId (Get-KdsRootKey).KeyId ```
--- ### Шаг 3. Создание группы для серверов Создаём глобальную группу безопасности, в которую будут входить серверы, имеющие право использовать gMSA:
powershell
``` New-ADGroup MySQLServers -path 'OU=SQLServers,dc=example,DC=local' -GroupScope Global -PassThru –Verbose ```
--- ### Шаг 4. Добавление серверов в группу Добавляем в созданную группу серверы, которые смогут использовать gMSA:
powershell
``` Add-AdGroupMember -Identity MySQLServers -Members SQLServ1$, SQLServ2$, SQLServ3$ ```
> **Примечание:** Имена компьютеров указываются со знаком `$` на конце. --- ### Шаг 5. Создание групповой управляемой сервисной учетной записи (gMSA) Создаём gMSA для группы `MySQLServers`:
powershell
``` New-ADServiceAccount -name gmsaSrv1c -DNSHostName gmsaSrv1c.example.local -PrincipalsAllowedToRetrieveManagedPassword MySQLServers –verbose ```
--- ### Шаг 6. Перезапуск серверов Перезапускаем серверы, на которых планируется использовать gMSA. Это необходимо для того, чтобы серверы получили актуальный состав групп и членство в `MySQLServers`. --- ### Шаг 7. Установка модуля PowerShell для Active Directory На каждом сервере, где будет использоваться gMSA, устанавливаем модуль PowerShell для работы с Active Directory:
powershell
``` Add-WindowsFeature RSAT-AD-PowerShell ```
--- ### Шаг 8. Установка учетной записи gMSA на сервере На каждом сервере устанавливаем учетную запись gMSA:
powershell
``` Install-ADServiceAccount -Identity gmsaSrv1c ```
--- ### Шаг 9. Проверка корректности установки gMSA Проверяем, что gMSA успешно установлена и готова к использованию:
powershell
``` Test-ADServiceAccount gmsaSrv1c ```
--- ### Дополнительные команды #### Изменение периодичности смены пароля По умолчанию пароль gMSA меняется каждые 30 дней. Изменить интервал можно командой:
powershell
``` Set-ADServiceAccount gmsaSrv1c -ManagedPasswordIntervalInDays 60 ```
#### Получение времени последней смены пароля
powershell
``` Get-ADServiceAccount -Identity gmsaSrv1c -Properties passwordlastset ```
--- ### Настройка запуска службы 1С из-под gMSA Для запуска службы из-под сервисной учетной записи gMSA необходимо: 1. Открыть свойства нужной службы. 2. Перейти на вкладку **Log on** (Вход в систему). 3. Выбрать пункт **This account** (С учетной записью). 4. Указать имя сервисной учетной записи **со знаком `$` на конце** (например, `gmsaSrv1c$`), **без указания пароля**. 5. Перезапустить службу. > **Важно:** Для корректной работы сервера 1С необходимо предоставить полные права учетной записи gMSA на каталог `SRVINFO`. --- ### Примечание Использовать gMSA напрямую, например, на NAS Synology, не получится. Однако можно включить учетную запись gMSA в глобальную группу безопасности и назначать разрешения на NAS уже для этой группы. # Настройка MS SQL Server для 1С: актуальный чек-лист на 2026 год **Обновлённая версия** на основе оригинального руководства 2016 года с учётом современных реалий > **Важно:** Приведённые рекомендации следует адаптировать под конкретную конфигурацию сервера и нагрузку. Это не универсальные правила, а базовая отправная точка для оптимизации. --- ## Что изменилось с 2016 года За прошедшие годы ключевые изменения коснулись следующих областей: - **Рекомендуемые версии SQL Server:** переход на SQL Server 2019/2022 (и 2025 для новых внедрений) - **Настройка TempDB:** от простого переноса на отдельный диск к созданию множества файлов данных - **Оптимизация параллелизма:** пересмотр значений MAXDOP и Cost Threshold for Parallelism - **Сортировка баз данных:** рекомендации по использованию Latin1\_General\_100\_CI\_AS --- ## Часть 1. Базовые настройки сервера ### 1.1. Включите мгновенную инициализацию файлов (Instant File Initialization) **Что даёт:** Ускоряет создание базы данных, добавление файлов и журналов, увеличение размера файлов, восстановление базы данных. **Как включить:** 1. Откройте `secpol.msc` (Local Security Policy). 2. Разверните **Локальные политики** → **Назначение прав пользователей**. 3. Дважды кликните **Выполнение задач по обслуживанию томов**. 4. Добавьте SID службы Database Engine (рекомендуется) или учётную запись службы. 5. Перезапустите службу SQL Server. > **Новое в SQL Server 2022+:** Мгновенная инициализация теперь работает и для файлов журнала транзакций при авторасширении до 64 МБ . **Проверка:** В журнале ошибок SQL Server при запуске появится сообщение `Using locked pages in the memory manager`. --- ### 1.2. Включите «Блокировка страниц в памяти» (Lock Pages in Memory) **Что даёт:** Запрещает системе отправлять страницы данных SQL Server в виртуальную память на диске. Критически важно для серверов с большим объёмом RAM — без этой настройки возможны ошибки «non-yielding scheduler» . **Как включить:** 1. В меню **Пуск** → **Выполнить** введите `gpedit.msc`. 2. Разверните: **Конфигурация компьютера** → **Конфигурация Windows** → **Настройки безопасности** → **Локальные политики** → **Назначение прав пользователя**. 3. Дважды кликните **Блокировка страниц в памяти**. 4. Добавьте SID службы Database Engine . 5. Перезапустите SQL Server. **Проверка:**
sql
``` SELECT sql_memory_model_desc FROM sys.dm_os_sys_info; -- Должно вернуть LOCK_PAGES ```
--- ### 1.3. Установите режим электропитания «Высокая производительность» **Что даёт:** Предотвращает занижение частоты процессора ОС. **Как включить:** 1. **Панель управления** → **Электропитание** → **Схемы управления электропитанием**. 2. Установите значение **Высокая производительность**. > **Примечание:** Turbo Boost в BIOS — на современных серверных платформах обычно включён по умолчанию, отдельная настройка не требуется. --- ### 1.4. Отключите ненужные службы SQL Server **Что даёт:** Освобождает ресурсы для основной службы СУБД . **Оставьте только:** - SQL Server (sqlservr.exe) - SQL Server Agent (SQLAGENT.exe) - SQL Writer (sqlwriter.exe) **Отключите:** - FullText Search (у 1С собственный механизм полнотекстового поиска) - Integration Services - Analysis Services (если не используются) --- ## Часть 2. Настройки памяти и параллелизма ### 2.1. Ограничьте максимальный объём памяти (Max Server Memory) **Что даёт:** Предотвращает потребление всей RAM сервером СУБД. **Формула расчёта:**
text
``` Память для SQL Server = Общая RAM – Память для ОС – Память для сервера 1С ```
**Современные рекомендации:** - Для ОС: 4 ГБ (или 20–25% RAM, если сервер выделен только под SQL) - Для сервера 1С: сумма потребления `ragent`, `rmngr`, `rphost` в пик нагрузки + 1–1,5 ГБ на каждый процесс rphost **Как настроить:** 1. Management Studio → **Свойства сервера** → вкладка **Память**. 2. Укажите значение параметра **Максимальный размер памяти сервера**. --- ### 2.2. Настройте Max Degree of Parallelism (MAXDOP) **Что даёт:** Определяет, во сколько потоков может выполняться один запрос. Для баз с нагрузкой 1С рекомендуется MAXDOP = 1 . **Почему важно:** При высоких значениях MAXDOP возникают ожидания `CXPACKET` и `CXCONSUMER`, когда один сложный отчёт блокирует процессорные ядра и вытесняет оперативные транзакции . **Как настроить:** 1. Management Studio → **Свойства сервера** → вкладка **Дополнительно**. 2. Установите **Max Degree of Parallelism** = 1. --- ### 2.3. Настройте Cost Threshold for Parallelism **Что даёт:** Порог, при котором запрос распараллеливается. Значение по умолчанию (5) устарело . **Рекомендация:** Установите значение **50–100**, чтобы избежать распараллеливания простых запросов. **Как настроить:**
sql
``` EXEC sp_configure 'cost threshold for parallelism', 50; RECONFIGURE; ```
--- ### 2.4. Настройте Maximum Worker Threads **Что даёт:** По умолчанию сервер не создаёт больше 255 потоков, чего может не хватать при высокой нагрузке. **Рекомендация:** Установите значение **2048** . --- ## Часть 3. Оптимизация TempDB ### 3.1. Создайте несколько файлов данных TempDB **Что даёт:** Устраняет контеншн на страницах PFS/GAM, который возникает при одновременном создании временных таблиц сотнями сессий 1С . **Правила конфигурирования:**
Количество ядер CPUКоличество файлов данных
≤ 8Ровно столько, сколько ядер
> 8Начните с 8, при сохранении ожиданий увеличивайте кратно 4 (12, 16...)
**Требования:** - Все файлы должны иметь **одинаковый начальный размер** (например, 8 файлов по 10 ГБ) - **Фиксированный шаг авторасширения** в мегабайтах (например, 1024 МБ), но не в процентах --- ### 3.2. Разместите TempDB на быстром накопителе **Что даёт:** TempDB используется всеми базами для временных таблиц, промежуточных расчётов, версий строк при RCSI . **Рекомендации:** - Отдельный RAID 10 из NVMe PCIe 4.0/5.0 накопителей - Форматирование тома NTFS/ReFS с размером кластера 64 КБ **Скрипт для переноса:**
sql
``` USE master GO ALTER DATABASE tempdb MODIFY FILE (NAME = tempdev, FILENAME = 'Новый_Диск:\Новый_Каталог\tempdb.mdf') GO ALTER DATABASE tempdb MODIFY FILE (NAME = templog, FILENAME = 'Новый_Диск:\Новый_Каталог\templog.ldf') GO ```
--- ### 3.3. Диагностика контеншна TempDB **Скрипт для выявления проблемных сессий:**
sql
``` -- Диагностика ожиданий на страницах аллокации tempdb SELECT session_id, wait_type, wait_duration_ms, resource_description, blocking_session_id FROM sys.dm_os_waiting_tasks WHERE wait_type LIKE 'PAGELATCH_%' AND resource_description LIKE '2:%'; -- База данных 2 = tempdb ```
Если ожидания `PAGELATCH_UP` или `PAGELATCH_EX` сохраняются — увеличьте количество файлов данных . --- ## Часть 4. Настройки рабочих баз данных ### 4.1. Настройте автовыращивание файлов **Что даёт:** Слишком маленький шаг авторасширения приводит к частому расширению файлов и потере времени . **Рекомендации:** - Для файлов данных: **200–512 МБ** или **512 МБ – 5 ГБ** для крупных баз - Для файлов логов: **50–200 МБ** - **Не используйте процентное автовыращивание!** **Как настроить:** 1. Management Studio → **Свойства базы** → вкладка **Файлы**. 2. Напротив каждого файла в колонке **Автовувеличение** укажите значение в МБ. > Для применения ко всем новым базам настройте служебную базу **model**. --- ### 4.2. Разнесите файлы данных (.mdf) и логов (.ldf) на разные диски **Что даёт:** Параллельная работа с файлами повышает скорость дисковых операций. Лучше всего подходят SSD . --- ### 4.3. Используйте правильную сортировку (Collation) **Что даёт:** Устаревшие настройки сортировки могут приводить к ошибкам при сравнении строк и индексации. **Рекомендация для новых баз 1С:** - `Latin1_General_100_CI_AS` (современный стандарт) - `Cyrillic_General_100_CI_AS` (альтернатива) --- ### 4.4. Рассмотрите включение RCSI (READ\_COMMITTED\_SNAPSHOT) **Что даёт:** Снижает количество блокировок при чтении, что особенно актуально для многопользовательских систем на 1С . **Как включить:**
sql
``` ALTER DATABASE [ИмяБазы] SET READ_COMMITTED_SNAPSHOT ON; ```
> **Внимание:** Требует хорошо оптимизированной TempDB. --- ## Часть 5. Обслуживание и мониторинг ### 5.1. Регламентное обслуживание индексов **Что даёт:** Фрагментация индексов > 25% резко снижает производительность . **Рекомендации:** - **Ежедневно:** Дефрагментация индексов и обновление статистики (не требует отключения пользователей) - **Еженедельно:** Полная переиндексация с блокировкой БД (в нерабочее время) --- ### 5.2. Мониторинг TempDB при закрытии месяца **Что даёт:** Закрытие месяца часто замедляется из-за переполнения TempDB неоптимальными запросами . **Диагностический скрипт:**
sql
``` SELECT session_id, SUM(internal_objects_alloc_page_count) AS alloc_pages, SUM(internal_objects_dealloc_page_count) AS dealloc_pages, SUM(user_objects_alloc_page_count) AS user_alloc_pages FROM sys.dm_db_session_space_usage GROUP BY session_id ORDER BY alloc_pages DESC; ```
Если `alloc_pages` превышает 500 000 — требуется пересмотр плана запроса . **Признаки проблемы:** - Размер TempDB растёт быстрее 1 ГБ в минуту - Процессор загружен менее чем на 30% --- ### 5.3. Настройте резервное копирование **Что даёт:** Резервные копии необходимо делать средствами самой СУБД, а не сторонними системами . --- ## Часть 6. Дополнительные рекомендации ### 6.1. Исключите каталоги баз данных из антивирусного сканирования Антивирусное сканирование файлов базы может сильно замедлить работу СУБД. В идеале антивирус на сервере СУБД вообще не устанавливать. --- ### 6.2. Отключите сжатие данных для каталогов с файлами базы При сжатии ОС дополнительно обрабатывает файлы при модификации, что замедляет запись. **Как отключить:** 1. **Свойства** каталога → вкладка **Общие** → кнопка **Другие**. 2. Снимите флаг **Сжимать содержимое для экономии места на диске**. --- ### 6.3. Включите Shared Memory (если сервер 1С на том же компьютере) **Как включить:** 1. **Диспетчер конфигурации SQL Server** → **SQL Native Client** → **Клиентские протоколы** → **Общая память** → **Включено**. 2. Протокол **Именованные каналы** выключите. **После всех настроек перезапустите службу MS SQL Server.** --- ## Сводная таблица ключевых параметров
ПараметрРекомендуемое значение
Max Server MemoryОбщая RAM – 4 ГБ (ОС) – память 1С
Max Degree of Parallelism1
Cost Threshold for Parallelism50–100
Maximum Worker Threads2048
Файлы данных TempDBПо количеству ядер (мин. 8)
Автовыращивание данных512 МБ – 5 ГБ
Автовыращивание логов50–200 МБ
СортировкаLatin1\_General\_100\_CI\_AS
--- ## Рекомендуемые версии SQL Server на 2026 год
ВерсияСтатус
SQL Server 2019Стабильная, проверенная
SQL Server 2022Рекомендуемая
SQL Server 2025Для новых внедрений
> Старые версии (2016 и ранее) приближаются к концу жизненного цикла и требуют расширенной поддержки. --- ## Заключение Данный чек-лист представляет собой обновлённую версию рекомендаций 2016 года с учётом современных реалий. Ключевые изменения касаются используемых версий SQL Server, тонкой настройки TempDB, выбора правильной сортировки и порога параллелизма. Для поддержания стабильной работы базы данных важно также не забывать о регулярном обслуживании: обновлении статистики и перестройке индексов. --- **Источники и дополнительные материалы:** - Оригинальное руководство: Насипов Фарит и Евгений Гилев, ООО «ОдинКурс», 2016 - [Microsoft Learn: Database Instant File Initialization](https://learn.microsoft.com/ru-ru/sql/relational-databases/databases/database-instant-file-initialization) - [Microsoft Learn: Enable Lock Pages in Memory](https://learn.microsoft.com/ru-ru/sql/database-engine/configure-windows/enable-the-lock-pages-in-memory-option-windows) - [Фирма 1С: Работа с базой данных TEMPDB](https://its.1c.ru/db/content/metod8dev/src/admins/mssqlserver/i8102374.htm) # Урезание логов и перевод баз 1С:Предприятие в модель SIMPLE ## Назначение Скрипт предназначен для **продуктивных (рабочих) баз 1С:Предприятие** на Microsoft SQL Server. Его задача — перевести все пользовательские базы в модель восстановления `SIMPLE` и освободить место, занимаемое файлами журналов транзакций (LDF). Данный подход является стандартной практикой для продуктовых баз 1С, поскольку восстановление на момент времени (point-in-time recovery) в 1С связано с существенными сложностями и на практике применяется редко. > **Внимание!** Риски применения описаны в сноске в конце статьи. Ознакомьтесь с ними перед запуском скрипта на продуктовом контуре. --- ## Скрипт
sql
``` ---------------------------------------------------------- -- СЛУЖЕБНЫЕ ПЕРЕМЕННЫЕ DECLARE @db_name NVARCHAR(100); -- имя базы данных DECLARE @db_name_q NVARCHAR(300); -- экранированное имя базы DECLARE @sql NVARCHAR(MAX); -- текст динамического SQL DECLARE cursor_size_srv CURSOR FOR -- Выбираем все базы, кроме системных SELECT name AS DBName FROM sys.databases WHERE name NOT IN ('master','msdb','model','tempdb') ORDER BY name; -- Цикл по всем базам, попавшим в выборку OPEN cursor_size_srv; FETCH NEXT FROM cursor_size_srv INTO @db_name; WHILE (@@FETCH_STATUS = 0) BEGIN -- Экранируем имя базы (оборачиваем в [ ] и удваиваем ]) SET @db_name_q = QUOTENAME(@db_name); -- Формируем текст динамического SQL SET @sql = N' DECLARE @logname NVARCHAR(100); USE ' + @db_name_q + N'; SELECT @logname = name FROM sys.database_files WHERE type = 1; ALTER DATABASE ' + @db_name_q + N' SET RECOVERY SIMPLE; DBCC SHRINKFILE (@logname, EMPTYFILE);'; -- Выполняем EXEC (@sql); -- Следующая база данных FETCH NEXT FROM cursor_size_srv INTO @db_name; END CLOSE cursor_size_srv; DEALLOCATE cursor_size_srv; ---------------------------------------------------------- ```
--- ## Разбор логики работы ### 1. Объявление переменных и курсора
sql
``` DECLARE @db_name NVARCHAR(100); DECLARE @db_name_q NVARCHAR(300); DECLARE @sql NVARCHAR(MAX); DECLARE cursor_size_srv CURSOR FOR SELECT name AS DBName FROM sys.databases WHERE name NOT IN ('master','msdb','model','tempdb') ORDER BY name; ```
Курсор проходит по всем базам на экземпляре, исключая системные (`master`, `msdb`, `model`, `tempdb`). Это защищает от случайного изменения настроек системных баз. Переменные: - `@db_name` — имя текущей базы из курсора. - `@db_name_q` — экранированное имя (в квадратных скобках). - `@sql` — текст динамического SQL для выполнения. ### 2. Перебор баз в цикле
sql
``` OPEN cursor_size_srv; FETCH NEXT FROM cursor_size_srv INTO @db_name; WHILE (@@FETCH_STATUS = 0) BEGIN ... FETCH NEXT FROM cursor_size_srv INTO @db_name; END ```
Стандартный паттерн работы с курсором: открыть, получить первую строку, обрабатывать в цикле, пока `@@FETCH_STATUS = 0`. ### 3. Экранирование имени базы
sql
``` SET @db_name_q = QUOTENAME(@db_name); ```
Функция `QUOTENAME()` оборачивает имя в квадратные скобки и удваивает встречающиеся внутри `]`. Это делает скрипт устойчивым к любым именам баз: - **Имена, начинающиеся с цифры** (например, `1C_Prod`) — без экранирования вызывают синтаксическую ошибку, так как не являются допустимыми обычными идентификаторами SQL Server. - **Имена с пробелами и спецсимволами** (например, `База 1С Прод`). Важно: `QUOTENAME()` вызывается **на уровне внешнего скрипта**, а не внутри строки `EXEC`. В строку динамического SQL подставляется уже готовое значение `@db_name_q`. ### 4. Формирование и выполнение динамического SQL
sql
``` SET @sql = N' DECLARE @logname NVARCHAR(100); USE ' + @db_name_q + N'; SELECT @logname = name FROM sys.database_files WHERE type = 1; ALTER DATABASE ' + @db_name_q + N' SET RECOVERY SIMPLE; DBCC SHRINKFILE (@logname, EMPTYFILE);'; EXEC (@sql); ```
Ключевые шаги внутри динамического SQL: - **`USE [db_name]`** — переключение контекста на текущую базу (нужно для `sys.database_files`). - **`SELECT @logname = name FROM sys.database_files WHERE type = 1`** — получаем логическое имя файла журнала (`type = 1`). - **`ALTER DATABASE [db_name] SET RECOVERY SIMPLE`** — переводим базу в простую модель восстановления. - **`DBCC SHRINKFILE (@logname, EMPTYFILE)`** — очищаем файл журнала, перемещая все страницы в другой файл той же файловой группы. ### 5. Особенность объявления `@logname` Переменная `@logname` объявлена **внутри динамического SQL**, а не снаружи. Это сделано намеренно: при смене контекста через `USE` переменная из внешнего блока была бы недоступна для `DBCC SHRINKFILE`. ### 6. Типы переменных - `@db_name_q NVARCHAR(300)` — с запасом под скобки и удвоение символов `]`. - `@sql NVARCHAR(MAX)` — снимает ограничение в 4000 символов, если имя базы длинное или добавляются дополнительные команды. - Строковые литералы помечены префиксом `N` для корректной работы с Unicode (кириллица в именах баз). --- ## Рекомендации по применению ### Перед запуском 1. **Сделайте полный бэкап** всех целевых баз. Это обязательное условие. 2. **Убедитесь, что модель SIMPLE допустима** для всех баз, попадающих в выборку. 3. **Запускайте в окно обслуживания** — `SHRINKFILE` может блокировать операции записи. 4. **Проверьте initial size** файла журнала. Если задано большое значение (например, 100 ГБ), шринк не уменьшит файл ниже этой отметки. ### После перевода в SIMPLE Если требуется физически уменьшить файл журнала до разумного размера, добавьте после `EMPTYFILE` команду:
sql
``` DBCC SHRINKFILE (@logname, 512); -- 512 МБ, подберите под задачу ```
### Компенсация отсутствия PITR После перевода в `SIMPLE` восстановление возможно только на момент последнего полного или дифференциального бэкапа. Необходимо: - **Делать полные бэкапы часто** — с учётом допустимого окна потери данных. - **Использовать дифференциальные бэкапы** каждые несколько часов для активных баз. - **Регулярно проверять бэкапы восстановлением** в тестовую базу. ### Проверка результата
sql
``` SELECT d.name AS DatabaseName, d.recovery_model_desc, f.name AS FileName, f.type_desc, f.size * 8 / 1024 AS SizeMB FROM sys.databases d JOIN sys.master_files f ON f.database_id = d.database_id ORDER BY d.name, f.type_desc; ```
### Особенность 1С: журнал может не урезаться до минимума Даже в модели `SIMPLE` размер журнала транзакций определяется **максимальным размером одной транзакции**. В 1С это особенно заметно при массивных операциях: перепроведение документов, закрытие месяца, реструктуризация базы. Если типичная операция занимает несколько гигабайт в логе, минимальный размер LDF не будет меньше этой величины. Если журнал снова быстро растёт после урезания — проверьте, нет ли аномально длительных операций в 1С. --- ## Сноска: риски применения > **Внимание! Перед запуском скрипта на продуктовом контуре ознакомьтесь с рисками.** **1. Потеря возможности восстановления на момент времени (PITR).** Перевод базы в модель `SIMPLE` делает невозможным восстановление на произвольный момент между полными бэкапами. При сбое вы сможете восстановиться только на момент последнего полного или дифференциального бэкапа. Вся работа, выполненная после него, будет потеряна. **2. Несовместимость с технологиями репликации.** Модель `SIMPLE` не поддерживается для групп доступности Always On (AG), лог-шиппинга (Log Shipping) и репликации транзакций. Если эти технологии настроены, их работа будет нарушена. **3. Невозможность точечного отката ошибок пользователей.** При ошибочных действиях пользователя (массовое удаление, некорректное перепроведение документов, закрытие смены ККМ) откатить изменения до нужного момента без PITR невозможно — придётся восстанавливать базу из последнего бэкапа и повторно вводить данные. **4. Блокировка операций во время SHRINKFILE.** `DBCC SHRINKFILE (... , EMPTYFILE)` может длительное время ожидать завершения активных транзакций. На продуктовой базе это приведёт к блокировкам и замедлению работы пользователей. **5. Журнал может не уменьшиться.** Даже после перевода в `SIMPLE` и шринка файл журнала не станет меньше максимального размера одной транзакции. Для 1С характерны крупные транзакции (закрытие месяца, перепроведение, реструктуризация), поэтому ожидания «лога в 100 МБ» могут не оправдаться. **6. Ограничение по initial size.** Если в свойствах базы задан большой начальный размер файла журнала, шринк не уменьшит файл ниже этой отметки. Требуется предварительная корректировка начального размера. **7. Необходимость частых бэкапов.** После перехода в `SIMPLE` критически важно обеспечить регулярные полные и дифференциальные бэкапы. Без них при сбое возможна потеря существенного объёма данных. **8. Требования аудита и регуляторов.** Некоторые отрасли и внутренние регламенты требуют возможности восстановления на произвольный момент времени. Перевод в `SIMPLE` может нарушить эти требования. **Рекомендация.** Перед запуском скрипта на продуктовом контуре согласуйте решение с ответственными за сохранность данных и убедитесь, что выбранная стратегия резервного копирования компенсирует отсутствие PITR. --- ## Итог Скрипт предназначен для продуктовых баз 1С:Предприятие и решает задачу перевода баз в модель `SIMPLE` с освобождением журналов транзакций. Благодаря `QUOTENAME()` он корректно работает с любыми именами баз, включая начинающиеся с цифры и содержащие пробелы. Перед запуском на рабочем контуре обязательно ознакомьтесь со сноской о рисках и обеспечьте регулярное резервное копирование.