Галактика в вопросах и ответах

Добрый день!
В системе 427 активных учетных записи, пересчет прав (безусловный) по ним шел 10 часов, насколько это приемлемо?
и какие есть средства для оптимизации этого процесса?
Спасибо!

Только использование ролей:
[SQLDriver]
ForceRights=on
UseSQLRole=on
Для >3000 пользователей полный пересчёт занимает порядка 2 часов, но требуется нечасто (хотя "гал" последние годы увлеклась докомпиляцией БД, после чего необходим пересчёт прав всех пользователей).

pk писал(а):Только использование ролей:
[SQLDriver]
ForceRights=on
UseSQLRole=on
Для >3000 пользователей полный пересчёт занимает порядка 2 часов, но требуется нечасто (хотя "гал" последние годы увлеклась докомпиляцией БД, после чего необходим пересчёт прав всех пользователей).

Реализовал использование ролей на тестовой БД, действительно процесс пересчета стал занимать минуты, но хотелось бы понять как Галактика понимает что нужно работать именно с ролями SQL, мы же не прописываем UseSQLPole в конфигурационном файле пользователя Галактики, а только в Supporte, верно?

Приветствую.

Подмечено верно.
Однако Галактике и не нужно знать на каком уровне и каким способом тому или иному пользователю (учетке) выданы права на тот или иной объект в БД.
Она этого никак не "понимает".
Главное, что право или привилегия есть.

В момент разбора запросов от клиента сервер оценивает его права и привилегии, собранные из всех возможных "источников", если можно так сказать, в своем словаре.
Своем СИСТЕМНОМ словаре.

А Галактика, если и оценивает допустимые пользователю деяния, то по своему прикладному словарю, и то только в части ФУНКЦИОНАЛЬНЫХ возможностей прикладной части.

Ну а вот сапорту и чеке нужно знать КАКИМ именно образом выдавать права и привилегии НА УРОВНЕ СЛОВАРЯ СУБД, тому или иному пользователю.

При чём, замечу, что в принципе, одному пользователю права могут быть розданы непосредственно на его персональную роль клонированием прав из группы (считали с параметром USESQLRole=OFF), а потом параметр поменяли на ON и посчитали не всех, а несколько других пользователей - и им права раздадутся через групповые роли.
И все они будут работать с точки зрения СУБД совершенно одинаково - на сессию действуют права, суть которых, конкатенация всех выданных прав всеми возможными способами.

(по секрету - если на уровне СУБД дать юзеру ДБА и не дать прав на таблицы через сапорт, то все в Галактике будет работать, хотя Галактика формально ему прав и не давала - главное, чтобы на функционалы права были выданы )

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


Как-то так

AlexMK писал(а):Приветствую.

Подмечено верно.
Однако Галактике и не нужно знать на каком уровне и каким способом тому или иному пользователю (учетке) выданы права на тот или иной объект в БД.
Она этого никак не "понимает".
Главное, что право или привилегия есть.

В момент разбора запросов от клиента сервер оценивает его права и привилегии, собранные из всех возможных "источников", если можно так сказать, в своем словаре.
Своем СИСТЕМНОМ словаре.

А Галактика, если и оценивает допустимые пользователю деяния, то по своему прикладному словарю, и то только в части ФУНКЦИОНАЛЬНЫХ возможностей прикладной части.

Ну а вот сапорту и чеке нужно знать КАКИМ именно образом выдавать права и привилегии НА УРОВНЕ СЛОВАРЯ СУБД, тому или иному пользователю.

При чём, замечу, что в принципе, одному пользователю права могут быть розданы непосредственно на его персональную роль клонированием прав из группы (считали с параметром USESQLRole=OFF), а потом параметр поменяли на ON и посчитали не всех, а несколько других пользователей - и им права раздадутся через групповые роли.
И все они будут работать с точки зрения СУБД совершенно одинаково - на сессию действуют права, суть которых, конкатенация всех выданных прав всеми возможными способами.

(по секрету - если на уровне СУБД дать юзеру ДБА и не дать прав на таблицы через сапорт, то все в Галактике будет работать, хотя Галактика формально ему прав и не давала - главное, чтобы на функционалы права были выданы )

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


Как-то так

Спасибо большое! Вы для меня все окончательно прояснили! Я Вам очень благодарен!

Если установить
UseSQLRole=on
Надо еще что то где то настраивать ?

maikl писал(а):Если установить
UseSQLRole=on
Надо еще что то где то настраивать ?

1) Установить в конфигурационном файле комплекса Support параметры
SQLDriver.UseSQLRole = True
SQLDriver.ForceRights = True

2) Запустить Support и выполнить перерасчет прав на БД для всех пользователей и групп, установив в окне "Параметры расчета прав на БД" флаги:
1. безусловный пересчет
2. пересчет прав членов группы (если выполняется расчет прав групп)
или
2. пересчет прав иерархии групп пользователя (если выполняется расчет прав пользователей)
3. пересчитывать вхождение в группы

3) Для платформы MS SQL Server приведение привилегий пользователей в соответствие рассчитанным с учетом прав ролей групп при необходимости нужно выполнить внешними средствами.

После расчета прав, выполните проверку таблиц БД в модуле Восстановление БД с параметрами "Проверка пользователей и прав".
​Параметры проверки:
​Проверка контрольной суммы
Проверка структуры таблиц, проверка корректности индексов, проверка корректности триггеров, проверка мемо-полей

Спасибо
3-й пункт непонятен. Что такое внешними средствами ?

maikl писал(а):Спасибо
3-й пункт непонятен. Что такое внешними средствами ?

SQL Server Management Studio например

Chernikov писал(а):

maikl писал(а):Спасибо
3-й пункт непонятен. Что такое внешними средствами ?

SQL Server Management Studio например

А какой скрипт запускать и где его брать ?

maikl писал(а):

Chernikov писал(а):

maikl писал(а):Спасибо
3-й пункт непонятен. Что такое внешними средствами ?

SQL Server Management Studio например

А какой скрипт запускать и где его брать ?

нужно будет удалять роли старого типа в СУБД средствами Management Studio MS SQL Server
Так как в инструкции сказано о UseSQLRole - Рекомендуется устанавливать требуемое значение параметра до начала настройки СРПД , потому что при смене значений в процессе эксплуатации и последующем пересчете прав, поли нового типа в СУБД создадутся, а старого не удаляться.
Это не обязательная процедура, старые роли лучше не удаляйте. Ни на что не влияет.
Главное, чтобы не было индивидуальных прав в Правах доступа.

Добрый день! При существовании у пользователя индивидуальных и групповых прав они суммируются. А если права противоречивы, то у каких будет приоритет?

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

edward_K писал(а):Если вы про протект, то будут предоставлены максимально возможные. Если одни по чтению, а другие по записи, права получит по записи.
В протекте можете посмотреть отчет по рассчитанным правам пользователя. SQL должен сработать также.

Спасибо, понял! При использовании sql ролей для прав пользователей задался вопросом - почему в документации написано: Главное, чтобы не было индивидуальных прав в Правах доступа?
Поэтому и возник вопрос, что происходит с противоречивыми правами, если одни групповые, а другие индивидуальные