При администрировании систем на базе 1С:Предприятия оптимизация временной базы данных tempdb является одной из наиболее критичных задач. Платформа 1С генерирует колоссальное количество временных таблиц при выполнении сложных запросов, расчетов себестоимости, проведении документов и формировании отчетов. Со временем диск, на котором располагается tempdb, может переполниться, либо может возникнуть необходимость переноса базы на более быстрый SSD/NVMe-накопитель для повышения общей производительности системы. Для снижения нагрузки на временную базу со стороны кода можно использовать обработку для оптимизации временных таблиц в пакетных запросах 1С.
Многие администраторы баз данных сталкиваются с трудностями, когда база данных tempdb состоит не из двух привычных файлов (данных и лога транзакций), а разделена на несколько вспомогательных файлов (один основной файл .mdf и несколько дополнительных файлов данных .ndf). Проанализируем ситуацию, разберем по шагам правильный алгоритм переноса многофайловой базы tempdb и рассмотрим важные рекомендации по ее оптимизации под нужды 1С.
Перед тем как приступать к переносу, нам необходимо точно определить логические имена всех файлов, входящих в состав базы данных tempdb, а также их текущее физическое расположение на дисках. Для этого выполним специальный проверочный запрос в СУБД MS SQL Server. Запустим среду SQL Server Management Studio (SSMS), откроем новое окно запроса и выполним следующий код:
USE master;
GO
SELECT
name AS [Logical_Name],
physical_name AS [Current_Location],
state_desc AS [Status],
size * 8 / 1024 AS [Size_MB]
FROM sys.master_files
WHERE database_id = DB_ID('tempdb');
GO
Этот запрос вернет нам таблицу со всеми файлами tempdb. В высоконагруженных конфигурациях 1С вы обычно увидите один файл журнала транзакций (логическое имя по умолчанию — templog) и несколько файлов данных (например, tempdev, temp2, temp3, ... temp8). Нам важно выписать или сохранить все эти логические имена, так как переносить файлы мы будем строго по их именам.
Выясним причину одной частой ошибки, которую допускают даже опытные администраторы. При переносе обычных пользовательских баз данных (например, рабочих баз 1С) стандартная процедура требует сначала остановить службу SQL Server, скопировать физические файлы .mdf и .ldf на новый диск, а затем запустить службу. Однако с базой данных tempdb все работает совершенно иначе.
База данных TempDB полностью пересоздается с нуля при каждом перезапуске службы SQL Server!
Это означает, что физически копировать файлы старой базы tempdb на новый диск не нужно. Это абсолютно бесполезное действие, которое приведет лишь к потере времени на копирование «мусорных» данных. Нам достаточно указать серверу новые пути, создать целевую папку и перезапустить службу — SQL Server самостоятельно создаст новые пустые файлы по указанному нами новому пути. Старые файлы на прежнем диске после успешного перезапуска службы можно будет просто удалить вручную.
Рассмотрим подробнее критически важный нюанс, из-за которого чаще всего не запускается SQL Server после переноса временной базы. Размещение файлов в корне диска (например, непосредственно в D:\) является плохой практикой администрирования. Корень диска в Windows имеет специфические ограничения прав доступа, что может заблокировать запуск СУБД.
Поэтому выполним следующие подготовительные действия:
D:\SQL_TempDB\.NT Service\MSSQLSERVER или NT SERVICE\MSSQL$ИМЯ_ЭКЗЕМПЛЯРА). Предоставим этой учетной записи полные права доступа (Full Control). Если этого не сделать, служба SQL Server после перезапуска выдаст ошибку в системном журнале и откажется запускаться.Теперь, зная логические имена всех файлов, составим результирующий скрипт. Каждую команду мы должны прописать индивидуально для каждого логического файла базы данных tempdb. Посмотрим на пример скрипта, который переносит 8 файлов данных и один файл журнала транзакций в подготовленную папку на диске D::
USE master;
GO
-- Перенос основного файла данных
ALTER DATABASE tempdb
MODIFY FILE (
NAME = tempdev,
FILENAME = N'D:\SQL_TempDB\tempdb.mdf'
);
GO
-- Перенос дополнительных файлов данных (NDF)
ALTER DATABASE tempdb
MODIFY FILE (
NAME = temp2,
FILENAME = N'D:\SQL_TempDB\tempdb_mssql_2.ndf'
);
GO
ALTER DATABASE tempdb
MODIFY FILE (
NAME = temp3,
FILENAME = N'D:\SQL_TempDB\tempdb_mssql_3.ndf'
);
GO
ALTER DATABASE tempdb
MODIFY FILE (
NAME = temp4,
FILENAME = N'D:\SQL_TempDB\tempdb_mssql_4.ndf'
);
GO
ALTER DATABASE tempdb
MODIFY FILE (
NAME = temp5,
FILENAME = N'D:\SQL_TempDB\tempdb_mssql_5.ndf'
);
GO
ALTER DATABASE tempdb
MODIFY FILE (
NAME = temp6,
FILENAME = N'D:\SQL_TempDB\tempdb_mssql_6.ndf'
);
GO
ALTER DATABASE tempdb
MODIFY FILE (
NAME = temp7,
FILENAME = N'D:\SQL_TempDB\tempdb_mssql_7.ndf'
);
GO
ALTER DATABASE tempdb
MODIFY FILE (
NAME = temp8,
FILENAME = N'D:\SQL_TempDB\tempdb_mssql_8.ndf'
);
GO
-- Перенос журнала транзакций
ALTER DATABASE tempdb
MODIFY FILE (
NAME = templog,
FILENAME = N'D:\SQL_TempDB\templog.ldf'
);
GO
Выполним данный скрипт в SSMS. В ответ СУБД вернет сообщения о том, что пути изменены в системном каталоге, но изменения вступят в силу только после перезапуска службы SQL Server.
Для применения изменений выполним перезапуск службы СУБД. Это можно сделать через оснастку services.msc (Службы), через SQL Server Configuration Manager или с помощью командной строки администратора:
net stop MSSQLSERVER
net start MSSQLSERVER
Если служба запустилась без ошибок — поздравляем, вы все сделали правильно! Теперь проверим, действительно ли файлы создались в новой папке. Снова запустим запрос из Шага 1. В колонке Current_Location мы должны увидеть новые пути на диске D:. После того как мы убедились, что новые файлы успешно функционируют, мы можем со спокойной душой зайти на старый диск и удалить оттуда старые файлы tempdb.mdf, tempdb_mssql_X.ndf и templog.ldf, освободив дисковое пространство.
Просто перенести файлы на другой диск часто бывает недостаточно для достижения максимальной производительности 1С. Проанализируем несколько критически важных рекомендаций по настройке tempdb, которые уберегут вашу систему от деградации производительности.
В MS SQL Server распределение записи по файлам базы данных происходит по алгоритму Proportional Fill (пропорциональное заполнение). Если ваши файлы данных tempdev, temp2 ... temp8 будут иметь разный размер, SQL Server начнет писать данные преимущественно в тот файл, в котором больше свободного места. Это мгновенно создаст узкое горлышко дисковой производительности (очередь I/O) на одном файле и сведет к нулю всю пользу от разделения базы данных на несколько файлов.
Правило: Все файлы данных tempdb должны иметь строго одинаковый начальный размер (например, по 4 ГБ или 8 ГБ каждый) и строго одинаковый фиксированный шаг авторасширения в мегабайтах (например, по 256 МБ или 512 МБ), а не в процентах!
Количество файлов напрямую зависит от количества логических процессоров (ядер с учетом технологии Hyper-Threading) на сервере:
tempdb, равное количеству ядер.PAGELATCH_UP или PAGELATCH_EX в базе данных с ID = 2). Слишком большое количество файлов на многопроцессорных серверах может снизить общую производительность из-за накладных расходов процессора.По умолчанию при создании или расширении файлов баз данных операционная система Windows заполняет выделяемое пространство нулями. При работе тяжелых запросов в 1С база tempdb может начать резко расширяться, вызывая длительные зависания сессий пользователей 1С на время, пока файлы заполняются нулями.
Чтобы избежать этого, включите мгновенную инициализацию файлов. Для этого добавьте право «Выполнение задач по обслуживанию томов» (Perform Volume Maintenance Tasks) учетной записи службы SQL Server в локальной политике безопасности Windows (утилита secpol.msc -> Локальные политики -> Назначение прав пользователя). Это позволит SQL Server мгновенно аллоцировать место на диске под файлы tempdb без предварительного зануления.
Рекомендуется размещать файлы данных tempdb на наиболее скоростных локальных накопителях (лучше всего использовать корпоративные NVMe SSD в RAID-массиве). Крайне желательно отделять эти накопители от дисков, где хранятся рабочие базы данных 1С и их журналы транзакций, чтобы высокоинтенсивные операции чтения/записи во временных таблицах не мешали стабильной работе основных баз. Для комплексной проверки параметров СУБД и выявления узких мест можно использовать инструмент для чек-апа настроек СУБД под требования 1С.