Sql - таблицы postgresql существуют, но при запросе появляется сообщение «отношение не существует»

Лишние объекты базы данных

Точнее неиспользуемые объекты базы данных. К ним могут относиться:

неизвестные таблицы;
неиспользуемые индексы;

Для того, чтобы отделить используемые объекты от неиспользуемых для начала потребуется включить сбор статистики в принципе, если его кто-то догадался выключить (https://www.postgresql.org/docs/current/runtime-config-statistics.html). Кстати, я где-то читал, что сборщик статистики можно выключить для экономии ресурсов. Не знаю, не проверял, ума хватило не заниматься ерундой.

Также, мне пришлось сбросить статистику, так как VACUUM FULL на всех таблицах привел к тому, что все таблицы использовались и из них читались данные. Сброс статистики выполняется командой:

И это значит, что сразу искать неиспользуемые объекты — нельзя, пока все данные не пройдут некоторый жизненный цикл, пойду попью кофе.

Неизвестные таблицы

Это таблицы — остатки миграций и экспериментов. Так же могут оставаться устаревшие и уже не используемые таблицы. Тут как повезет, если разработчики точно знают какие таблицы уже ими не используются — это хорошо, иначе ищем сами. Так, можно посмотреть, вообще из каких таблиц читались данные за последнее время:

Мне повезло, и большинство таблиц называлось более чем вменяемо и однотипно:

Смотрим, итого:

И это без учета размера индексов на этих таблицах и только одна база (пусть и самая большая).

Далее, можно переименовать все таблицы по шаблону, например ‘deplecated_’ + relname, либо отключить права на чтение-запись для проектного пользователя и ждать обратной связи от пользователей и приложений. В случае чего вернуть всегда можно. А можно их просто удалить, все одно есть резервирование и судя по статистике таблицы не используются, значит в бекапе будут актуальные данные.

Итого высвобождено места: 19 Gb (на 1Gb наскребли индексы и прочие таблицы из других баз).

Неиспользуемые индексы

С индексами все гораздо проще, так как они не хранят в себе данные, но в процессе развития проекта некоторые индексы перестают быть актуальными. Некоторые создавались в качестве неудачных экспериментов оптимизации, но не удалялись. С одной стороны казалось бы ничего плохого, но с другой — индексы занимают дисковое пространство и требуют перестроений при изменении данных, то есть таким образом замедляют работу на этих операциях.

Но не стоит забывать, что некоторые индексы все-таки могут не использоваться, но тем не менее требуются для обеспечения логики, к таким индексам относятся:

PRIMARY KEY
UNIQ CONSTRAINT

Первичный ключ удалять точно нельзя даже если статистика показывает, что он ни разу не использовался. Уникальные индексы тоже скорее всего удалять нельзя, по крайней мере без согласования с разработкой. Тем не менее некоторые разработчики считают, что уникальные индексы работают быстрее и могут наплодить их вагон и тележку, при этом они будут проходить проверку уникальности, просто потому что в них поле id, и не создавать конфликтов при работе. Так что проверить все же стоит. Впрочем, это больше относится к производительности, потому вернемся к занимаемому месту.

Итак, поиск неиспользуемых индексов практически не отличается от поиска неиспользуемых таблиц.

При этом, удаление “лишних” индексов не так страшно с точки зрения данных. Но после удаления обязательно провести мониторинг и анализ медленных запросов к базе.

Общий размер составил:

Итого высвобождено места: 14 Gb.

В итоге, всего “мусора” насобирали на 33 Gb, с одной стороны немного, но с другой — в боевой базе много мусора быть и не должно.

В общем, с черновой уборкой закончили пора перейти к самой “мякоте”.

Журнал предзаписи (WAL)

То что у нас данные находятся в оперативной памяти – это хорошо. Но при сбое эти данные теряются, если не успели записаться на диск.

После сбоя наша база становится рассогласованной. Какие-то страницы менялись и были записаны, другие не успели записаться.

Журнал предварительной записи (WAL) – механизм, которым позволит нам восстановить согласованность данных после сбоя.

Когда мы хотим поменять какую-то страницу памяти, мы предварительно пишем, что хотим сделать в журнал предзаписи. И запись в этом журнале должна попасть на диск раньше, чем сама страница будет записана на диск.

В случае сбоя мы смотрим в журнал предзаписи и видим какие действия выполнялись, проделываем эти действия заново и восстанавливаем согласованность данных.

Почему запись в WAL эффективнее чем запись самой страницы? При записи страницы памяти на диск она пишется в произвольное место, это место еще нужно выбрать, подготовить для записи и начать запись. А запись в журнал ведется одним потоком и с этим потоком нормально справляются и обычные жёсткие диски и ssd.

WAL защищает всё что попадает в буферный кэш:

страницы таблиц, индексов;
статусы транзакций.

WAL не защищает:

временные таблицы;
нежурналируемые таблицы.

background

Some operations in the database may use temporary files such as sorting, HASH JOIN, intermediate result storage, aggregation, and so on.

In order to improve the efficiency of database execution, some operations may use memory instead of temporary storage, only use temporary files when there is insufficient memory.

The work_mem can set the threshold of the temporary memory used by the session Query. Of course, if a large number of parallel sorting operations are used in a Query, or when multiple WORKER PROCESSs are used in parallel, multiple WORK_MEM spaces may be used, then the memory The amount used may be larger.

Note that the temporary table is not the same as the temporary file used in the Query execution process, including several temporary file usage tracking parameters mentioned later, which actually track the temporary files generated during Query execution, not temporary. table. Please note.

In controlling the amount of temporary file usage, the number of parameters used is controlled by the temporary file generated during Query execution, and does not control how many files are used by the temporary table.

Кто уложил 1С, или мониторинг загрузки кластера в разрезе пользователей с помощью Grafana

Мониторингом различных параметров работы кластера 1С в zabbix сейчас уже никого не удивишь. Собственно потребление памяти, процов и места на серверах обычно настраивают первыми. Потом идет мониторинг в разрезе rphost’ов и различные метрики функционирования SQL сервера. Но вот когда уже все это есть, то временами возникает вопрос — какой же конкретно нехороший человек пытается съесть все (ну не все, но много) ресурсы сервера?

Можно смотреть в консоль кластера и ловить редиску там. Можно анализировать журнал регистраций, включать технологический журнал или накапливать статистку в специализированных базах 1С. Но, «настоящим» сисадминам проще как-то с внешними скриптами, базами данных и, например, Grafana. Расскажу что у нас получилось.

1 стартмани

02.09.2019
14166
32
DonAlPatino

Производительность WAL

По умолчанию, каждый раз, когда транзакция фиксирует изменения, результат должен быть сброшен на диск. Для этого вначале страница сбрасывается из буферной памяти на дисковый кэш. А затем выполняется операция fsync для записи страницы на диск. То есть частые COMMIT приводят к частым fsync.

В PostgreSQL есть другой режим работы – асинхронный. При этом каждый COMMIT не приводит к fsync. Вместо этого страницы сбрасываются на диск по расписанию специальным процессом – WALWRITER. Этот процесс периодически просыпается и записывает на диск всё что изменилось за время пока он спал и опять засыпает.

В асинхронном режиме postgresql работает быстрее, но вы можете потерять некоторые данные при сбое.

Режим работы настраивается с помощью конфигурационного файла и настройки не требуют перезагрузки сервера. Это позволяет приложению устанавливать параметры на лету. Некоторые транзакции сразу запишут изменения на диск, то есть поработают в синхронном режиме. Другие транзакции будут работать в асинхронном режиме. Условно можно поделить операции на критичные и не критичные.

Следующие параметры отвечают за режим работы WAL:

synchronous_commit – on/off – синхронный или асинхронный режим работы;
wal_writer_delay = 200ms – период сброса на диск wal записей при асинхронном режиме.

1С:Предприятие Бухгалтерия переход с редакции 2.0 на 3.0. Практика перевода информационной базы для работы в управляемом приложении. Промо

Из информационного выпуска 1С № 16872 от 08.07.2013г. стало известно об относительно скором необходимом переходе на редакцию 1С:Бухгалтерия 3.0. В данной публикации будут разобраны некоторые особенности перевода нетиповой конфигурации 1С:Бухгалтерия 2.0 на редакцию 3.0, которая работает в режиме «Управляемое приложение».
Публикация будет дополняться по мере подготовки нового материала. Публикация не является «универсальной инструкцией».

Update 3. Права доступа. 14.08.2013
Update 4. Добавлен раздел 0. Дополнен раздел 4. Добавлен раздел 7. Внесены поправки, актуализирована информация. 23.11.2013.

1 стартмани

Контрольная точка

При выполнении контрольной точки (CHECKPOINT) – принудительно сбрасываются на диск все грязные страницы, которые есть в буферном кэше. Это гарантирует что на момент контрольной точки все данные сбросились на диск и при восстановлении данных нужно читать не весь журнал WAL, а только ту часть которая была сделана после последней контрольной точки.

Сброс данных при контрольной точке не проходит моментально, это бы сильно нагрузило наш сервер. Чтобы не было пиковых нагрузок сброс идет примерно 50% времени от времени между контрольными точками. Например, контрольные точки делаются каждую минуту, тогда сброс осуществляют плавно в течении 30 секунд. Это регулируется и вы можете установить например 90% времени.

Контрольная точка также уменьшает размер необходимого дискового пространства. Так как весь журнал WAL не нужен, его можно периодически подрезать.

Отдельный серверный процесс контрольных точек автоматически выполняет контрольные точки с заданной частотой. Эту частоту можно настроить следующими параметрами:

checkpoint_timeout – период выполнения контрольных точек в секундах;
max_wal_size – максимальный размер, до которого может вырастать WAL во время автоматических контрольных точек;
checkpoint_completion_target – время для завершения процедуры контрольной точки, как коэффициент для общего времени между контрольными точками. По умолчанию это значение равно 0.5.

Значения по умолчанию: 5 минут и 1 Гбайт, соответственно. Если после предыдущей контрольной точки новые записи WAL не добавились, следующие контрольные точки будут пропущены, даже если проходит время checkpoint_timeout. Также можно выполнить контрольную точку принудительно, воспользовавшись SQL-командой CHECKPOINT.

Уменьшение значений checkpoint_timeout и max_wal_size приводит к учащению контрольных точек. Но появляется дополнительная нагрузка на сервер.

Администрирование конфигураций 1С (недокументированные особенности работы)

Многие мои коллеги по работе и по профессии, уверен, сталкиваются с аналогичными ситуациями, когда программа 1С при работе с конфигурацией, мягко говоря, работает «странно». Как говорит один хороший знакомый (к слову, один из авторов УТ 11):
— «вот, ну согласись, нанять пару серьезных методистов — реальных дядечек с реального производства, до начала разработки — единственная ЭЛЕМЕНТАРНАЯ политика, как можно было этого не сделать???? там их НЕТ. Причем это 0 в плане затрат на разработку, там нет ограничений бюджета, это просто самый тупой прокол.»
В этой статье приведу способы лечения пресловутых проколов (за последний месяц).

Псевдо роль public

Псевдо роль public не видна, но про неё следует знать. Это групповая роль, в которую включены все остальные роли. Это означает, что все роли по умолчанию будут иметь привилегии наследуемые от public. Поэтому иногда у public отбирают некоторые привилегии, чтобы отнять их у всех пользователей.

Роль public по умолчанию имеет следующие привилегии:

для всех баз данных:
- CONNECT – это означает что любая созданная роль сможет подключаться к базам данных, но не путайте с привилегией LOGIN;
- TEMPORARY – любая созданная роль сможет создавать временные объекты во всех база данных и объекты эти могут быть любого размера;
для схемы public:
- CREATE (создание объектов) – любая роль может создавать объекты в этой схеме;
- USAGE (доступ к объектам) – любая роль может использовать объекты в этой схеме;
для схемы pg_catalog и information_schema
USAGE (доступ к объектам) – любая роль может обращаться к таблицам системного каталога;

:
для всех функций

EXECUTE (выполнение) – любая роль может выполнять любую функцию. Ещё нужны ещё права USAGE на ту схему, в которой функция находится, и права к объектам к которым обращается функция.

:

Это сделано для удобства, но снижает безопасность сервера баз данных.

Шаг 3. Настройте базу данных PostgreSQL для включения SCRAM-SHA-256

Теперь, когда SSL включен и работает в соответствии с настройками, давайте добавим еще один уровень безопасности, включив аутентификацию по паролю SCRAM-SHA-256. Это очень простой процесс. Сначала откройте основной файл конфигурации postgresql и измените строку ниже, как показано.

Как только это будет сделано, нам нужно заставить клиентов аутентифицироваться по этой новой схеме, отредактировав файл pg_hba.conf, как показано ниже. Вы заметите, что все вхождения md5 были заменены на scram-sha-256.

Чтобы сохранить изменения, которые мы сделали до сих пор, нам нужно перезапустить службу PostreSQL следующим образом:

После внесения этих изменений нам придется обновить пароли для всех пользователей в вашей базе данных, иначе вы не сможете войти в систему. Для этого войдите в свою базу данных следующим образом. У вас должны быть права sudo ..

Затем запустите команду пароля, например, и нажмите клавишу ВВОД. Вам будет предложено дважды ввести пароль. Вы можете ввести тот же пароль, что и раньше. Теперь он будет зашифрован с использованием новой схемы scram-sha-256 .

Как только это будет сделано, останется только добавить сертификаты в клиентские приложения. Для систем * nix вы можете разместить сертификат клиента в каталоге $ {user.home} /. Postgresql / . Как встраивать сертификат клиента в различные приложения, написанные на разных языках, выходит за рамки этого руководства. Пример для Java представлен в документации PostgreSQL JDBC.

При подключении с помощью драйвера JDBC строка подключения должна соответствовать следующему формату. Обратите внимание на добавленную опцию ssl=true

Просмотр заблокированных строк в 1С

Ввиду своей деятельности, мне часто приходится рассказывать про различные аспекты оптимизации и в том числе про блокировки.
Очень часто слушатели задают следующие вопросы:
Как посмотреть в реальном времени, какие именно данные сейчас заблокированы?
Как понять, что сейчас заблокировано в терминах 1С?
Если гранулярность блокировки страница, как увидеть, какие данные в ней находятся?

Раньше приходилось отвечать, что инструмента, который показывает все вышеописанное, сейчас просто нет. Но потом мне это надоело, и я решил сделать собственный инструмент, который позволяет ответить на все вышеописанные вопросы.

1 стартмани

25.10.2016
48073
863
Andreynikus

Понимание модели клиент-сервер

Я уже упоминал PostgreSQL Server как важный компонент базы данных. Но что такое сервер в этом контексте и зачем он нам нужен?

Для начала тебе необходимо понимать модель клиент-сервер.

Почти все СУБД (PostgreSQL, MySQL и другие) следуют клиент-серверной модели. В ней база данных находится на сервере, и клиент
отправляет запросы на сервер, который их обрабатывает.

Под клиентом здесь подразумевается бекэнд нашего приложения, а запросы в — это SQL операции, такие как SELECT, INSERT, UPDATE и DELETE.

Для разработки любого бекэнда, тебе нужен локальный сервер для экспериментов и тестирования.
Этот локальный сервер аналогичен удаленному, но работает прямо на твоем компьютере.

С точки зрения клиента удаленный и локальный сервер идентичны. После разработки и тестирования ты можешь заставить свой
продукт взаимодействовать с удаленным сервером вместо локального, просто изменив пару параметров.

Некоторые базы данных не используют эту модель, например SQLite, которая хранит все в простом файле на диске. Это хорошо
работает для небольших приложений, но для большинства реальных приложений тебе понадобится архитектура клиент-сервер.

Выявляем и оптимизируем ресурсоемкие запросы 1С:Предприятия

Обычно предметом оптимизации являются заранее определенные ключевые операции, т.е. действия, время выполнения которых значимо для пользователей. Причиной недостаточно быстрого выполнения ключевых операций может быть неоптимальный код, неоптимальные запросы либо же проблемы параллельности. Если выясняется, что основная доля времени выполнения ключевой операции приходится на запросы, то осуществляется оптимизация этих запросов.
При высоких нагрузках на сервер СУБД в оптимизации нуждаются и те запросы, которые потребляют наибольшие ресурсы. Такие запросы не обязательно связаны с ключевыми операциями и заранее неизвестны. Но их также легко выявить и определить контекст их выполнения, чтобы оптимизировать стандартными методами.

Сервер 1С:Предприятие на Ubuntu 16.04 и PostgreSQL 9.6, для тех, кто хочет узнать его вкус. Рецепт от Капитана

Если кратко описать мое отношение к Postgres: Использовал до того, как это стало мейнстримом.
Конкретнее: Собирал на нем сервера для компаний среднего размера (до 50 активных пользователей 1С).
На настоящий момент их набирается уже больше, чем пальцев рук пары человек (нормальных, а не фрезеровщиков).
Следуя этой статье вы сможете себе собрать такой же и начать спокойную легальную жизнь, максимально легко сделать первый шаг в мир Linux и Postgres.
А я побороться за 1. Лучший бизнес-кейс (лучший опыт автоматизации предприятия на базе PostgreSQL).
Если, конечно, статья придется вам по вкусу.

Варианты запуска очистки

Очищать таблицы или базы данных от ненужных версий строк можно с помощью следующих команд:

– очищает таблицу;
– базу данных;
– обёртка для использования в ОС.

Процедура VACUUM выполняется параллельно с другими транзакциями. При этом частый запуск нагружает систему, редкий запуск приводит к росту размера файлов. Подробнее почитать про очистку PostgreSQL можно тут. Мы уже встречались с понятием VACUUM в статье “Изоляция и многоверсионность в Postgresql“.

Дополнительно к этому существует процесс автоматической очистки AUTOVACUUM:

autovacuum launcher – следит за таблицами и в случае необходимости запускает autovacuum worker;
autovacuum worker – занимается очисткой таблиц.

Частота работы autovacuum worker зависит от частоты изменений таблицы. Чем активнее ведётся работа с таблицей, тем чаще туда приходит autovacuum. Autovacuum настраивается конфигурационными параметрами.

Как уже рассматривалось VACUUM и AUTOVACUUM не сжимает файл, а только очищает его образовывая в нем пустые пространства. Для полного перестроения файла, другими словами чтобы файл уменьшился, нужно использовать VACUUM FULL:

– очистка таблицы;
– очистка базы;
– обёртка для использования в ОС.

VACUUM FULL очищает таблицу и перезаписывает её в новый файл, при этом файл уменьшается в размере. Для этого на таблицу навешивают блокировку, поэтому на некоторое время таблица становится недоступной. Похожим образом работает TRUNCATE.

Команда TRUNCATE блокирует таблицу и очищает её, при этом старые версии строк не сохраняются и файл уменьшается физически. Другой способ очистить таблицу это выполнить DELETE всех строк в ней, а затем запустить по этой таблице VACUUM FULL для очистки. TRUNCATE это транзакционная команда, поэтому её можно отменить (ROLLBACK).

Понимание планов выполнения

Теперь, когда вы нашли несколько медленных запросов, самое время начать веселье.

EXPLAIN

Команда EXPLAIN, безусловно, обязательна при настройке запросов. Он говорит вам, что на самом деле происходит. Чтобы использовать его, просто добавьте к запросу EXPLAIN и запустите его. PostgreSQL покажет вам план выполнения, который он использовал.
При использовании EXPLAIN для настройки, я рекомендую всегда использовать опцию ANALYZE (EXPLAIN ANALYZE), поскольку она дает вам более точные результаты. Опция ANALYZE фактически выполняет оператор (а не просто оценивает его), а затем объясняет его.
Давайте окунемся и начнем понимать вывод EXPLAIN. Вот пример:

Узлы

Первое, что нужно понять, это то, что каждый блок с отступом с предшествующим «->» (вместе с верхней строкой) называется узлом. Узел — это логическая единица работы («шаг», если хотите) со связанной стоимостью и временем выполнения. Стоимость и время, представленные на каждом узле, являются совокупными и сводят все дочерние узлы. Это означает, что самая верхняя строка (узел) показывает совокупную стоимость и фактическое время для всего оператора

Это важно, потому что вы можете легко детализировать для определения, какие узлы являются узким местом.

Стоимость

Первое число — это начальные затраты (затраты на получение первой записи), а второе число — это затраты на обработку всего узла (общие затраты от начала до конца).
Фактически, это стоимость, которую, по оценкам PostgreSQL, придется выполнить для выполнения оператора. Это число не означает сколько времени потребуется для выполения запроса, хотя обычно существует прямая зависимость, необходимого для выполнения. Стоимость — это комбинация из 5 рабочих компонентов, используемых для оценки требуемой работы: последовательная выборка, непоследовательная (случайная) выборка, обработка строки, оператор (функция) обработки и запись индекса обработки

Стоимость представляет собой операции ввода-вывода и загрузки процессора, и здесь важно знать, что относительно высокая стоимость означает, что PostgresSQL считает, что ему придется выполнять больше работы. Оптимизатор принимает решение о том, какой план выполнения использовать, исходя из стоимости

Оптимизатор предпочитает более низкие затраты.

Фактическое время

В миллисекундах первое число — это время запуска (время для извлечения первой записи), а второе число — это время, необходимое для обработки всего узла (общее время от начала до конца). Легко понять, верно?
В приведенном выше примере потребовалось 55,009 мс для получения первой записи и 55,012 мс для завершения всего узла.

Узнать больше о планах выполнения

Есть несколько действительно хороших статей для понимания результатов EXPLAIN. Вместо того, чтобы пытаться пересказать их здесь, я рекомендую потратить время на то, чтобы по-настоящему понять их, перейдя к этим 2 замечательным ресурсам:

http://www.depesz.com/2013/04/16/explaining-the-unexplainable/
https://wiki.postgresql.org/images/4/45/Explaining_EXPLAIN.pdf

Работа с большими строками (TOAST)

В PostgreSQL одна строка должна помещаться в одну страницу, то есть не быть больше 8 КБ. Чтобы поместить большую строку у PostgreSQL есть следующие стратегии:

сжать большие атрибуты;
вынести большие атрибуты в отдельную служебную TOAST таблицу;
можно объединить оба способа.

Механизм работы с большими строками называется – TOAST. Внешняя таблица в которую по кусочкам помещают длинную строку называют TOAST-таблица.

TOAST-таблица имеет собственную версионность. Например, хранится у вас в такой табличке фотография сотрудника. Вы изменяете сотруднику фамилию, появляется новая версия длинной строки, но фотография в новую версию не копируется. Фотография в TOAST табличке остаётся в той-же версии. Просто новая версия строки (из обычной таблички) ссылается на туже самую фотографию. Это экономит место на диске и увеличивает скорость работы.

Разделение и склеивание длинных строк PostgreSQL делает самостоятельно, то есть вам не нужно обо всем этом задумываться. Вы просто пишите запрос (SELECT), а PostgreSQL склеивает из нескольких частей длинную строку.

Но про них нужно знать. Так как длинные строки обрабатываются отдельно, то это замедляет работу базы данных, но только при запросах к длинному атрибуту, например к фотографии.

TOAST-таблица имеет свою схему pg_toast. А если это временная таблица, то pg_toast_temp_N.

Если в табличке есть поле с типом, куда может поместиться большое значение (numeric, text и т.д.), то TOAST-таблица создается сразу (как бы на всякий случай). Но до помещения больших атрибутов в TOAST-таблицу, она будет пустой.

Выявляем и оптимизируем ресурсоемкие запросы 1С:Предприятия

Ротация жарналов

Если писать все в 1 файл, то постепенно он вырастит до огромных размеров. Поэтому лучше использовать некоторую схему ротации. Следующими параметрами можно настроить ротацию, если мы используем log_destination=stderr:

log_filename – может принять не просто имя файла, а маску имени. С помощью специальных символов можно указать текущее время;
log_rotation_age – задает время переключения на следующий файл в минутах;
log_rotation_size – задает размер файла, при котором нужно переключиться на следующий файл;
log_truncate_on_rotation – если включить (on) то вы разрешите серверу перезаписывать уже существующие файлы. Если выключить (off) – то файл не будет перезаписываться, записи будут писаться в конец файла.

Комбинируя все выше перечисленное, можно настроить некоторую схему ротации. Например:

log_filename = postgres-%H.log / log_rotation_age = 1h – 24 файла в сутки;
log_filename = postgres-%a.log / log_rotation_age = 1d – 7 файлов в неделю.

Опыт оптимизации и контроля производительности в БД с 3000 пользователей Промо

Данная статья написана по материалам доклада, прочитанного на Конференции Инфостарта IE 2014 29-31 октября 2014 года.

Меня зовут Сергей, являюсь руководителем отдела оптимизации и производительности систем в компании «Деловые линии».
Цель этого доклада – поделиться информацией о нашем опыте работы с большой базой на платформе 1С, с чем пришлось столкнуться, как удалось обеспечить работоспособность.
Уверен, что вам будет интересно, так как подобной информацией мало кто делится, да и про само существование таких систем их владельцы стараются не рассказывать, максимум про это «краем глаза» упоминают участвовавшие в проекте вендоры.
**update от 04.03.2016 по вопросам из комментариев

Автокликер для 1С

Внешняя обработка, запускаемая в обычном (неуправляемом) режиме для автоматизации действий пользователя (кликер). ActiveX компонента, используемая в обработке, получает события от клавиатуры и мыши по всей области экрана в любом приложении и транслирует их в 1С, получает информацию о процессах, текущем активном приложении, выбранном языке в текущем приложении, умеет сохранять снимки произвольной области экрана, активных окон, буфера обмена, а также, в режиме воспроизведения умеет активировать описанные выше события. Все методы и свойства компоненты доступны при непосредственной интеграции в 1С. Примеры обращения к компоненте представлены в открытом коде обработки.

1 стартмани