Собствено сабж.

Штатная не устраивает тем, что долго работает при сколь нибудь больших объемах данных.

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

pailThe Dim!Все ссылки на произвольный объект (элемент справочника, документ, перечисление, счет... в общем на все что можно сослаться) конфигурации - для типовых, без доработок самой конфигурации.
... а перед этим надо пробежаться по каждому реквизиту всех метаданных, и отобрать все N из них,которые могут содержать такую ссылку - все типа "тип.ТакойТо", все составные, которые этот тип включают, все типа "любая ссылка"....
А потом либо один запрос строить, с объединением N подзапросов, либо результаты N отдельных запросов объединять.

.... ииии?

Как варинат да, это самый простой (в смысле что первое в голову пришло) - наверное. Хотя сама платформа, наврное, так же работает. И вряд ли прирост в скорости будет ощютимый.
Но может кто уже дела что-то такое?

А интересно, полнотекстный поиск нельзя к этому приспособить, что бы искал GUID объекта в полях-ссылках - хотя, по скорости тоже "не фаетан".
Или может как-то можно вытащить "связи" таблиц. Тогда понятно в каких "таблицах" и в каких "полях" искать.

Программист 1сThe Dim!Все ссылки на произвольный объект (элемент справочника, документ, перечисление, счет... в общем на все что можно сослаться) конфигурации - для типовых, без доработок самой конфигурации.А зачем? В чем задача?

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

Зачем поиск?
Было-бы интересно посмотреть, сколько в базе элементов справочников на которых нет ссылок - это раз. Второе - для отчета по элементам/документам которые помечены на удаление...
Да и просто для подсчета статистики использования того или иного элемента справочников...

pailThe Dim!А интересно, полнотекстный поиск нельзя к этому приспособить, что бы искал GUID объекта в полях-ссылках - хотя, по скорости тоже "не фаетан".


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

Я имел в виду под "GUID" - ID объекта в базе. Ведь если есть ссылка на объект, то она будет именно через ID - ну или как он там щас у 1С называется.
Это поле из конфигуратора не видно... да и что-то дорабатывать для этого крайне не хочется.

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

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

Статистик хочу видеть в трех видах.

1. Количество документов, элементов, помеченных на удаление, не проведенных - это каждый час.
2. Статистик по ссылка - раз в сутки.
3. Статистику по пользователям. Лог не устраивает по скорости доступа, хочу все в одной базе.

Потом еще статистику из SQL хочу подтянуть и из WMI - счетчики по процу, винту, оперативке, свопу.

Программист 1сThe Dim!1. Количество документов, элементов, помеченных на удаление, не проведенных - это каждый час.Зачем?

Почему нельзя взять любую неделю и проанализировать логи? Зачем в текущем режиме тормозить работу базы бесполезными задачами?

Да и в скуле - ставьте уж ВСЕ счетчики, тогда точно база умрет.


ps Анализ нужен - когда тормозит. А анализ ради анализа...

Ну зачем же так кардинально-радикально :)

"ВСЕ" счетчики точно включать не буду - пару/тройку. А из SQL нужны данне о блокировках, физическом размере таблиц и их фрагментации.
Это не нагрузит систему так что бы её убить.

AHDP The Dim!, создатйте себе в базе 1-2 таблички и перекладываете туда агрегированные данные из лога. Данные агрегируйте по интервалам в 5-15 минут. Прочитать несколько раз в час лог назад на несколько минут - нагрузка не очень существенная.

Лог за 15 минут не проанализировать - на предмет того, сколько документов было создано за последний час, сколько добавлено элементов справочника.
А вот если нужна будет "расшифровка" такой статистики, тогда да, можно и в лог заглянуть.

Как отметил выше AHDP анализировать во время тормоза... ничего не даст. Он уже есть.
А вот попытаться дать прогноз на подобные ситуации это совсем иной разговор...

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

AHDPThe Dim!, Если вы не можете за 15 минут проанализировать лог за последний час - то у вас с вероятностью 95% проблема с дисковой подсистемой ;) Оставщиеся 5% на проц.

Чесно говоря, не побывал.

AHDPPS А не пытаетесь ли вы повторить 1С:Центр Управления Производительностью?

Все никак руки не дойдут до него - а он собирает статистику такого рода или есть в нем возможность анализа лога?
Да и стоимость не радует.

Там ведь - насколько я знаю - ничего своего 1С не добавляло. Все на счетчиках винды/SQL, WMI и объектной модели сервера приложений...

В общем не знаю, может и велосипед изобретаю... ну попробую в любом случае, да и это велосипед будет заточен под меня.