Различные пользователи на стороне СУБД

[DesertBrowser]

Добрый день.
Используем СУБД SQL Server 2000, Axapta 3.0, трёхзвенная архитектура.
Возможно ли настроить систему так, чтобы АОС для каждого пользователя открывал с сервером БД соединение от имени этого пользователя, а не от bmssa?
Возможно ли это реализовать при помощи конфигурационных файлов?
Необходим ли в таком случае запуск отдельного АОС под каждый конфигурационный файл, в котором прописывается отдельный Database user id?
Какие есть ещё способы реализации?

аос работает по 1 (или двум) соединениям.
Соответственно - нельзя.

[DesertBrowser]

Если для какого-то пользователя будет свой конфигурационный файл, где будет прописан отличный от bmssa Database User ID, приведёт ли это в текущем АОСе к созданию нового соединения с БД?
Кстати, программно с использованием объекта UserConnection можно открыть новое соединение с сервером БД. Может быть, используя ODBCConnection, можно как-то подменять открытое от имени bmssa соединение на своё, открытое от имени нужного пользователя?

нельзя. Только подключившись толстым клиентом/двузвенным клиентом

[DesertBrowser]

А то, что описано в статье, тоже относится к двухзвенке? Если да, тогда в силе вопрос о программной подмене/настройке текущего подключения

[Vadik]

Цитата:

Сообщение от DesertBrowser

Возможно ли настроить систему так, чтобы АОС для каждого пользователя открывал с сервером БД соединение от имени этого пользователя, а не от bmssa?

Предположим на секунду, что можно. А зачем ?

используйте "толстого" клиента в трехзвенке

[DesertBrowser]

Цитата:

Сообщение от Vadik

Предположим на секунду, что можно. А зачем ?

Для того, чтобы на стороне сервера БД можно было бы однозначно идентифицировать пользователя. Это даст удобство при использовании средств мониторинга текущей активности сервера БД (которые функциональнее, чем включенные в Аксапту, да и не требуют запущенной Аксапты на машине администратора и следовательно дополнительной лицензии), к которым можно отнести и Профайлер.

[Vadik]

Цитата:

Сообщение от DesertBrowser

Для того, чтобы на стороне сервера БД можно было бы однозначно идентифицировать пользователя

Зачем? Допустим, в приложении кривой код, который каждый раз инициирует table scan или открывает диалог в транзакции - решение этих проблем как-то зависит от того, кто этот код запустил? Если разноска Васей накладных занимает 80% процессорного времени, надо

• оштрафовать Васю на растрату корпоративных русурсов
• выдать Васе премию потому что он больше всех работает
• разобраться что не так с разноской инвойса

?

[AndyD]

Наверное, прийти к Васе и спросить, а што это было?

[fed]

Если уж помечтать, то хорошо было бы чтобы в Аксапте был какой-то отладочный режим (включемый и выключаемый динамически), который бы запрещал повторно использовать SPIDs пользователей. Тогда можно было бы посмотреть текущий SPID в Users Online и тупо трассировать SQL Profiler, зная, что при смене контекста транзации, этот SPID не будет назначен какому-то другому пользователю.

[Logger]

Цитата:

Сообщение от fed

Если уж помечтать, то хорошо было бы чтобы в Аксапте был какой-то отладочный режим (включемый и выключаемый динамически), который бы запрещал повторно использовать SPIDs пользователей. Тогда можно было бы посмотреть текущий SPID в Users Online и тупо трассировать SQL Profiler, зная, что при смене контекста транзации, этот SPID не будет назначен какому-то другому пользователю.

Может имеет смысл завести аос для отладок, включив на нем всевозможные логирования и запустив его в БД под отдельным юзером.
Хотя для случае когда несколько человек отладку ведут - это несильно поможет.

[DesertBrowser]

Цитата:

Наверное, прийти к Васе и спросить, а што это было?

Примерно да. Предположим, у меня есть трасса, собранная Профайлером. Из трассы я выбираю запросы, требующие больше других ресурсов сервера. Чтобы разобраться, в каком функционале реализованы эти запросы, надо провести расследование. И если бы имелась информация, кто инициировал выполнение этих операций, было бы легче найти первопричину.
Ещё хорошо было бы сгруппировать затраты процессорного ресурса и количество операций ввода-вывода из трассы по пользователям и выяснить, какой функционал больше нагружает систему и нуждается в оптимизации.
Также для задач администрирования (скажем просмотра блокировок) можно было бы не входить в Аксапту (не использовать лицензию), а пользоваться только средствами сервера БД.
Т.е. такая возможность была бы весьма полезна.

Цитата:

который бы запрещал повторно использовать SPIDs пользователей

А я почему-то всегда думала, что если у другого пользователя появляется такой же SPID, какой был ранее у другого, то потому, что АОС создал для другого пользователя новое подключение, а у предыдущего подключение удалил. Но сейчас проверила - и действительно, для пользователя, который зашёл в 8:30, назначен SPID со временем входа 8:15.
Но опять-таки, в чём тогда смысл в конфигурационном файле указывать Database User ID, если его процесс может быть передан другому пользователю?

все-таки мануал читать лишним не бывает

[DesertBrowser]

Цитата:

Сообщение от otkudao

все-таки мануал читать лишним не бывает

Может быть, подскажете, что именно и где нужно читать? Перед тем, как спрашивать на формуме, я читала мануал (трейнинг) именно по конфигурационным файлам, а также искала информацию в Интернете.

[Vadik]

Цитата:

Сообщение от DesertBrowser

Может быть, подскажете, что именно и где нужно читать? Перед тем, как спрашивать на формуме, я читала мануал (трейнинг) именно по конфигурационным файлам, а также искала информацию в Интернете.

- Документацию по сиквелу, чтобы разобраться в чем разница между User ID и Process ID
- Руководство администратора в части "толстого" трехуровнего клиента
- Help по Query profiler-у аксапты
- Если найдете, посмотрите в сторону спрятанного в конфигурационной утилите параметра -allowntauth

Цитата:

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

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

Администрирование
Axapta 3.0

[DesertBrowser]

Цитата:

в чем разница между User ID и Process ID

У серверного процесса есть реквизиты SPID и UserID. Один SPID создаётся под конкретного пользователя, который указывается в строке подключения при создании соединения. Когда пользователь закрывает соединение, его процесс(ы) уничтожаются. Если другой пользователь подключается позже, ему может быть выделен серверный процесс с номером, совпадающим с уже освободившимся. Но реквизит "пользователь" у этого серверного процесса будет другим.
Т.о. в одном соединении пользователя может быть несколько серверных процессов, объединённых одним UserID. Но один серверный процесс не может относиться к разным соединениям, а следовательно и пользователям. Номера (SPID) процессам, создающимся позже, могут присваиваться из числа уже освободившихся, поэтому одинаковые номера вовсе не свидетельствуют о том, что процесс один и тот же.
Т.к. АОС соединяется с сервером БД под одним пользователем, понятно, что в АОСе может храниться несколько соединений от имени этого пользователя, и когда от клиентских приложений в АОС поступают запросы, АОС выбирает объект-команду, ассоциированный с одним из соединений, и используя его отправляет запрос к серверу БД.
Поэтому я и предположила, что если с использованием конфигурационного файла открывается соединение от имени указанного в утилите Database User ID, а потом механизм АОСа использует это соединение для выполнения команд другого пользователя Аксапты, то это привело бы к путанице и мне бы не подошло
Возможно, предположение и было ошибочным.
Толстый трёхуровневый клиент не подойдёт нам для массового использования.
Справку по Профайлеру читала.
Параметр -allowntauth буду искать

Администрирование
Axapta 3.0 - как раз по нему и изучала конфигурационную утилиту. Читала весь от начала до конца, возможно не заметила ссылки, где говорится об использовании параметра Database User ID только для толстых клиентов?

там указано, что толстый клиент имеет свое отдельное соединение с базой.

У тонкого такой возможности нет. И это тоже явно прописано. И, кажется, закладка с Database User ID у него блокируется при переходе 2-узвенный/толстый -> тонкий. Если не блокируется, то увы .

[Андре]

Цитата:

Vadik:Зачем? Допустим, в приложении кривой код, который каждый раз инициирует table scan или открывает диалог в транзакции - решение этих проблем как-то зависит от того, кто этот код запустил? Если разноска Васей накладных занимает 80% процессорного времени, надо

Ну, скажем, периодически возникают ситуации, когда я бы хотел более гибко управлять ресурсами SQL Server'а и использовать Resource Governor. При создании функции-классификатора я должен опираться на какие-то данные, для того, чтобы ассоциировать текущую сессию с той или иной группой загрузки и идентификатор пользователя для этого очень удобен.