Администратор БД хочет видеть пользователя автора или компьютер источник запроса

parcan

Новичок
Стандартная трехзвенная конфигурация 1С 8.2 с использованием сервера приложений и SQL Server2008R2 в качестве БД. Администраторы БД требуют транслировать при создании подключения параметры Windows пользователя – имя и, возможно, ip.

В консоли управления 1с в разделе "Сеансы" для каждого "Соединение с СУБД" видны "Сервер", "Компьютер", "Пользователь".
В SQL Server Profiler для каждого запроса "Соединение с СУБД", "ApplicationName", "HostName/Сервер".
Сейчас сопоставить пользователя получается только во время выполнения запроса - посмотреть номер соединения в профайлере и быстро посмотреть кто ему соответствует в консоли 1с.

Может ли сервер 1с при соединении с SQL каким-то образом передавать для каждого "Соединение с СУБД" еще "Компьютер" или "Пользователь"?
Существуют ли какие либо способы идентифицировать пользователя автора или компьютер источник запроса в SQL Server Profiler при стандартной трехзвенной конфигурации 1С 8.2 с использованием сервера приложений и SQL Server2008R2 в качестве БД?
 

Andrey

ВР
Команда форума
Нет. К СУБД сервер подключается по одним пользователем. Он указывается в параметрах БД в консоли сервера предприятия.
Собственно, а чего вдруг такая параноя на стороне СУБД? Хотите отловить сторонние подключения? Или логировать кто, с кем и как? Для второго достаточно журнала регистрации 1С.
 

parcan

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

Andrey

ВР
Команда форума
И, ну найдет он этого пользователя? Что дальше? Судя по всему с 1С он знаком очень даже шапочно. Вопросы нагрузки на СУБД нужно решать на стороне приложения, в данном случае 1С, и тем человеком который знает как работает и устроено внутри данное приложение. Приглашайте специалистов.
 

parcan

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

Владимир Владимирович

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

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

parcan

Новичок
А как вы определяете оптимален ли запрос, нужен ли индекс, какую нагрузку дает и т.д., я со стороны 1с исключительно методом псевдонаучного предположения, а DBA по каким-то критериям, при этом он просто констатирует что для этой БД это плохо, а это пофигу.
 

Владимир Владимирович

Известная личность
А как вы определяете оптимален ли запрос, нужен ли индекс, какую нагрузку дает и т.д., я со стороны 1с исключительно методом псевдонаучного предположения, а DBA по каким-то критериям, при этом он просто констатирует что для этой БД это плохо, а это пофигу.

Определяется путем тестирования и оптимизации кода 1с, вопрос о том, могут ли пользователи запускать этот запрос в определенное время остается открытым :)
 

parcan

Новичок
Запрос выполняется 1 секунду и практически не потребляет разделяемых ресурсов Сервера БД и запрос выполняется 1 секунду и потребляет значительную часть разделяемых ресурсов.
Запрос выполняется 1 минуту и практически не потребляет разделяемых ресурсов Сервера БД и запрос выполняется 1 минуту и потребляет значительную часть разделяемых ресурсов.
Грубо я со стороны 1с вижу только первую часть и оптимизирую ее, а DBA может рассказать про вторую часть.
 

Andrey

ВР
Команда форума
А как вы определяете оптимален ли запрос, нужен ли индекс, какую нагрузку дает и т.д., я со стороны 1с исключительно методом псевдонаучного предположения, а DBA по каким-то критериям, при этом он просто констатирует что для этой БД это плохо, а это пофигу.

Самый простой способ - замер производительности в отладчике.
У Вас объем БД какой? Какая конфигурация? Типовая или доработанная? Сколько пользователей работает? Есть ли блокировки? Как часто они возникают? Если проведение документов - оптимально по времени, но отчеты выполняются долго - оптимизировать нужно запросы на основании которых строятся выборки данных отчетов.
Вообще вопрос оптимизации - оооооочень многогранен, и начинать его со стороны СУБД..... ну я бы не стал. Я бы, для начала, локализовал сами проблемы производительности на стороне приложения.
 

Andrey

ВР
Команда форума
Запрос выполняется 1 секунду и практически не потребляет разделяемых ресурсов Сервера БД и запрос выполняется 1 секунду и потребляет значительную часть разделяемых ресурсов. Запрос выполняется 1 минуту и практически не потребляет разделяемых ресурсов Сервера БД и запрос выполняется 1 минуту и потребляет значительную часть разделяемых ресурсов. Грубо я со стороны 1с вижу только первую часть и оптимизирую ее, а DBA может рассказать про вторую часть.
А при чем тут конкретный пользователь? Основная масса запросов будет одинаково выполнятся для ВСЕХ пользователей. Разница появляется тогда когда включается RLS. Тут да - скорость может резко упасть. Но это опять же не проблема на стороне СУБД, а проблема в конфигурации приложения. Потом, Вы же знаете какой именно запрос потребляет много ресурсов сервера - вот его и оптимизируйте.
Сетевые пользователи тут вообще не при чем.
 

parcan

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

Andrey

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

parcan

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

Andrey

ВР
Команда форума
На стороне СУБД Вы это не решите и не определите. Все проблемы настроек - это исключительно квалификация пользователя и его ответственность.
 

parcan

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