Почему база 1С на SQL 25ГБ тормозит, если логи регулярно чистятся?

В этой теме 1 ответ, 2 участника, последнее обновление 13 минут назад сделано Odin — Одинэсник.

Просмотр 1 ветки ответов

Автор

Записи

10 ноября 2026 в 8:55 #38994
Odineski
Участник
база 1с SQL 25Gb стала сильно тормозить логи раз в неделю вычищаются

10 ноября 2026 в 8:55 #38995

Участник

25 ГБ для базы 1С на SQL Server не является большим размером. Сам по себе размер базы обычно не объясняет сильные тормоза. В вашем случае в первую очередь нужно проверить:

1. Не переполняется ли журнал транзакций.
2. Какая модель восстановления установлена.
3. Выполняются ли резервные копии журнала.
4. Не запускается ли раз в неделю тяжелая очистка или уменьшение журнала.
5. Нет ли блокировок, фрагментации индексов и устаревшей статистики.
6. Хватает ли места на дисках и оперативной памяти.

## 1. Сначала определить причину роста журнала

Выполните в SQL Server Management Studio:

SELECT
    name,
    recovery_model_desc,
    log_reuse_wait_desc
FROM sys.databases
WHERE name = N'ИмяБазы1С';

SELECT

name,

recovery_model_desc,

log_reuse_wait_desc

FROM sys.databases

WHERE name = N'ИмяБазы1С';

Вместо ИмяБазы1С укажите фактическое имя базы.

Возможные результаты log_reuse_wait_desc:

— NOTHING , журнал может использоваться повторно, проблема не в невозможности очистки;
— LOG_BACKUP , для базы в модели FULL не выполняются резервные копии журнала;
— ACTIVE_TRANSACTION , есть незавершенная или зависшая транзакция;
— DATABASE_MIRRORING , проблема связана с зеркалированием;
— AVAILABILITY_REPLICA , проблема связана с Always On;
— REPLICATION , журнал удерживается репликацией;
— ACTIVE_BACKUP_OR_RESTORE , идет резервное копирование или восстановление;
— OLDEST_PAGE , старая версия данных удерживается активной транзакцией.

Также проверьте фактическое заполнение журнала:

USE [ИмяБазы1С];

DBCC SQLPERF(LOGSPACE);

USE [ИмяБазы1С];

DBCC SQLPERF(LOGSPACE);

Более современный вариант:

USE [ИмяБазы1С];

SELECT
    total_log_size_in_bytes / 1024.0 / 1024 AS TotalLogSizeMB,
    used_log_space_in_bytes / 1024.0 / 1024 AS UsedLogSizeMB,
    used_log_space_in_percent AS UsedPercent
FROM sys.dm_db_log_space_usage;

USE [ИмяБазы1С];

SELECT

total_log_size_in_bytes / 1024.0 / 1024 AS TotalLogSizeMB,

used_log_space_in_bytes / 1024.0 / 1024 AS UsedLogSizeMB,

used_log_space_in_percent AS UsedPercent

FROM sys.dm_db_log_space_usage;

## 2. Проверьте модель восстановления

SELECT
    name,
    recovery_model_desc
FROM sys.databases
WHERE name = N'ИмяБазы1С';

SELECT

name,

recovery_model_desc

FROM sys.databases

WHERE name = N'ИмяБазы1С';

### Если установлена модель FULL

В этом случае журнал транзакций не будет освобождаться просто от обычного полного резервного копирования базы. Необходимо регулярно делать резервные копии журнала.

Обычно для базы 1С достаточно выполнять их каждые 15 минут, 30 минут или 1 час, в зависимости от требований к восстановлению.

Пример резервной копии журнала:

BACKUP LOG [ИмяБазы1С]
TO DISK = N'D:SQLBackupИмяБазы1С_log.trn'
WITH
    INIT,
    COMPRESSION,
    STATS = 10;

BACKUP LOG [ИмяБазы1С]

TO DISK = N'D:SQLBackupИмяБазы1С_log.trn'

WITH

INIT,

COMPRESSION,

STATS = 10;

Важно: файл резервной копии журнала не нужно каждый раз перезаписывать через INIT, если вы хотите хранить цепочку резервных копий. Обычно используются разные имена файлов или настроенный SQL Server Agent.

После настройки резервного копирования журнала его физический размер сам по себе может остаться большим. Это нормально. Главное, чтобы внутри него освобождалось место для повторного использования.

### Если резервные копии журнала не нужны

Для большинства обычных баз 1С можно использовать модель SIMPLE:

ALTER DATABASE [ИмяБазы1С]
SET RECOVERY SIMPLE;

1 2	ALTER DATABASE [ИмяБазы1С] SET RECOVERY SIMPLE;

После переключения модель восстановления сама по себе может не уменьшить физический файл журнала. Если журнал уже раздулся, его можно один раз уменьшить до разумного размера.

Сначала определите логическое имя файла:

USE [ИмяБазы1С];

SELECT
    name,
    type_desc,
    size * 8 / 1024 AS SizeMB,
    physical_name
FROM sys.database_files;

USE [ИмяБазы1С];

SELECT

name,

type_desc,

size * 8 / 1024 AS SizeMB,

physical_name

FROM sys.database_files;

Затем однократно:

USE [ИмяБазы1С];

DBCC SHRINKFILE (N'ИмяЛогическогоФайлаЛога', 2048);

USE [ИмяБазы1С];

DBCC SHRINKFILE (N'ИмяЛогическогоФайлаЛога', 2048);

Здесь 2048 означает 2 ГБ. Это только пример. Размер нужно выбирать по фактической нагрузке.

Не рекомендуется выполнять SHRINKFILE каждую неделю. После уменьшения SQL Server будет снова увеличивать журнал, что приводит к дополнительным паузам, фрагментации и тормозам.

## 3. Не путайте очистку журнала с уменьшением файла

Есть две разные операции:

1. Освободить занятые внутри журнала участки для повторного использования.
2. Уменьшить физический файл .ldf.

Регулярное уменьшение .ldf обычно является ошибкой. Правильная схема:

— для FULL настроить резервное копирование журнала;
— для SIMPLE не уменьшать журнал постоянно;
— один раз подобрать размер журнала с запасом;
— настроить нормальный шаг авторасширения, например 512 МБ или 1 ГБ;
— не использовать авторасширение в процентах.

Проверить параметры файлов можно так:

SELECT
    DB_NAME(database_id) AS DatabaseName,
    name,
    type_desc,
    size * 8 / 1024 AS SizeMB,
    growth,
    is_percent_growth,
    physical_name
FROM sys.master_files
WHERE database_id = DB_ID(N'ИмяБазы1С');

SELECT

DB_NAME(database_id) AS DatabaseName,

name,

type_desc,

size * 8 / 1024 AS SizeMB,

growth,

is_percent_growth,

physical_name

FROM sys.master_files

WHERE database_id = DB_ID(N'ИмяБазы1С');

Если is_percent_growth = 1, лучше заменить процентное увеличение на фиксированное:

ALTER DATABASE [ИмяБазы1С]
MODIFY FILE
(
    NAME = N'ИмяЛогическогоФайлаЛога',
    FILEGROWTH = 512MB
);

ALTER DATABASE [ИмяБазы1С]

MODIFY FILE

(

NAME = N'ИмяЛогическогоФайлаЛога',

FILEGROWTH = 512MB

);

## 4. Проверьте, не тормозит ли база во время еженедельной процедуры

Если тормоза появляются примерно в один и тот же день или время, очень вероятно, что запускается одно из заданий:

— уменьшение файлов базы;
— перестроение всех индексов;
— обновление статистики всей базы;
— проверка целостности;
— полное резервное копирование;
— резервное копирование журнала;
— обслуживание баз сразу нескольких информационных баз;
— удаление данных в 1С;
— очистка регистра сведений;
— регламентное задание 1С;
— обновление полнотекстового индекса;
— обработка копий базы данных или 1С:Аналитики.

Проверьте задания SQL Server Agent и регламентные задания в 1С.

Особенно подозрительны задания, в которых присутствуют команды:

DBCC SHRINKDATABASE
DBCC SHRINKFILE
ALTER INDEX ... REBUILD
UPDATE STATISTICS
DBCC CHECKDB

DBCC SHRINKDATABASE

DBCC SHRINKFILE

ALTER INDEX ... REBUILD

UPDATE STATISTICS

DBCC CHECKDB

DBCC CHECKDB сам по себе полезен, но на рабочей базе объемом 25 ГБ он может создавать заметную нагрузку. Его лучше запускать ночью и не одновременно с резервным копированием или регламентными заданиями 1С.

## 5. Проверьте активные блокировки

Во время тормозов выполните:

SELECT
    r.session_id,
    r.blocking_session_id,
    r.status,
    r.command,
    r.wait_type,
    r.wait_time,
    r.cpu_time,
    r.total_elapsed_time,
    DB_NAME(r.database_id) AS DatabaseName,
    t.text AS SqlText
FROM sys.dm_exec_requests AS r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) AS t
WHERE r.database_id = DB_ID(N'ИмяБазы1С');

SELECT

r.session_id,

r.blocking_session_id,

r.status,

r.command,

r.wait_type,

r.wait_time,

r.cpu_time,

r.total_elapsed_time,

DB_NAME(r.database_id) AS DatabaseName,

t.text AS SqlText

FROM sys.dm_exec_requests AS r

CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) AS t

WHERE r.database_id = DB_ID(N'ИмяБазы1С');

Если blocking_session_id не равен 0, один сеанс блокирует другой.

Для просмотра открытых транзакций:

DBCC OPENTRAN (N'ИмяБазы1С');

1	DBCC OPENTRAN (N'ИмяБазы1С');

Если найдена очень старая активная транзакция, она может не давать SQL Server переиспользовать журнал. Причиной может быть:

— зависший сеанс 1С;
— длительная обработка;
— незавершенная транзакция в расширении;
— массовое проведение документов;
— удаление большого объема данных;
— зависшая фоновая задача.

Нельзя без проверки сразу завершать сеанс командой KILL. Сначала нужно определить, что это за пользователь, что он выполняет и не идет ли важная операция.

## 6. Проверьте индексы и статистику

На базе 1С не стоит бездумно перестраивать абсолютно все индексы каждый день. Но если база давно не обслуживалась, фрагментация может влиять на скорость.

Проверка фрагментации:

USE [ИмяБазы1С];

SELECT
    OBJECT_SCHEMA_NAME(ips.object_id) AS SchemaName,
    OBJECT_NAME(ips.object_id) AS TableName,
    i.name AS IndexName,
    ips.index_type_desc,
    ips.avg_fragmentation_in_percent,
    ips.page_count
FROM sys.dm_db_index_physical_stats
(
    DB_ID(),
    NULL,
    NULL,
    NULL,
    'LIMITED'
) AS ips
INNER JOIN sys.indexes AS i
    ON ips.object_id = i.object_id
    AND ips.index_id = i.index_id
WHERE ips.database_id = DB_ID()
  AND ips.index_id > 0
  AND ips.page_count > 1000
ORDER BY ips.avg_fragmentation_in_percent DESC;

USE [ИмяБазы1С];

SELECT

OBJECT_SCHEMA_NAME(ips.object_id) AS SchemaName,

OBJECT_NAME(ips.object_id) AS TableName,

i.name AS IndexName,

ips.index_type_desc,

ips.avg_fragmentation_in_percent,

ips.page_count

FROM sys.dm_db_index_physical_stats

(

DB_ID(),

NULL,

'LIMITED'

) AS ips

INNER JOIN sys.indexes AS i

ON ips.object_id = i.object_id

AND ips.index_id = i.index_id

WHERE ips.database_id = DB_ID()

AND ips.index_id > 0

AND ips.page_count > 1000

ORDER BY ips.avg_fragmentation_in_percent DESC;

Ориентировочно:

— до 10% , ничего не делать;
— от 10 до 30% , обычно REORGANIZE;
— более 30% , возможно REBUILD, но лучше не выполнять это в рабочее время.

Пример:

ALTER INDEX [ИмяИндекса]
ON [dbo].[ИмяТаблицы]
REORGANIZE;

ALTER INDEX [ИмяИндекса]

ON [dbo].[ИмяТаблицы]

REORGANIZE;

или:

ALTER INDEX [ИмяИндекса]
ON [dbo].[ИмяТаблицы]
REBUILD;

ALTER INDEX [ИмяИндекса]

ON [dbo].[ИмяТаблицы]

REBUILD;

При REBUILD существенно увеличивается нагрузка и может резко вырасти журнал транзакций. Если база работает в модели FULL, перед таким обслуживанием особенно важно, чтобы резервные копии журнала выполнялись штатно.

Обновить статистику можно так:

USE [ИмяБазы1С];

EXEC sys.sp_updatestats;

USE [ИмяБазы1С];

EXEC sys.sp_updatestats;

Но на рабочей базе это также может дать нагрузку. Запускайте ночью и предварительно сделайте резервную копию.

## 7. Проверьте крупные таблицы базы

Размер базы 25 ГБ нужно разложить на данные и индексы:

USE [ИмяБазы1С];

SELECT
    t.name AS TableName,
    SUM(a.total_pages) * 8 / 1024 AS TotalMB,
    SUM(a.used_pages) * 8 / 1024 AS UsedMB,
    SUM(a.data_pages) * 8 / 1024 AS DataMB
FROM sys.tables AS t
INNER JOIN sys.indexes AS i
    ON t.object_id = i.object_id
INNER JOIN sys.partitions AS p
    ON i.object_id = p.object_id
    AND i.index_id = p.index_id
INNER JOIN sys.allocation_units AS a
    ON p.partition_id = a.container_id
GROUP BY t.name
ORDER BY TotalMB DESC;

USE [ИмяБазы1С];

SELECT

t.name AS TableName,

SUM(a.total_pages) * 8 / 1024 AS TotalMB,

SUM(a.used_pages) * 8 / 1024 AS UsedMB,

SUM(a.data_pages) * 8 / 1024 AS DataMB

FROM sys.tables AS t

INNER JOIN sys.indexes AS i

ON t.object_id = i.object_id

INNER JOIN sys.partitions AS p

ON i.object_id = p.object_id

AND i.index_id = p.index_id

INNER JOIN sys.allocation_units AS a

ON p.partition_id = a.container_id

GROUP BY t.name

ORDER BY TotalMB DESC;

Если среди крупнейших объектов находятся таблицы:

— _DbCopiesTrLogs;
— _DbCopiesTrTables;
— _DbCopiesTrChanges;
— _DbCopiesTrChObj;
— _DbCopiesInitialLast;
— _DbCopiesUpdates;

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

Удалять данные напрямую из таблиц 1С через SQL нельзя без понимания структуры и резервной копии. Сначала нужно отключать ненужные копии базы штатными средствами 1С и проверять результат. Прямое удаление из таблиц 1С может повредить логическую целостность базы.

## 8. Проверьте свободное место

Нужно проверить свободное место минимум на следующих дисках:

— диск с файлами данных .mdf и .ndf;
— диск с журналом .ldf;
— диск для временной базы tempdb;
— диск для резервных копий.

Если файл журнала растет, а на диске мало свободного места, 1С может начать выдавать ошибки и сильно замедляться.

Рекомендуется размещать отдельно:

— файлы данных;
— файл журнала;
— tempdb;
— резервные копии.

Для небольшой базы это не всегда обязательно, но при постоянных тормозах разделение дисков помогает определить узкое место.

## 9. Проверьте настройки SQL Server и 1С

Для SQL Server стоит проверить:

— разрядность SQL Server, желательно 64 bit;
— достаточный объем оперативной памяти;
— ограничение максимальной памяти SQL Server;
— наличие свободной памяти на сервере;
— загрузку дисков;
— размер tempdb;
— число файлов tempdb;
— включенную автостатистику;
— отсутствие запуска тяжелых заданий в рабочее время.

Если SQL Server забирает всю память сервера, оставляя недостаточно памяти операционной системе и серверу 1С, работа также будет замедляться.

Проверьте параметры памяти:

SELECT
    name,
    value_in_use
FROM sys.configurations
WHERE name IN
(
    'max server memory (MB)',
    'min server memory (MB)'
);

SELECT

name,

value_in_use

FROM sys.configurations

WHERE name IN

(

'max server memory (MB)',

'min server memory (MB)'

);

Для сервера, где одновременно работают SQL Server и сервер 1С, нельзя отдавать SQL Server всю оперативную память. Нужно оставить запас для Windows, rphost, rmngr, антивируса и других служб.

## Что исправить в первую очередь

Практический порядок действий такой:

1. Узнать recovery_model_desc и log_reuse_wait_desc.
2. Проверить фактический размер и заполнение .ldf.
3. Если модель FULL, настроить резервное копирование журнала каждые 15 минут, 30 минут или 1 час.
4. Если модель SIMPLE, не выполнять еженедельный SHRINK.
5. Один раз уменьшить чрезмерно раздутый журнал после устранения причины роста.
6. Найти еженедельное задание, во время которого начинаются тормоза.
7. Проверить блокировки и активные транзакции именно в момент тормозов.
8. Проверить фрагментацию индексов и статистику.
9. Найти самые крупные таблицы.
10. Проверить свободное место, память, tempdb и нагрузку на диски.

Наиболее вероятные причины при вашем описании:

— журнал не резервируется, а раз в неделю принудительно уменьшается;
— раз в неделю выполняется тяжелый REBUILD или SHRINK;
— зависает длительная транзакция;
— база работает в FULL, но резервные копии журнала не настроены;
— накопились таблицы механизма «Копии баз данных»;
— тормоза вызываются регламентным заданием 1С, а не размером самой базы.

Автор

Записи

Просмотр 1 ветки ответов

Для ответа в этой теме необходимо авторизоваться.

Вы пропустили

Новый курс «Администратор 1С v4.1»

Автономный сервер 1С — публикация ИБ

Установка PostgreSQL 17 для 1С на Windows server 2022

Как запустить «Сервер 1С» на Ubuntu 24.04 LTS ?