Давайте вместе рассмотрим ситуацию, когда после серьезного сбоя базы данных PostgreSQL и последующего восстановления, пользовательские варианты отчетов, созданные через расширения в 1С:Предприятии (в данном случае УТ 11.4), перестают отображаться в интерфейсе пользователя. При этом мы выяснили, что предопределенные варианты отчетов и пользовательские варианты для стандартных отчетов видны без проблем. Самое интригующее — данные этих "пропавших" вариантов отчетов, предположительно, существуют в таблице reference67, но система 1С их почему-то не подхватывает. Разберем эту сложную проблему, пытаясь понять как логику хранения 1С, так и возможные причины сбоев в PostgreSQL.
Для начала, давайте проанализируем, как система 1С:Предприятие хранит варианты отчетов и почему они могут быть не видны, даже если их данные, казалось бы, присутствуют в базе. В 1С существуют два основных типа вариантов отчетов:
В нашем случае, пользовательские варианты отчетов, созданные для отчетов из расширений, перестали быть видимыми. При этом автор темы указывает на несколько таблиц, которые были восстановлены из бэкапа: _frmdtsettings, Reference262, Reference250, Reference125, ReferenceChngR20769, reference67. Особое внимание уделяется таблице reference67, где, как утверждает автор, "все варианты отчетов есть".
Почему же данные есть, а отображения нет? Мы можем предположить несколько причин, по которым такое может происходить:
reference67), 1С использует множество вспомогательных системных таблиц для хранения метаданных, связей между объектами, информации о владельцах настроек (пользователях) и т.д. Возможно, при восстановлении базы данных или в результате сбоя, были повреждены или некорректно восстановлены именно эти связующие таблицы, которые "регистрируют" пользовательские варианты отчетов для определенного отчета и пользователя. Например, могут быть нарушены связи, указывающие, к какому именно отчету и к какому расширению относится данный вариант./UpdateDBCfg) частично помогает, но, как мы видим, восстанавливает только предопределенные варианты. Возможно, требуется более глубокая процедура, которая, к сожалению, не всегда документирована для конечного пользователя или администратора.К сожалению, в рамках данного обсуждения на форуме не было найдено прямого решения или указания на конкретную "еще одну таблицу", которая бы полностью решила проблему видимости вариантов отчетов. Однако мы видим, что фокус обсуждения быстро сместился на диагностику причин самого сбоя PostgreSQL, что является критически важным для предотвращения подобных ситуаций в будущем.
Поскольку первопричиной потери данных стал сбой PostgreSQL, давайте подробно рассмотрим настройки СУБД, которые были предоставлены, и как они влияют на стабильность и производительность работы 1С:Предприятия. Правильная настройка PostgreSQL является фундаментальным аспектом обеспечения надежности и быстродействия информационной системы.
Мы видим, что в конфигурационном файле postgresql.conf есть секция # CUSTOMIZED OPTIONS, которая содержит актуальные настройки, переопределяющие или дополняющие стандартные закомментированные параметры. Давайте разберем их.
listen_addresses = '*'
shared_buffers = 16103MB # 25% of RAM
temp_buffers = 128MB
work_mem = 256MB
maintenance_work_mem = 256MB
max_files_per_process = 10000
max_parallel_workers_per_gather = 1
max_parallel_maintenance_workers = 6 # Количество CPU/4, минимум 2, максимум 6
commit_delay = 1000
max_wal_size = 4GB
min_wal_size = 2GB
checkpoint_timeout = 15min
effective_cache_size = 48311MB # 75% of RAM
from_collapse_limit = 8
join_collapse_limit = 8
autovacuum_max_workers = 12 # Количество CPU/2, минимум 2
vacuum_cost_limit = 1200 # 100* autovacuum_max_workers
autovacuum_naptime = 20s
autovacuum_vacuum_scale_factor = 0.01
autovacuum_analyze_scale_factor = 0.005
max_locks_per_transaction = 1024
escape_string_warning = off
standard_conforming_strings = off
shared_preload_libraries = 'online_analyze, plantuner'
online_analyze.threshold = 50
online_analyze.scale_factor = 0.1
online_analyze.enable = on
online_analyze.verbose = off
online_analyze.min_interval = 10000
online_analyze.table_type = 'temporary'
plantuner.fix_empty_table = on
Журнал предзаписи (WAL) — это краеугольный камень отказоустойчивости PostgreSQL. Все изменения сначала записываются в WAL, а затем уже в саму базу данных. В случае сбоя, PostgreSQL использует WAL для восстановления базы до последнего консистентного состояния.
wal_level = replica (закомментировано в секции WAL, но важно для 1С): Для 1С:Предприятия рекомендуется устанавливать значение replica или logical. Это необходимо для корректной работы репликации и некоторых расширений. Отсутствие явной настройки может означать использование значения по умолчанию (обычно replica для современных версий), но всегда лучше убедиться, что оно установлено.fsync = on (закомментировано): Этот параметр определяет, будет ли PostgreSQL принудительно сбрасывать данные на диск для обеспечения безопасности при сбоях. Его отключение (off) значительно увеличивает производительность, но также в разы повышает риск потери данных и повреждения базы при внезапном отключении питания или аппаратном сбое. Если вы используете RAID-контроллер с кэшем в режиме write-back, крайне важно убедиться, что контроллер имеет батарейку или конденсатор для защиты кэша (BBU/FBU). Если такой защиты нет, fsync должен быть on.synchronous_commit = on (закомментировано): Этот параметр определяет, будет ли транзакция считаться зафиксированной только после того, как её записи в WAL будут физически сброшены на диск. Отключение этого параметра (off) может повысить производительность, так как система не будет ждать сброса данных на диск для каждой транзакции. Однако при этом возникает небольшой риск потери последних нескольких транзакций (обычно в течение 0.5-1 секунды) в случае жесткого сбоя сервера. База данных при этом останется целостной, но может "откатиться" на очень короткий промежуток времени. Для 1С часто рекомендуют комбинацию fsync = on и synchronous_commit = off как баланс между скоростью и безопасностью.max_wal_size = 4GB и min_wal_size = 2GB: Эти параметры совместно с checkpoint_timeout регулируют частоту контрольных точек (checkpoint). Контрольные точки — это моменты, когда все "грязные" страницы из оперативной памяти (измененные, но не записанные на диск) принудительно сбрасываются на постоянное хранилище.
max_wal_size позволяет системе дольше не выполнять контрольные точки, что может улучшить производительность во время активной записи, но увеличит время восстановления базы данных после сбоя.min_wal_size определяет минимальный объем WAL-файлов, которые система должна сохранять.max_wal_size и min_wal_size являются хорошим выбором для активных баз 1С.checkpoint_timeout = 15min: Этот параметр задает максимальный интервал между контрольными точками. Если max_wal_size достигается быстрее, чем истекает checkpoint_timeout, контрольная точка будет выполнена раньше. Значение 15 минут в сочетании с max_wal_size = 4GB является разумным для большинства систем 1С, но может потребовать корректировки в зависимости от интенсивности записи.Эффективное использование оперативной памяти критически важно для производительности PostgreSQL.
shared_buffers = 16103MB (25% от ОЗУ): Это основной буфер, который PostgreSQL использует для кэширования данных и индексов. Значение в 25% от доступной оперативной памяти является хорошей отправной точкой. Увеличение этого параметра обычно положительно сказывается на производительности, поскольку больше данных может храниться в памяти, уменьшая количество обращений к диску. Однако слишком большое значение может привести к конкуренции за память с операционной системой и другими процессами, вызывая своппинг, что, наоборот, ухудшит производительность. Мы рекомендуем экспериментировать, постепенно увеличивая его и отслеживая нагрузку на диск.temp_buffers = 128MB: Максимальный объем памяти, который каждая сессия может использовать для временных буферов. Временные буферы используются для кэширования временных таблиц и временных файлов, создаваемых при сложных запросах. Значение 128 МБ подходит для большинства случаев.work_mem = 256MB: Лимит памяти для операций сортировки и хэширования в рамках одного запроса. Если запросу требуется больше памяти, чем установлено в work_mem, он будет использовать временные файлы на диске, что значительно медленнее. Каждая сессия может использовать несколько блоков work_mem одновременно. Значение 256 МБ довольно щедрое и может быть адекватным для сложных отчетов 1С. Мы рекомендуем внимательно отслеживать логи PostgreSQL на предмет сообщений о превышении work_mem, чтобы при необходимости его скорректировать.maintenance_work_mem = 256MB: Лимит памяти, используемый для операций обслуживания, таких как VACUUM, ANALYZE, CREATE INDEX и ALTER TABLE ADD FOREIGN KEY. Увеличение этого параметра (например, до 512 МБ или 1 ГБ для больших баз) может ускорить эти операции.effective_cache_size = 48311MB (75% от ОЗУ): Этот параметр не выделяет память напрямую, а информирует оптимизатор запросов о предполагаемом размере дискового кэша, доступного для одного запроса. Оптимизатор использует это значение при принятии решения о том, стоит ли использовать индексное сканирование или последовательное сканирование таблицы. Установка этого параметра в 50-75% от общего объема оперативной памяти является распространенной практикой.Автовакуум (autovacuum) — это критически важный фоновый процесс в PostgreSQL, который предотвращает раздувание таблиц (bloat) и очищает "мертвые" строки, оставшиеся после операций UPDATE и DELETE. Без регулярного вакуума база данных будет расти, а производительность ухудшаться.
autovacuum_max_workers = 12 (Количество CPU/2, минимум 2): Этот параметр определяет максимальное количество процессов автовакуума, которые могут работать одновременно. Значение 12 для многоядерного сервера является агрессивным и обычно эффективным, так как 1С может генерировать большой объем "мертвых" строк. Мы рекомендуем подбирать это значение, исходя из количества ядер процессора, чтобы не перегружать систему.vacuum_cost_limit = 1200 (100 * autovacuum_max_workers): Этот параметр ограничивает "стоимость" операций вакуума. Автовакуум работает, исходя из бюджетной модели, чтобы не мешать другим операциям. Увеличение лимита позволяет автовакууму выполнять больше работы за один цикл. Значение 1200 при 12 воркерах является логичным продолжением рекомендованной формулы.autovacuum_naptime = 20s: Период (в секундах) между запусками автовакуума на каждой базе данных. Значение 20 секунд указывает на довольно частую проверку, что хорошо для активно изменяющихся баз 1С.autovacuum_vacuum_scale_factor = 0.01: Доля от числа строк таблицы, при превышении которой запускается VACUUM. Значение 0.01 (1%) является очень низким и агрессивным, что заставляет автовакуум запускаться чаще. Это помогает поддерживать таблицы в актуальном состоянии и предотвращать раздувание.autovacuum_analyze_scale_factor = 0.005: Доля от числа строк таблицы, при превышении которой запускается ANALYZE (обновление статистики). Значение 0.005 (0.5%) еще более агрессивно, чем для VACUUM. Частое обновление статистики критически важно для оптимизатора запросов 1С, так как он сможет принимать более точные решения о планах выполнения запросов.Эти расширения специально разработаны для улучшения производительности PostgreSQL в связке с 1С:Предприятием.
shared_preload_libraries = 'online_analyze, plantuner': Этот параметр загружает указанные библиотеки при старте PostgreSQL-сервера. Это необходимо для того, чтобы расширения были доступны.online_analyze.enable = on: Включает функциональность расширения online_analyze. Этот модуль позволяет обновлять статистику для таблиц сразу после операций INSERT, UPDATE, DELETE или SELECT INTO, что особенно полезно для временных таблиц (online_analyze.table_type = 'temporary'), активно используемых в 1С. Это помогает оптимизатору запросов принимать более правильные решения, особенно если стандартный автовакуум не успевает оперативно обновлять статистику для быстро меняющихся данных.
online_analyze.threshold = 50: Минимальное количество измененных строк, после которого запускается онлайн-анализ.online_analyze.scale_factor = 0.1: Процент от количества строк таблицы, после изменения которого запускается онлайн-анализ.online_analyze.min_interval = 10000: Минимальный интервал между запусками анализа для одной таблицы (в миллисекундах).plantuner.fix_empty_table = on: Включает функциональность расширения plantuner. Этот модуль помогает оптимизировать планы выполнения запросов, добавляя поддержку указаний для планировщика и улучшая планирование запросов с недавно созданными пустыми таблицами. В 1С часто создаются и используются временные таблицы, которые на момент планирования запроса могут быть пустыми, что приводит к неоптимальным планам выполнения. plantuner помогает решить эту проблему.listen_addresses = '*': Позволяет PostgreSQL принимать соединения со всех сетевых интерфейсов. Для производственной среды рекомендуется указывать конкретные IP-адреса, чтобы повысить безопасность.max_files_per_process = 10000: Максимальное число файлов, которое может быть одновременно открыто каждым серверным подпроцессом. Значение 10000 является высоким и достаточным для 1С, которая может открывать множество файлов.commit_delay = 1000: Задержка в микросекундах перед сбросом WAL на диск. Это позволяет собрать несколько транзакций и сбросить их одной операцией, что может улучшить производительность дисковой подсистемы.max_parallel_workers_per_gather = 1 и max_parallel_maintenance_workers = 6: Эти параметры управляют параллельным выполнением запросов и операций обслуживания. Для 1С часто не рекомендуется использовать агрессивное распараллеливание запросов из-за особенностей их формирования, поэтому max_parallel_workers_per_gather = 1 является разумным. А вот для операций обслуживания (например, VACUUM или CREATE INDEX), параллелизм может быть полезен, отсюда max_parallel_maintenance_workers = 6.Чтобы минимизировать риск повторения подобных сбоев и обеспечить максимальную стабильность системы, мы рекомендуем обратить внимание на следующие аспекты:
archive_mode = on) являются вашей последней линией защиты от потери данных.chdbfl.exe или утилиты администрирования 1С). Это поможет выявить и, возможно, исправить логические ошибки в структуре данных 1С, которые могли возникнуть в результате сбоя или некорректного восстановления.Таким образом, хотя мы не смогли найти прямого решения проблемы с видимостью пользовательских вариантов отчетов из расширений в данной теме форума, мы провели детальный анализ конфигурации PostgreSQL, который является основой для стабильной работы 1С:Предприятия. Правильная настройка WAL, буферов памяти, автовакуума и использование специализированных расширений, таких как online_analyze и plantuner, могут значительно снизить вероятность возникновения аппаратных и программных сбоев, подобных описанному. В случае повторения проблемы с вариантами отчетов, рекомендуется обращаться в службу поддержки 1С с максимально подробным описанием ситуации и логов.