Антон Дорошкевич | маяк в мире 1С и СУБД
Open in Telegram
Только интересные технические подробности, кейсы, тесты, а также анонсы выступлений на мероприятиях Никакой "воды" и рекламы Вся информация в этом канале - это моё личное мнение и не является официальной позицией вендоров и рекомендациями к действиям
Show more2 013
Subscribers
+324 hours
+27 days
+1530 days
Data loading in progress...
Similar Channels
No data
Any problems? Please refresh the page or contact our support manager.
Tags Cloud
Incoming and Outgoing Mentions
---
---
---
---
---
---
Attracting Subscribers
September '26
September '26
+6
in 0 channels
August '26
+32
in 1 channels
Get PRO
July '26
+29
in 0 channels
Get PRO
June '26
+16
in 0 channels
Get PRO
May '260
in 0 channels
Get PRO
April '26
+11
in 3 channels
Get PRO
March '26
+201
in 1 channels
Get PRO
February '26
+52
in 0 channels
Get PRO
January '26
+64
in 0 channels
Get PRO
December '25
+120
in 0 channels
Get PRO
November '25
+11 077
in 1 channels
Get PRO
October '25
+1 055
in 4 channels
| Date | Subscriber Growth | Mentions | Channels | |
| 09 September | +3 | |||
| 08 September | 0 | |||
| 07 September | 0 | |||
| 06 September | 0 | |||
| 05 September | +1 | |||
| 04 September | 0 | |||
| 03 September | 0 | |||
| 02 September | +1 | |||
| 01 September | +1 |
Channel Posts
Теперь на багборде можно легко и быстро сравнить версии платформы по изменениям!
Уверен что это сильно упростит ответ на самый популярный вопрос - "А на какую платформу переходить?")))
| 2 |  Начнём...) | 933 |
| 3 | Как собрать для анализа запроса все временные таблицы с их содержимым?
Все мы хорошо знаем, что количество временных таблиц, создаваемых и используемых во время работы 1С огромно.
Очень часто нам для оптимизации скорости работы 1С требуется не только текст запросы и его план, но и содержание временных таблиц.
А это огромная проблема – таблиц может быть много, записей в них могут быть и тысячи и миллионы…
Какие только инструменты для этого не пытались использовать, и ТехЖурнал с записью всех запросов к СУБД, и трассировку запросов на уровне СУБД. А потом сбор всех этих данных и формирование таблиц с содержимым на основании этих данных.
Было очень тяжело и всегда неохота этим заниматься…
Насколько мне известно при работе с MS SQL так ничего и не поменялось.
А вот в PostgreSQL появилось расширение auto_dump.
«На пальцах» что делает расширение:
Следит за текстом запросов dump_on_query_string и когда находит нужный (например UPDATE _AccRg), то делает бэкап всех временных таблиц и их содержимым (можно и физических, но по моему мнению это достаточно опасно, ниже опишу почему), собирает предполагаемый и фактический планы запроса, сохраняет текст самого запроса, складывает это всё в каталог указанный в параметре output_directory
Так же можно настроить чтобы собирались запросы только длительнее чем auto_dump.timeout
Или запросы у которых по нашему мнению плохой план из-за большой разницы в предполагаемых и фактических значениях bad_plan_count_threshold и/или bad_plan_percent_threshold
Чем опасен параметр dump_persistent_tables, который позволяет сразу дампить физические таблицы?
Тем что физические таблицы могут быть огромного объёма и в итоге мы получим и тормоза и забитый диск.
Поэтому включать этот параметр нужно только полностью понимая что вы делаете.
Как потом работать с полученной информацией уже запросами к СУБД напрямую:
1. Создаём новую пустую базу из 1С. Это делается для того чтобы были созданы функции и типы данных, которые использует 1С.
2. Делаем dump физических таблиц, которые есть в запросе.
3. Восстанавливаем из дампа таблицы в базу созданную в п.1
4. Выполняем скрипт по созданию временных таблиц, который нам создал auto_dump
5. Выполняем скрипт по наполнению временных таблиц, который нам создал auto_dump
6. Выполняем запрос, который нам создал auto_dump, на уровне СУБД и пытаемся его оптимизировать настройками СУБД, добавлением индексов (понимая как потом мы их сможем добавить на уровне 1С), улучшать план запроса манипулируя параметрами сбора статистики, менять сам запрос на уровне СУБД опять же понимая как мы потом это на 1С напишем и т.д.
В итоге мы получаем достаточно удобный инструмент, в котором есть вся необходимая для оптимизации запроса информация. | 1 517 |
| 4 |  Небольшой анонс поездок и мероприятий с моим участием:
03-04/09 - Обучение по PostgreSQL, Усть-Каменогорск
07-10/09 - Обучение по кластеру 1с и PostgreSQL, Москва
11/09 - Хакатон-ИнфоСофт, Новосибирск
18/09 - Жёлтая конфа, Москва
26-27/09 - Партнёрский семинар 1С, Москва
08-10/10 - Infostart Tech Event, Санкт-Петербург
Сентябрь беспощаден!) | 1 918 |
| 5 | Плановая дата обязательного перехода на Платформу 8.5 для клнфигураций ERP/УТ– не ранее 30.04.2027
Многие спрашивают - сколько ещё сможем жить на ламповой 8.3?
Фирма 1С дала ответ.
https://1c.ru/news/info.jsp?id=34779
Так что пора уже понемногу планировать переход на 8.5.
❗Особенное внимание нужно уделить переходу на новый сервис лицензирования при наличии USB-ключей, так как 8.3 не видит новый сервис, а 8.5.4 не умеет работать с lm-hasp. | 2 653 |
| 6 |  Дампы аварийного завершения процессов 1С
В последнее время достаточно часто сталкиваемся с тем что сбор дампов или не настроен, или настроен не совсем верно, или приводит к окончанию места на диске...
А тем временем причину падения процесса без разбора дампа понять бывает или очень трудно или вообще невозможно.
Так как же настроить сбор дампов и сделать так чтобы это не приводило к падению сервера по нехватке места на диске?
В настройке ТехЖурнала (файл logcfg.xml) для сбора дампов в ОС Windows (в Linux всё по другому) нужно добавить/отредактировать строку:
<dump location="D:\dumps\" create="1" type="3" externaldump="1"/>
Тип дампа (type) нужно поставить 3, так как это минимально необходимый объём информации для действенного разбора дампа.
Дамп такого типа при формировании будет иметь размер равным размеру оперативной памяти, которую занимал процесс на момент формирования дампа.
Очень важно указать location не на системном диске С и не на диске где у нас расположены сеансовые данные и/или каталог временных файлов пользователя процесса rphost.
Желательно выделить для этого отдельный логический/физический диск с объёмом свободного места не менее всего объёма оперативной памяти, так как в крайнем случае дамп будет размером во всю оперативку.
Затем нужно сделать скрипт и поставить его в шедуллер на выполнение раз в 5 минут (меньше получится только использую cron, там раз в минуту), который будет архивировать файл дампа.
Архив дампа очень часто занимает в десять раз меньше места чем оригинал.
Настроить систему мониторинга или в самом скрипте архивации прописать сообщение ответственному админу 1С о факте формирования дампа.
Что делать с дампами потом и какие они бывают?
Дамп в ОС Windows достаточно понятным именем файла:
<имя процесса>_<версия платформы>_<смещение>_<годмесяцденьчасминутасекунда>_<PID процесса>.mdmp
Например: rphost_8.3.27.1606_547f1b52_20260810051328_13432.mdmp
Сформированный архив дампа нужно отправить в 1С с полным описанием всей ситуации падения, если оно есть, только там смогут указать причину падения.
В имени много важной информации, и отдельно нас интересует смещение.
Если у нескольких дампов смещение одинаковое, то и причина падения с 99% вероятностью тоже одна, поэтому на расследование достаточно отправить пару дампов, а остальные просто сохранить с торонке.
Если же смещение _00000000_, то такой дамп отправлять никуда не нужно.
Тут причина падения заранее известна и заключается в том, что процесс был убит Системой отслеживания разрыва соединений.
Это поведение зависит от настроек кластера 1С (на скриншоте), а именно:
❗️Менять их нужно крайне осознанно полностью понимая что делаешь, несколько раз прочитав документацию и поняв её!
Принудительно завершать проблемные процессы - если выключим, то таких дампов и не будет, так как и система отслеживания по факту прекратит работу.
Так можно делать только в крайних случаях, еогда формирование дампов множественное, все они со смещением 00000000 и мешают работе системы.
Другие настройки это Период проверки (1000 мс) и Таймаут проверки (5000 мс), вот их нужно кратно увеличить до тех пор пока падения не прикратяться.
НО, сам факт таких дампов говорит о том что процессы реально не отвечают системе отслеживания и с этим нужно разбираться.
И о УЖАС - разбираться с этим нужно АДМИНИСТРАТОРАМ 1С, а не 1С-кам!!!
Вот выдержка из документации (ссылка выше), которая с этим поможет:
Для этого каждые 10 секунд в технологический журнал записывается статистика проверки соединений за прошедшие 10 секунд. В частности, выводится информация о среднем времени ответа и о максимальном времени ответа. Эта информация позволяет выставить оптимальные значения таймауты проверки, которые не будут приводить к ложным срабатываниям системы проверки, но, в тоже время, обеспечат надежное функционирование самой системы. В технологическом журнале информация фиксируется в событии CONN. | 2 354 |
| 7 | Сегодня особенный день — мой день рождения!
Хочу поблагодарить всех, кто делает мою жизнь ярче и интереснее. Каждый день я учусь чему-то новому и встречаю замечательных людей.
Пусть этот год принесет ещё больше возможностей, успехов и приятных моментов. 🌟
С днём рождения меня! 🎂
P.S. С днем рождения мою сестру-двойняшку 😘
🎉🎉🎉🎉🎉🎉 | 1 894 |
| 8 |  Статистика по временным таблицам в PostgrePRO - другой подход
Сначала о проблематике:
В 1С мы с вами обожаем создавать и использовать в запросах временные таблицы, причём создавать и заполнять их тысячами в секунду в рамках одного сервера СУБД.
При этом лучшая в мире платформа 1С, после заполнения каждой временной таблицы даёт команду ANALYZE ##tt1, где ##tt1 имя нашей временной таблицы.
При этом статистика считается по каждой колонке временной таблицы.
Это влечёт за собой серьёзные траты ресурсов сервера на расчёт статистики именно по временным таблицам.
Расширение pgpro_temp_stats предлагает интересный подход к решению этой проблемы, побочным эффектом которого может стать ускорение запросов с временными таблицами!
Кратко:
1. При включении параметра pgpro_temp_stats.skip_analyze - игнорируем команды ANALYZE по целым таблицам, т.е. пока не греем воздух просто расчётом статистики
2. При включении параметра pgpro_temp_stats.create_statistics - расширение считает статистику только по тем столбцам временной таблицы, которые задействованы в запросе.
Более того, считается не просто статистика, а расширенная статистика, т.е. не по каждому столбцу в отдельности, а по всем столбцам из запроса сразу.
Что позволяет планировщику получить более оптимальный план запроса.
Расширение доступно в 17 и 18 версиях PGRPO Enterprise.
Мы протестировали - нам понравилось!) | 1 976 |
| 9 |  +3Релизы ЗУП и ЗУП КОРП от 31/07/2026 отозваны.
Не торопитесь обновлять. | 2 615 |
| 10 | Системные администраторы, с праздником! 🎉🎉🎉
Именно системное администрирование было моим началом в ИТ) | 2 454 |
| 11 | Открыто голосование за доклады на октябрьский Инфостарт
https://infostart.ru/event/tech2026/agenda/
Выбирайте, голосуйте, приезжайте!) | 2 307 |
| 12 |  Утром в канале, вечером в Красноярске) | 2 180 |
| 13 |  Настройка параметров ibcmd в режиме replicate, а так же СУБД транслятора и СУБД приёмника для оптимальной скорости
Казалось бы, миграция базы 1С с помощью ibcmd и так происходит очень быстро, гораздо быстрее чем выгрузка/загрузка dt.
Но даже эту скорость можно существенно повысить и дальше расскажу как.
Начнём с настроек параметров ibcmd в режиме replicate при сценарии миграции базы с MS SQL на PostgreSQL как самом распространённом:
▫️ Количество потоков чтения (--jobs-count) Значение по умолчанию: количество логических ядер процессора компьютера, на котором исполняется ibcmd.
Несколько моментов, которые стоит учесть при подборе начального значения --jobs-count:
1. Утилита ibcmd ограничена одной NUMA, т.е. если у вас на сервере 48 ядер и 2 NUMA, то максимально утилита сможет занять только 48/2=24 ядра.
2. Это потоки на чтение, а есть же ещё и потоки на запись, поэтому для начала нужно поделить наши 24 ядра ещё на 2 и получим уже 12.
3. Поскольку это чтение, то точно имеет смысл включить параллелизм на MS SQL увеличив параметр MAXDOP. А вот насколько его увеличивать тут надо посчитать.
Опять же, если у нас на сервере СУБД 96 ядер, а мы читаем в 12 потоков, то нужно 96/12=8.
▫️ Количество потоков записи (--target-jobs-count) Значение по умолчанию: количество логических ядер процессора компьютера, на котором исполняется ibcmd.
Что нужно учесть при подборе параметра --target-jobs-count:
1 и 2 пункты те же самые что и у --jobs-count, т.е. в итоге получим 12
3. Поскольку это запись, то она всегда однопоточная на СУБД, но после записи у нас начнут создаваться индексы, а PostgreSQL нам позволяет распараллеливать именно эту операцию указывая параметр max_parallel_maintenance_workers (максимальное число рабочих процессов, для CREATE INDEX) и при этом не забываем что «сверху» число параллельных процессов ограничено параметром max_parallel_workers.
Соответственно при 96 ядрах на СУБД PostgreSQL и 12 потоков записи у ibcmd нам можно указать 96/12= 8 у max_parallel_maintenance_workers и max_parallel_workers = 96.
Так же будет очень полезно увеличить параметры work_mem (оперативная память на сеанс для операций ORDER BY) до 2-4 ГБ и maintenance_work_mem (Лимит памяти для CREATE INDEX) до 4-8 ГБ.
Учитывая, что у нас 12 потоков, то 12*4*8 = 384ГБ и это может быть максимум 50% всей доступной оперативной памяти.
▫️ Количество строк в порции данных (--batch-size) Количество строк в порции данных, используемой при репликации таблицы. Значение по умолчанию: 10 000
Казалось бы, ну а тут то что ещё считать, 10 000 вроде должно хватить всем?
Подбор этого параметра можно осуществить только тестами миграции и чтением лога PostgreSQL, в котором фиксируем операции длительнее 0,5 сек (log_min_duration_statement = 500ms) сравниваем скорость записи при умолчательном параметре 10 000, а затем увеличивая его на те же 10 000 пока скорость не начнёт падать.
У нас на серверах этот параметр получился оптимальным по скорости при значении 50 000.
▫️ Объем пакета данных (в байтах) (--batch-data-size). Значение по умолчанию: 10 485 760.
Ну и в целом похожий по смыслу на параметр --batch-size, только теперь в объёме памяти, а не количестве строк. Тут к сожалению, только подбор замером времени полной миграции при разных параметрах.
Опять же у нас оптимальным вышло увеличение и этого параметра в 5 раз до значения 52 428 800.
❗️Напомню, что по моему убеждению большая у вас база или нет определяется не её размером, а размером тех. окна и успеваете ли вы в это тех. окно сделать нужные вам монопольные операции или нет.
Миграция с СУБД на СУБД это одна из самых "больных" операций в части тех. окна тем и подбор параметров как ibcmd так и обоих, участвующих в этом процессе серверов СУБД может существенно и даже на порядок сократить это самое тех. окно.
Ну и на всякий случай канал в MAX https://max.ru/explorer1c | 3 056 |
| 14 | Крайне важная новость для инфраструктур в которых есть KVM
Не секрет, что последние громкие публичные взломы и шифрования в основном делались на уровне взлома систем виртуализации.
В публичный доступ вывалили уязвимость Januscape (CVE-2026-53359) в гипервизоре Linux KVM. Если у злоумышленника есть root-права внутри гостевой виртуалки, он может пробить изоляцию, выйти на уровень гипервизора на архитектуре x86 и получить полный контроль над физическим сервером и всеми остальными соседями по железу.
Ubuntu советует вырубить вложенную виртуализацию (nested virtualization).
По информации с securitylab.ru Исправление вошло в основную ветку Linux 19 июня этого года. Разработчики добавили проверку роли страницы, чтобы KVM повторно использовал её только при совпадении адреса и назначения. Исправленные стабильные ядра 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211 и 5.10.260 вышли 4 июля.
❗️Крайне рекомендую всем обновить свои системы KVM в ближайшее время. | 2 031 |
| 15 | Тонкости настройки пулов приложений IIS для 1С
Веб сервер от Microsoft - Internet Information Services (IIS) до сих пор очень популярен в инфраструктур 1С да я и сам его очень люблю за удобство и гибкость!
Взаимодействие с 1С устроено через пулы приложений IIS.
Это с одной стороны очень удобно и позволяет на одном порту опубликовать базы 1С разных версий Лучшей в мире платформы 1С!
Например базу ERP опубликовать на версии 8.3.27, а базу ZUP на версии 8.5.1 и при этом базы будут иметь один и тот же адрес сервера и порт https://web-server-erp и https://web-server/zup
▫️И тут кроется первая тонкость настройки:
Часто приходится встречаться с проблемой когда база 1С то работает по http то нет…
Естественно – никто ничего не трогал, вчера всё работало! 😄
❗️Обычно причина такого поведения кроется в том, что внутри одного пула приложений в сопоставлении обработчиков для разных баз 1С прописаны разные версии платформы 1С.
В этом случае в пул загружается та версия, которую раньше всех вызвали после перезапуска пула, а пул периодически перезапускается – по умолчанию после 20 минут простоя.
Правильно делать так:
Внутри одного пула приложений должна быть прописана одна версия платформы 1С в сопоставлении обработчиков.
После обновления версии 1С в сопоставлении обработчиков пул приложений лучше всего перезапустить.
▫️Вторая тонкость настройки касается тех инсталляций, где на одном пуле приложений работают сотни/тысячи сеансов, при чём не только пользовательских, но и http-сервисы, web-сервисы, odata, т.е. всё что идёт через веб-сервер.
Оказалось, что многопоточность рабочего процесса пула приложений IIS не бесконечна и при большом количестве соединений он начинает подвисать, что пользователями воспринимается как периодическое подтормаживание 1С…
Мы очень долго выясняли причину такого поведения, методом «научного тыка» подобрали что на нашем железе оптимальным являлась настройка Один рабочий процесс – 128 сеансов.
Но при этом количество рабочих процессов не должно быть больше количества ядер, доступных операционной системе.
Т.е., если мы рассчитываем что на это веб-сервере будет работать 2000 сеансов, то нам нужно 2000/128 = 16 рабочих процессов, а соответственно и ядер в системе нужно 16+2. Два ядра для работы остальных процессов Операционной системы.
❗️Ну и как это часто бывает, когда мы уже нашли себе ответ на вопрос, оказалось что он есть на ИТС - https://its.1c.ru/db/metod8dev/content/6034/hdoc, тут указано что расчёт нужно вести Один процесс - 100 соединений, очень похоже на наш вывод.
Правда мы столкнулись с проблемой ещё на 25-й версии платформы, и решение у нас выглядит сильно сложнее, с применением haproxy и «умной» балансировки нагрузки согласно знаниям devops системы о расположении баз 1С относительно кластеров 1С, и соединений там многие тысячи, но об этом расскажу в следующий раз.
Ну и на всякий случай канал в MAX https://max.ru/explorer1c | 2 394 |
| 16 | В этот четверг 02/07 в 10-00 по Мск (14-00 по Нск) вебинар по возможностям КОРП-платформы 1С и новшествам PostgreSQL для высоких нагрузок.
Ну и конечно ответы на все вопросы, какие накопились.
Приходите, будет интересно!) | 2 397 |
| 17 |  По дороге на ИТ-ночь https://ciocdo.ru/meropriyatiya/kupala2026/?ysclid=mqurz0d71y639102609 | 2 511 |
| 18 | Вчера получил несколько десятков вопросов с непониманием - что всё таки явилось причиной блокировок, описанных в https://t.me/explorer1c/75
❗️Итак:
Причиной проблемы был установленный параметр ALLOW_ROW_LOCKS = OFF для всех индексов всех таблиц базы.
При чём тут документация?
На ИТС написано:
До дефрагментации индекса необходимо включить страничные блокировки. Пример команды:
ALTER INDEX index_name ON table_name SET (ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON);
Выполнить дефрагментацию.
Обратно выключить страничные блокировки. Пример команды:
ALTER INDEX index_name ON table_name SET (ALLOW_PAGE_LOCKS = OFF, ALLOW_ROW_LOCKS = ON);
Т.е. речь всегда идёт только о страничных блокировках, это параметр ALLOW_PAGE_LOCKS.
Но в примерах команд есть ещё и параметр ALLOW_ROW_LOCKS , который вообще-то и в первом скрипте (Перед дефрагментацией индексов) и во втором (после дефрагментации) установлен в значение ON.
Но поскольку текстом написано включить и после дефрагментации выключить, то читается это как выключить всё что было включено.
Что и явилось причиной неверного плана обслуживания, где после дефрагментации был выключен параметр ALLOW_ROW_LOCKS=OFF. | 2 402 |
| 19 |  Прорыв блокировок на MS SQL через Управляемые
Недавно разбирали очень странную проблему…
На MS SQL фиксировалось огромное количество таймаутов, при том что конфигурация на управляемых блокировках и по идее таймауты если могут быть, то должны фиксироваться на уровне 1С с событием TTIMEOUT, а не EXCP
Пользователи сотни раз в час получали сообщение вида:
Конфликт блокировок при выполнении транзакции Microsoft SQL Server Native Client: Превышено время ожидания запроса на блокировку
При этом виновниками блокировок судя по анализу таймаутов на СУБД были совершенно безобидные запросы select…
Но по мимо них и update, и insert, и delete, да ещё и на разных таблицах…
Т.е. никакой системности, никакого одного подозреваемого и совершенно непонятное поведение СУБД.
Как будто мы работаем на автоматических, а не на управляемых блокировках…
Долго ломали голову с какой стороны подойти даже к анализу, не то что к решению проблемы, так как по ощущениям в системе не просто проблема, а «ушиб всей бабки»…
Запрос:
SELECT DB_NAME(tl.resource_database_id) AS database_name, tl.request_session_id, tl.request_mode AS lock_type,* FROM sys.dm_tran_locks tl WHERE DB_NAME(tl.resource_database_id) = 'erp' ORDER BY tl.request_session_id
Показывал очень странный вывод – в колонке resource_type была только запись OBJECT, что означает что виновник блокировки блокирует всю таблицу, а не конкретную запись/записи в ней
Если бы блокировались записи, то в колонке resource_type должна быть запись KEY.
Получается, что мало того что мы каким-то чудесным образом прорываемся сквозь управляемые блокировки, ещё и блокируем каждый раз таблицы целиком…
Но мы точно знаем – чудес не бывает!
На соседней базе, на этом же сервер СУБД выполняем запрос, который начинает транзакцию на чтение, внутри становится на паузу в 1С минуту, чтобы мы успели увидеть, что и как он блокирует
BEGIN TRANSACTION;
SELECT * FROM dbo._InfoRg178 T1 WITH (HOLDLOCK) WHERE T1._Fld80 = 'test'
WAITFOR DELAY '00:01:00';
COMMIT TRANSACTION;
И видим что СУБД совершенно корректно блокирует по KEY, т.е. конкретную запись в таблице.
Такой же запрос в проблемной базе, блокирует всю таблицу – OBJECT
Значит разница именно в какой настройке в базе, а не в сервере СУБД.
В итоге – нашли!
А именно: https://its.1c.ru/db/metod8dev/content/5837/hdoc
Важно! Начиная с версии платформы 8.3.22 необходимо выполнять дефрагментацию индексов по следующему алгоритму:
До дефрагментации индекса необходимо включить страничные блокировки. Пример команды: ALTER INDEX index_name ON table_name SET (ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON);
Выполнить дефрагментацию.
Обратно выключить страничные блокировки. Пример команды: ALTER INDEX index_name ON table_name SET (ALLOW_PAGE_LOCKS = OFF, ALLOW_ROW_LOCKS = ON);
При этом в плане обсуживания проблемной базы в самом последнем шаге устанавливается ALLOW_ROW_LOCKS = OFF
Что отключает у MS SQL возможность использовать индексы и SQL Server будет вынужден использовать только табличные блокировки
Вывод – читать документацию нужно очень внимательно, там всё написано верно, но так, что может и ввести в заблуждение)))
И проверьте свои планы обслуживания баз на MS SQL | 1 766 |
| 20 | 16/06/2026 вышел релиз Postgres PRO Enterprise 18.4.1, где добавлена поддержка операций чтения и записи для временных таблиц, временных последовательностей и временных представлений на сервере горячего резерва.
Ранее писал о нашем тестировании этого механизма:
https://t.me/explorer1c/63?single
https://max.ru/explorer1c/AZ12VKRVZj4 | 1 187 |
