Представьте ситуацию: ваша база данных 1С на платформе MS SQL Server стабильно работала и весила, к примеру, 68 Гб. Но буквально за трое суток ее объем внезапно увеличился на 25 Гб, достигнув отметки в 92 Гб. При этом в журнале регистрации 1С нет никаких аномальных событий, а пользователи уверяют, что работают в обычном режиме. Знакомая картина? В этой статье мы подробно разберем, как локализовать проблему «раздувания» базы данных, выясним причины такого поведения СУБД и рассмотрим по шагам технологию перевода хранения файлов из базы данных в тома на жестком диске.
Когда мы сталкиваемся с лавинообразным ростом базы данных, первым делом необходимо локализовать, что именно увеличилось физически. В случае использования MS SQL Server база состоит минимум из двух файлов: файла данных (с расширением .mdf) и файла журнала транзакций (с расширением .ldf). Выясним, какой именно файл вырос:
Если мы убедились, что увеличился именно файл .mdf, проанализируем основные прикладные причины резкого роста данных в 1С:
Для того чтобы точно определить виновника роста, нам потребуется заглянуть «под капот» MS SQL Server и оценить физический размер таблиц. Сделать это можно как средствами самой СУБД, так и специализированными обработками 1С. Проанализируем оба варианта.
Рассмотрим сначала классический запрос T-SQL, который можно выполнить в среде SQL Server Management Studio (SSMS). Он позволяет вывести список всех таблиц базы данных, отсортированных по занимаемому пространству:
SELECT
t.NAME AS TableName,
s.Name AS SchemaName,
p.rows AS RowCounts,
SUM(a.total_pages) * 8 AS TotalSpaceKB,
SUM(a.used_pages) * 8 AS UsedSpaceKB,
(SUM(a.total_pages) - SUM(a.used_pages)) * 8 AS UnusedSpaceKB
FROM
sys.tables t
INNER JOIN
sys.indexes i ON t.object_id = i.object_id
INNER JOIN
sys.partitions p ON i.object_id = p.object_id AND i.index_id = p.index_id
INNER JOIN
sys.allocation_units a ON p.partition_id = a.container_id
LEFT OUTER JOIN
sys.schemas s ON t.schema_id = s.schema_id
WHERE
t.is_ms_shipped = 0
AND i.object_id > 255
GROUP BY
t.Name, s.Name, p.Rows
ORDER BY
TotalSpaceKB DESC;
Выполнив этот запрос, мы получим список системных имен таблиц (например, _InfoRg19063) и их физический размер в килобайтах. Теперь нам нужно сопоставить физическое имя таблицы SQL с понятным объектом метаданных 1С. Для этого воспользуемся встроенной функцией платформы ПолучитьСтруктуруХраненияБазыДанных().
Разберем простой пример кода на языке 1С, который можно запустить во внешней обработке или в режиме отладки через табло, чтобы быстро сопоставить имя SQL-таблицы с объектом конфигурации:
СтруктураБД = ПолучитьСтруктуруХраненияБазыДанных();
Для Каждого СтрокаТаблицы Из СтруктураБД Цикл
Если СтрокаТаблицы.ИмяТаблицыХранения = "_InfoRg19063" Тогда
Сообщить("Имя таблицы в SQL: " + СтрокаТаблицы.ИмяТаблицыХранения);
Сообщить("Объект в 1С: " + СтрокаТаблицы.ИмяТаблицы);
Сообщить("Назначение: " + СтрокаТаблицы.Назначение);
КонецЕсли;
КонецЦикла;
В результате анализа мы выясняем, что таблица _InfoRg19063 соответствует регистру сведений РегистрСведений.ДвоичныеДанныеФайлов. Именно этот регистр в типовых конфигурациях (таких как ERP, КА, УТ, УТАП) отвечает за хранение всех присоединенных к объектам файлов. Становится очевидно: пользователи начали загружать в систему тяжелые сканы документов, из-за чего база данных стремительно увеличивается в объемах.
Хранить двоичные данные внутри СУБД — крайне неэффективное решение, так как это увеличивает время создания резервных копий СУБД, снижает скорость работы дисковой подсистемы и повышает требования к дорогостоящему дисковому пространству под СУБД. Оптимальное решение — перенос файлов на внешние тома хранения. Выполним эту настройку по шагам:
\\server-name\shared-folder\).Важное предупреждение: Пути к томам должны быть сетевыми (UNC), даже если папка находится на том же физическом сервере, где установлен сервер 1С. Локальные пути вида D:\Files допускается использовать только в том случае, если сервер 1С работает в односерверном режиме и никогда не будет масштабироваться на кластер.
При хранении файлов вне базы данных безопасность информации выходит на первый план. Нам необходимо настроить права доступа к сетевой папке \\server-name\shared-folder\ по следующим правилам:
USR1CV8 или доменная учетная запись службы).Проанализируем критически важную деталь: простое включение настройки «Хранить файлы в томах» влияет только на новые загружаемые файлы. Те 25 Гб файлов, которые уже успели «раздуть» базу, автоматически из СУБД не переместятся.
Для переноса ранее накопленных данных выполним встроенную процедуру Библиотеки Стандартных Подсистем (БСП):
ДвоичныеДанныеФайлов.Обратите внимание, что процесс переноса сотен тысяч файлов создает колоссальную нагрузку на дисковую подсистему и оперативную память сервера. Запускать эту процедуру необходимо исключительно в периоды технологического окна (ночью или в выходные дни), предварительно убедившись, что все пользователи вышли из базы данных.
После успешного завершения переноса файлов в тома мы можем заметить, что размер файла базы данных .mdf на диске остался прежним (92 Гб). Почему это произошло? Дело в том, что MS SQL Server при удалении данных внутри таблиц просто помечает освободившиеся страницы как пустые для последующей записи, но физически не возвращает место операционной системе.
Чтобы физически уменьшить файл базы данных и вернуть дисковое пространство ОС, выполним операцию сжатия базы данных (Shrink):
Важное примечание: Операция сжатия базы данных (Shrink) приводит к сильнейшей фрагментации индексов СУБД (она может достигать 95-99%). Сразу после завершения процедуры Shrink в обязательном порядке запустите регламентные процедуры обслуживания базы данных — реорганизацию и переиндексацию (Reorganize/Rebuild Indexes). Если этого не сделать, производительность системы 1С после сжатия может катастрофически снизиться.
Перевод файлов в тома решает проблему производительности и размера базы, но накладывает на администратора дополнительные обязанности. Проанализируем критические риски, которые необходимо учитывать:
.bak) и архива каталога с томами файлов. Необходимо настроить расписание так, чтобы бэкап базы и бэкап тома создавались максимально близко по времени друг к другу. В противном случае при восстановлении базы на определенную дату вы можете получить несоответствие: в базе запись о прикрепленном файле есть, а физически в томе на диске этот файл еще отсутствует (или наоборот).Таким образом, мы детально разобрали механизм диагностики резкого роста базы данных, выявили причину в виде неоптимального хранения файлов внутри СУБД и перевели систему на эффективную работу с дисковыми томами. Это позволило вернуть дисковое пространство серверу СУБД, уменьшить время создания ежедневных бэкапов и значительно повысить стабильность работы всей информационной системы.