Как определить размер таблиц 1С в SQL: от простых запросов до продвинутых методов

Работа с базами данных 1С:Предприятие рано или поздно сталкивает администраторов с необходимостью анализировать объемы таблиц. Это критично для оптимизации производительности, планирования резервного копирования или миграции на другое оборудование. Однако стандартные инструменты платформы 1С не всегда предоставляют полную картину — особенно когда речь идет о физическом размере таблиц на уровне SQL-сервера.

В этой статье мы разберем 5 проверенных способов получить точные данные о размерах таблиц 1С в разных СУБД (SQL Server, PostgreSQL, Oracle), включая скрытые системные таблицы платформы. Вы узнаете, какие запросы использовать для анализа фрагментации, как интерпретировать результаты и какие инструменты ускорят процесс. Особое внимание уделим типичным ошибкам, которые искажают реальные показатели, и дадим рекомендации по оптимизации "раздутых" таблиц.

Почему важно мониторить размеры таблиц 1С в SQL

На первый взгляд, контроль объемов таблиц кажется рутинной задачей, но на практике он решает сразу несколько критичных проблем:

• 📉 Производительность: таблицы размером более 10 ГБ часто становятся узким местом при выполнении запросов. Например, таблица _AccumRgT92345 (регистр накопления) может тормозить отчеты, если не оптимизирована.
• 💾 Резервное копирование: знание точных объемов позволяет спланировать время бэкапа и место на диске. Так, база с таблицами общим объемом 500 ГБ потребует иного подхода, чем база на 50 ГБ.
• 🔄 Миграция: при переносе на новый сервер или переходе с SQL Server на PostgreSQL точное понимание структуры данных помогает избежать сюрпризов с нехваткой места.
• 🛠️ Диагностика: внезапный рост таблицы (например, _DocLog) может сигнализировать о сбоях в логировании или ошибках в конфигурации.

Без регулярного мониторинга администраторы рискуют столкнуться с timeout-ошибками при выполнении тяжелых операций или неожиданным заполнением дискового пространства. Например, в одной из компаний таблица _InfoRg87654 (регистр сведений) выросла до 120 ГБ из-за некорректной очистки истории — это было обнаружено только когда база перестала помещаться в резервную копию.

Способ 1: Стандартные запросы для SQL Server

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

SELECT
t.NAME AS TableName,
s.Name AS SchemaName,
p.rows AS RowCounts,
SUM(a.total_pages) * 8 AS TotalSpaceKB,
CAST(ROUND(((SUM(a.total_pages) * 8) / 1024.00), 2) AS NUMERIC(36, 2)) AS TotalSpaceMB,
CAST(ROUND(((SUM(a.total_pages) * 8) / 1024.00 / 1024.00), 2) AS NUMERIC(36, 2)) AS TotalSpaceGB
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.NAME NOT LIKE 'dt%'
AND t.is_ms_shipped = 0
AND i.OBJECT_ID > 255
GROUP BY
t.Name, s.Name, p.Rows
ORDER BY
TotalSpaceGB DESC;

Этот запрос возвращает:

• 📊 Имя таблицы и схему (важно для 1С, где таблицы часто лежат в схеме dbo)
• 📈 Количество строк — помогает оценить плотность данных
• 💾 Объем в КБ, МБ и ГБ с округлением до двух знаков

Обратите внимание на фильтр t.NAME NOT LIKE 'dt%' — он исключает временные таблицы, которые SQL Server создает для служебных операций. Без этого фильтра результаты будут зашумлены ненужными данными.

Способ 2: Анализ для PostgreSQL

В PostgreSQL подход отличается — здесь нет системных представлений вроде sys.tables, но есть мощные функции для работы с каталогами. Используйте этот запрос:

SELECT
table_schema || '.' || table_name AS full_table_name,
pg_size_pretty(pg_total_relation_size(quote_ident(table_schema) || '.' || quote_ident(table_name))) AS total_size,
pg_size_pretty(pg_relation_size(quote_ident(table_schema) || '.' || quote_ident(table_name))) AS data_size,
pg_size_pretty(pg_indexes_size(quote_ident(table_schema) || '.' || quote_ident(table_name))) AS indexes_size,
pg_stat_get_live_tuples(quote_ident(table_schema) || '.' || quote_ident(table_name)) AS live_rows
FROM
information_schema.tables
WHERE
table_schema NOT IN ('pg_catalog', 'information_schema')
AND table_type = 'BASE TABLE'
ORDER BY
pg_total_relation_size(quote_ident(table_schema) || '.' || quote_ident(table_name)) DESC;

Ключевые особенности этого запроса:

• 🔍 Функция pg_total_relation_size учитывает данные + индексы + TOAST (специфичная для PostgreSQL структура для хранения больших объектов).
• 📏 pg_size_pretty автоматически форматирует размер в удобочитаемый вид (например, "12 GB").
• 🗃️ Фильтр исключает системные схемы pg_catalog и information_schema, где хранятся служебные данные PostgreSQL.

Для баз 1С на PostgreSQL особенно важно отслеживать таблицы с суффиксами _VT (виртуальные таблицы) и _DD (данные документов). Например, таблица _Document123_VT может занимать непропорционально много места из-за неоптимальной структуры хранения.

Способ 3: Oracle Database — специфика и запросы

В Oracle для анализа размеров таблиц используются представления словаря данных. Основной запрос выглядит так:

SELECT
owner || '.' || table_name AS full_table_name,
ROUND(NVL(bytes/1024/1024, 0), 2) AS size_mb,
ROUND(NVL(num_rows, 0)) AS row_count,
ROUND(NVL(blocks, 0)) AS blocks_used
FROM
all_tables
WHERE
owner NOT IN ('SYS', 'SYSTEM', 'XDB', 'CTXSYS')
AND table_name NOT LIKE 'BIN$%'
ORDER BY
size_mb DESC;

Важные нюансы для Oracle:

• 🏷️ Колонка owner критична — в Oracle таблицы привязаны к схеме-пользователю. Для 1С это обычно пользователь, под которым создана база (например, USR1CV8).
• 🗑️ Фильтр table_name NOT LIKE 'BIN$%' исключает таблицы в "корзине" (recyclebin), которые занимают место, но не используются.
• 📊 Размер в bytes переводится в мегабайты делением на 1024². Для гигабайт добавьте еще одно деление на 1024.

В Oracle также полезно анализировать сегменты некластеризованных индексов:

SELECT
index_name,
ROUND(NVL(bytes/1024/1024, 0), 2) AS size_mb
FROM
all_indexes
WHERE
owner = 'USR1CV8'  -- Замените на вашу схему 1С
ORDER BY
size_mb DESC;

Способ 4: Анализ через инструменты 1С

Не всегда удобно работать напрямую с SQL — особенно если у вас нет прав на выполнение системных запросов. В таких случаях поможет встроенная функциональность 1С:Предприятие:

1. Тестирование и исправление:

   Перейдите в Администрирование → Тестирование и исправление. На вкладке Таблицы отобразится список таблиц с количеством строк и приблизительным размером. Минус метода — данные не всегда точные (особенно для больших баз) и не учитывают индексы.

2. Консоль запросов:

   В режиме Конфигуратор откройте Сервис → Консоль запросов. Здесь можно выполнить SQL-запрос прямо к базе (если разрешены прямые запросы). Например, для SQL Server:

   ВЫБРАТЬ
   ИмяТаблицы КАК Таблица,
   РазмерМБ КАК Размер
   ИЗ
   (ВЫПОЛНИТЬ("SELECT name AS ИмяТаблицы, SUM(reserved_page_count) * 8 / 1024 AS РазмерМБ FROM sys.dm_db_partition_stats WHERE object_id > 100 GROUP BY name")) КАК ВременнаяТаблица
   УПОРЯДОЧИТЬ ПО
   Размер УБЫВ

3. Отчет "Анализ использования дискового пространства":

   В некоторых конфигурациях (например, 1С:ERP) есть стандартный отчет, который показывает распределение данных по таблицам. Найдите его через Отчеты → Стандартные отчеты.

Преимущество этих методов — не требуют знания SQL. Однако они дают приблизительные данные и не заменяют полноценный анализ на уровне СУБД.

Способ 5: Продвинутый анализ с учетом фрагментации

Обычные запросы показывают "сырой" размер таблиц, но не учитывают фрагментацию — разрывов в данных, которые увеличивают физический объем без пользы для производительности. Для глубокого анализа используйте:

Для SQL Server:

SELECT
OBJECT_NAME(ind.OBJECT_ID) AS TableName,
ind.name AS IndexName,
indexstats.avg_fragmentation_in_percent,
indexstats.page_count,
CAST(indexstats.avg_fragmentation_in_percent AS INT) AS FragmentationPercent
FROM
sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'LIMITED') indexstats
INNER JOIN
sys.indexes ind ON ind.object_id = indexstats.object_id AND ind.index_id = indexstats.index_id
WHERE
indexstats.avg_fragmentation_in_percent > 10  -- Порог фрагментации
AND OBJECT_NAME(ind.OBJECT_ID) NOT LIKE 'dt%'
ORDER BY
FragmentationPercent DESC;

Для PostgreSQL:

SELECT
schemaname || '.' || tablename AS full_table_name,
n_live_tup AS live_rows,
n_dead_tup AS dead_rows,
ROUND(n_dead_tup * 100.0 / (n_live_tup + n_dead_tup), 2) AS dead_percentage,
last_autovacuum
FROM
pg_stat_all_tables
WHERE
n_dead_tup > 0
AND schemaname NOT IN ('pg_catalog', 'information_schema')
ORDER BY
dead_percentage DESC;

Критичные пороги фрагментации:

В 1С высокий уровень фрагментации часто наблюдается в таблицах регистров накопления (например, _AccumRg12345) и регистров сведений с большой историей изменений. Регулярная очистка истории или архивирование данных может снизить фрагментацию на 40-60%.

Типичные ошибки и как их избежать

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

⚠️ Внимание: Если вы используете 1С:Предприятие 8.3.20+ с управляемыми блокировками, временные таблицы сессий могут искусственно увеличивать размер базы. Перед анализом завершите все сеансы или используйте фильтр WHERE session_id <> @@SPID в запросах.

• 🔄 Игнорирование транзакционных логов:

  В SQL Server размер файла .ldf (лог транзакций) может превышать размер самой базы. Чтобы получить полную картину, проверяйте его размер через DBCC SQLPERF(LOGSPACE).

• 📁 Учет только данных без индексов:

  Индексы могут занимать до 70% от общего размера таблицы. Всегда анализируйте их отдельно (например, через sys.indexes в SQL Server).

• 🕒 Анализ во время пиковой нагрузки:

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

• 🔍 Пропуск системных таблиц 1С:

  Таблицы вроде _ClusterNodes, _Subscriptions или _SchedJobs часто игнорируют, хотя они могут занимать гигабайты в распределенных базах.

Еще одна типичная ошибка — сравнивать размеры таблиц до и после сжатия (например, после DBCC SHRINKDATABASE). Сжатие уменьшает физический размер файлов, но увеличивает фрагментацию и деградирует производительность. Всегда оценивайте логический размер данных, а не физический объем файлов .mdf/.ndf.

FAQ: Частые вопросы по анализу таблиц 1С

SELECT
OBJECT_NAME(object_id) AS TableName,
SUM(CAST((
CASE
WHEN DATEDIFF(day, modify_date, GETDATE()) <= 30
THEN reserved_page_count * 8.0 / 1024
ELSE 0
END) AS FLOAT)) AS GrowthLast30DaysMB
FROM
sys.dm_db_partition_stats
WHERE
object_id > 100
GROUP BY
object_id
HAVING
SUM(CAST((
CASE
WHEN DATEDIFF(day, modify_date, GETDATE()) <= 30
THEN reserved_page_count * 8.0 / 1024
ELSE 0
END) AS FLOAT)) > 0
ORDER BY
GrowthLast30DaysMB DESC;