Нередко системные администраторы и специалисты 1С сталкиваются с ситуацией: в консоли кластера 1С нет активных сеансов или служба сервера 1С вовсе остановлена, однако дисковая подсистема сильно нагружена, и процесс СУБД продолжает активно вычитывать данные из файла базы данных .mdf. В результате производительность сервера деградирует, а пользователи сталкиваются с зависаниями.
Разберем подробно, почему SQL Server выполняет операции чтения с диска в фоновом режиме, какими встроенными инструментами и системными запросами можно локализовать источник нагрузки, и как оптимизировать обслуживание баз данных.
Если в 1С сеансы отсутствуют, чтение данных инициируется внутренними задачами СУБД или внешними подключениями напрямую к Microsoft SQL Server. Выделим ключевые факторы:
DBCC CHECKDB) или создание резервных копий. Все эти процессы сканируют страницы данных с диска.AUTO_UPDATE_STATISTICS и внешнее приложение запрашивает данные из таблицы с устаревшей статистикой, SQL Server приостанавливает выполнение запроса и выполняет полное сканирование таблицы.Table Scan гигабайтных таблиц.Ghost Cleanup), сброс страниц или автоматическое сжатие файлов (AUTO_SHRINK).Для быстрого визуального анализа воспользуемся штатными инструментами среды администрирования:
Ctrl+Alt+A). В разделах Процессы и Недавние ресурсоемкие запросы отсортируем список по столбцу операций чтения, чтобы увидеть логин, имя приложения и ресурсоемкий запрос.Агент SQL Server → Монитор активности заданий. Проверим, какие фоновые регламентные задачи запущены в текущий момент (например, регламентный расчет статистик или дефрагментация).Чтобы точно определить, кто инициирует чтение, выполним следующий SQL-запрос. Он покажет идентификаторы сессий, учетные записи, имена хостов, названия программ и точный текст выполняемого SQL-кода:
SELECT
r.session_id,
s.login_name,
s.host_name,
s.program_name,
r.status,
r.command,
r.reads,
r.logical_reads,
r.cpu_time,
r.total_elapsed_time,
t.text AS sql_query_text
FROM sys.dm_exec_requests r
JOIN sys.dm_exec_sessions s ON r.session_id = s.session_id
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE r.session_id <> @@SPID
ORDER BY r.reads DESC;
Проанализируем вывод запроса: столбец program_name позволяет сразу выявить внешние коннекторы (например, запросы от BI-систем или фоновые утилиты), а reads указывает объем физических чтений с диска.
Для проверки объемов прочитанных мегабайт и задержек ввода-вывода (I/O latency) по отдельным файлам данных используем представление sys.dm_io_virtual_file_stats:
SELECT
DB_NAME(vfs.database_id) AS database_name,
mf.name AS file_logical_name,
mf.physical_name,
vfs.num_of_reads,
vfs.num_of_bytes_read / 1024 / 1024 AS mb_read,
vfs.io_stall_read_ms
FROM sys.dm_io_virtual_file_stats(NULL, NULL) vfs
JOIN sys.master_files mf
ON vfs.database_id = mf.database_id AND vfs.file_id = mf.file_id
WHERE vfs.database_id = DB_ID('Имя_Вашей_Базы');
Разберем практические шаги по оптимизации работы сервера:
AUTO_UPDATE_STATISTICS_ASYNC. В этом случае запрос пользователя выполняется мгновенно по имеющейся статистике, а пересчет запускается в фоновом потоке, исключая «зависание» сессий:
ALTER DATABASE [Имя_Вашей_Базы]
SET AUTO_UPDATE_STATISTICS_ASYNC ON;
READ_COMMITTED_SNAPSHOT:
ALTER DATABASE [Имя_Вашей_Базы]
SET READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK IMMEDIATE;