В этом топике будет размещаться информация об особенности администрирования инструментальной части в разрезе слабо документированной, но широко используемой, и зачастую используемой с заблуждениями, функциональности.
Следующий планируемый выпуск посвящён запретительным и разрешительным правам.
Аналогичные тематические вопросы, требующие освещения, пока размещайте в комментах.
Так же в комментах размещайте вопросы к написанному.
Планируется по ходу ответов на вопросы тереть комменты, дабы не засорять эфир.
Сложные или заведомо нетематические вопросы предполагается выносить в отдельные топики.
Пока так. А там - будем посмотреть.
Это нужно знать: Инструментарий (Атлантис, Support, etc)
Модератор: mike
-
cruger
- топ-софт
- Сообщения: 566
- Зарегистрирован: Пт, 21/09/2007 15:19
- Имя Фамилия: Фёдор Терсин
- Откуда: Галактика Софт
- Контактная информация:
Это нужно знать: Инструментарий (Атлантис, Support, etc)
Последний раз редактировалось cruger Пн, 08/02/2010 19:18, всего редактировалось 3 раза.
-
cruger
- топ-софт
- Сообщения: 566
- Зарегистрирован: Пт, 21/09/2007 15:19
- Имя Фамилия: Фёдор Терсин
- Откуда: Галактика Софт
- Контактная информация:
Модификация словаря
Модификация словаря бывает прикладная - в обновления поставляются скрипты, которые надо запускать, и пользовательская - клиент сам решает, как ему нужно доработать стандартный словарь.
Пользовательская модификация словаря осуществляется простым запуском соответствующих запросов (create table, alter table etc), без оператора alter dictionary и параметра FullSQL. Или, что лучше для дизайнирования, из модуля Support-Консоль управления. При этом контрольная сумма остаётся такой же, какой была до этой модификации, т.е. пользовательские изменения словаря в расчёте контрольной сумме не учитываются. Занулять контрольную сумму словаря не надо.
С помощью пользовательской модификации можно не только создавать и изменять свои таблицы, но и:
- добавлять поля в конец стандартных таблиц;
- добавлять индексы к стандартным таблицам;
- добавлять сегменты индексов стандартных таблиц;
- удалять индексы стандартных таблиц;
- возможно (давно не проверял), удалять сегменты индексов стандартных таблиц.
Другие изменения структуры (полей, индексов) стандартных таблиц невозможны. Однако можно менять ссылочную целостность (как декларативную, так и ограничивающую) - к структуре она не относится.
Что даёт добавление полей, очевидно. Например - отказ от внешних атрибутов-классификаторов, что позволяет более просто и качественно добавлять свою логику. Но это более интересно программистам.
Манипуляции же с индексами более интересны администраторам. С одной стороны на поддержку индексов СУБД тратит определённые ресурсы. Чем больше индексов, тем больше БД, тем медленнее модификация, тем (на блокировочных СУБД) чаще конфликты изменений. С другой стороны - чем больше нужных индексов, тем быстрее поиск, да и сортировка работает.
Неиспользуемые индексы можно удалить (встаёт вопрос, как узнать о неиспользуемом индексе, но это тема для отдельного обсуждения). Используемые индексы можно доработать. Например, удалить неиспользуемые сегменты (тут, очевидно, вопрос тот же, только более сложного уровня). Более интересно - добавить свои сегменты в используемый индекс. Это может дать, например, более быстрый поиск в наложенных ограничениях, или автоматическую сортировку там, где её не предусмотрел разработчик. Наконец, добавление своего индекса часто оправдано при собственных доработках.
Пользовательскую докомпиляцию можно выполнять как из лицензируемых Support-Консоль управления (тут доступно GUI по изменению словаря), Support-SQL, так и из нелицензируемого (но штатно обновляемого!) консольного asql.
Для справки. Ограничения пользовательской докомпиляции не связаны с лицензионными или иными подобными ограничениями. Они связаны лишь с поддержкой корректности функционирования системы. Т.е., если вы хотите разломать свою систему, смело используйте alter dictionary & FullSQL. К сожалению, наши условия абонентского обслуживания несовершенны, и мы в любом случае будем пытаться разобраться в поломанной вами же базе.
Примечание. Известный хинт с занулением контрольной суммы связан с тем, что на Атлантисе 3.?? флаг пользовательского изменения словаря при расчёте контрольной суммы не учитывался. Он взводился, при самом изменении контрольная сумма не рассчитывалась, но при любом пересчёте она съезжала. Эта недоработка давным давно устранена.
Широко применяемая пользователями ошибочная практика alter dictionary & FullSQL связана, очевидно, с тем, что давным давно, когда часто происходила прикладная докомпиляция БД, пользователи, желающие выполнить пользовательскую докомпиляцию, предпочитали изучению документации смотреть исходники прикладной докомпиляции и делать так же, как там, не утруждая себя пониманием того, что же они делают.
Итого: забудьте про зануление контрольных сумм, alter dictionary и FullSQL - это инструменты для настоящих профессионалов (ака прикладные программисты), хехехе.
Модификация словаря бывает прикладная - в обновления поставляются скрипты, которые надо запускать, и пользовательская - клиент сам решает, как ему нужно доработать стандартный словарь.
Пользовательская модификация словаря осуществляется простым запуском соответствующих запросов (create table, alter table etc), без оператора alter dictionary и параметра FullSQL. Или, что лучше для дизайнирования, из модуля Support-Консоль управления. При этом контрольная сумма остаётся такой же, какой была до этой модификации, т.е. пользовательские изменения словаря в расчёте контрольной сумме не учитываются. Занулять контрольную сумму словаря не надо.
С помощью пользовательской модификации можно не только создавать и изменять свои таблицы, но и:
- добавлять поля в конец стандартных таблиц;
- добавлять индексы к стандартным таблицам;
- добавлять сегменты индексов стандартных таблиц;
- удалять индексы стандартных таблиц;
- возможно (давно не проверял), удалять сегменты индексов стандартных таблиц.
Другие изменения структуры (полей, индексов) стандартных таблиц невозможны. Однако можно менять ссылочную целостность (как декларативную, так и ограничивающую) - к структуре она не относится.
Что даёт добавление полей, очевидно. Например - отказ от внешних атрибутов-классификаторов, что позволяет более просто и качественно добавлять свою логику. Но это более интересно программистам.
Манипуляции же с индексами более интересны администраторам. С одной стороны на поддержку индексов СУБД тратит определённые ресурсы. Чем больше индексов, тем больше БД, тем медленнее модификация, тем (на блокировочных СУБД) чаще конфликты изменений. С другой стороны - чем больше нужных индексов, тем быстрее поиск, да и сортировка работает.
Неиспользуемые индексы можно удалить (встаёт вопрос, как узнать о неиспользуемом индексе, но это тема для отдельного обсуждения). Используемые индексы можно доработать. Например, удалить неиспользуемые сегменты (тут, очевидно, вопрос тот же, только более сложного уровня). Более интересно - добавить свои сегменты в используемый индекс. Это может дать, например, более быстрый поиск в наложенных ограничениях, или автоматическую сортировку там, где её не предусмотрел разработчик. Наконец, добавление своего индекса часто оправдано при собственных доработках.
Пользовательскую докомпиляцию можно выполнять как из лицензируемых Support-Консоль управления (тут доступно GUI по изменению словаря), Support-SQL, так и из нелицензируемого (но штатно обновляемого!) консольного asql.
Для справки. Ограничения пользовательской докомпиляции не связаны с лицензионными или иными подобными ограничениями. Они связаны лишь с поддержкой корректности функционирования системы. Т.е., если вы хотите разломать свою систему, смело используйте alter dictionary & FullSQL. К сожалению, наши условия абонентского обслуживания несовершенны, и мы в любом случае будем пытаться разобраться в поломанной вами же базе.
Примечание. Известный хинт с занулением контрольной суммы связан с тем, что на Атлантисе 3.?? флаг пользовательского изменения словаря при расчёте контрольной суммы не учитывался. Он взводился, при самом изменении контрольная сумма не рассчитывалась, но при любом пересчёте она съезжала. Эта недоработка давным давно устранена.
Широко применяемая пользователями ошибочная практика alter dictionary & FullSQL связана, очевидно, с тем, что давным давно, когда часто происходила прикладная докомпиляция БД, пользователи, желающие выполнить пользовательскую докомпиляцию, предпочитали изучению документации смотреть исходники прикладной докомпиляции и делать так же, как там, не утруждая себя пониманием того, что же они делают.
Итого: забудьте про зануление контрольных сумм, alter dictionary и FullSQL - это инструменты для настоящих профессионалов (ака прикладные программисты), хехехе.
Последний раз редактировалось cruger Вт, 02/02/2010 20:03, всего редактировалось 4 раза.
-
cruger
- топ-софт
- Сообщения: 566
- Зарегистрирован: Пт, 21/09/2007 15:19
- Имя Фамилия: Фёдор Терсин
- Откуда: Галактика Софт
- Контактная информация:
О ForceRights
Наверное каждому админу Галактики на SQL платформах приходилось слышать совет: включи ForceRights. Совет этот настолько распостранён, что применяется как стандартный магический ритуал, наряду с рекомендациями по удалению dsk и тому подобным процедурам. Больше того, косвенно приходилось сталкиваться с нежеланием отключать этот параметр! Дескать, без него всё глючит (как будто с ним всё работает безупречно, хехе).
На самом деле этот параметр редко когда нужен. И уж точно не нужен в обычной работе. Хотя бы потому, что расчёт прав при этом невозможно тормозит.
Процесс расчёта прав на SQL платформах двойной: помимо формирования записи в x$Rights с эффективными правами пользователя эти эффективные права отражаются в права пользователя на СУБД. Очевидно, если мы поменяли права доступа, допустим, на одну таблицу, то отражать и так ранее отражённые права на остальные таблицы не надо. Это в обычных условиях и не делается. И если БД поддерживается в корректном состоянии (например, никто не импортит настройки Протекта), то всё работает корректно.
Вообще права пользователя в СУБД несут факультативный характер, т.к. запросы, формируемые приложением, формируются на основе x$Rights. Иными словами, если вы в Протекте выставите для пользователя ограниченные права, а затем в СУБД сделаете его админом, то в Атлантис-приложениях админом этот пользователь не станет, и больше прав не получит.
С другой стороны - прав пользователя на СУБД должно быть достаточно для выполнения запросов. Т.е. права на СУБД должны быть не меньше, чем задано в Протекте.
С этой задачей в нормальных условиях функционирования вполне справляется Support в настройках по умолчанию - без ForceRights. Причём справляется быстро - при пересчёте прав анализирует отличия нового результата расчёта от старого, и эти отличия выдаёт/отнимает на СУБД.
Для чего же он нужен, этот ForceRights? Если у вас всё таки возникло несоответствие (точнее недостаток) реальных прав доступа рассчитанным (а симптомы этого очевидны - в логах SQL драйверов при этом пишутся характерные для нехватки прав ошибки СУБД), то в этом случае вы можете пересчитать права проблемному пользователю, включив этот параметр.
При включённом ForceRights рассчитываемые права пользователя перевыдаются в СУБД вне зависимости от того, какие они были раньше - никакого анализа нет. Безусловно отнимаются те права, которых нет, выдаются те, которые есть. Очевидно, поскольку процедура выдачи прав в СУБД весьма ресурсоёмка, расчёт прав с этим параметр работает часами.
Функциональность эта появилась ещё тогда, когда не было утилит проверки БД. Если бы эти утилиты были с самого начала, не было бы и этого параметра.
Надеюсь, вышесказанное исчерпывающе объясняет смысл параметра ForceRights. Используйте его пореже, только тогда, когда нужно, и процедура перерасчёта прав превратится для вас из утомительной рутины в элементарную незаметную операцию.
Наверное каждому админу Галактики на SQL платформах приходилось слышать совет: включи ForceRights. Совет этот настолько распостранён, что применяется как стандартный магический ритуал, наряду с рекомендациями по удалению dsk и тому подобным процедурам. Больше того, косвенно приходилось сталкиваться с нежеланием отключать этот параметр! Дескать, без него всё глючит (как будто с ним всё работает безупречно, хехе).
На самом деле этот параметр редко когда нужен. И уж точно не нужен в обычной работе. Хотя бы потому, что расчёт прав при этом невозможно тормозит.
Процесс расчёта прав на SQL платформах двойной: помимо формирования записи в x$Rights с эффективными правами пользователя эти эффективные права отражаются в права пользователя на СУБД. Очевидно, если мы поменяли права доступа, допустим, на одну таблицу, то отражать и так ранее отражённые права на остальные таблицы не надо. Это в обычных условиях и не делается. И если БД поддерживается в корректном состоянии (например, никто не импортит настройки Протекта), то всё работает корректно.
Вообще права пользователя в СУБД несут факультативный характер, т.к. запросы, формируемые приложением, формируются на основе x$Rights. Иными словами, если вы в Протекте выставите для пользователя ограниченные права, а затем в СУБД сделаете его админом, то в Атлантис-приложениях админом этот пользователь не станет, и больше прав не получит.
С другой стороны - прав пользователя на СУБД должно быть достаточно для выполнения запросов. Т.е. права на СУБД должны быть не меньше, чем задано в Протекте.
С этой задачей в нормальных условиях функционирования вполне справляется Support в настройках по умолчанию - без ForceRights. Причём справляется быстро - при пересчёте прав анализирует отличия нового результата расчёта от старого, и эти отличия выдаёт/отнимает на СУБД.
Для чего же он нужен, этот ForceRights? Если у вас всё таки возникло несоответствие (точнее недостаток) реальных прав доступа рассчитанным (а симптомы этого очевидны - в логах SQL драйверов при этом пишутся характерные для нехватки прав ошибки СУБД), то в этом случае вы можете пересчитать права проблемному пользователю, включив этот параметр.
При включённом ForceRights рассчитываемые права пользователя перевыдаются в СУБД вне зависимости от того, какие они были раньше - никакого анализа нет. Безусловно отнимаются те права, которых нет, выдаются те, которые есть. Очевидно, поскольку процедура выдачи прав в СУБД весьма ресурсоёмка, расчёт прав с этим параметр работает часами.
Функциональность эта появилась ещё тогда, когда не было утилит проверки БД. Если бы эти утилиты были с самого начала, не было бы и этого параметра.
Надеюсь, вышесказанное исчерпывающе объясняет смысл параметра ForceRights. Используйте его пореже, только тогда, когда нужно, и процедура перерасчёта прав превратится для вас из утомительной рутины в элементарную незаметную операцию.
-
cruger
- топ-софт
- Сообщения: 566
- Зарегистрирован: Пт, 21/09/2007 15:19
- Имя Фамилия: Фёдор Терсин
- Откуда: Галактика Софт
- Контактная информация:
Дамир Ибатуллин
Михаил Львович
Вообще этот топик задумывался как некое "развенчивание мифов", уточнение тонких неочевидных мест. А что неочевидного или непонятного в UseSQLRole? В документации вроде бы достаточно информации для применение. Само применение пока широко не распостранено, посему мне неизвестно о заблуждениях рядовых админов в отношении этого механизма. О чём писать-то?
Михаил Львович
Вообще этот топик задумывался как некое "развенчивание мифов", уточнение тонких неочевидных мест. А что неочевидного или непонятного в UseSQLRole? В документации вроде бы достаточно информации для применение. Само применение пока широко не распостранено, посему мне неизвестно о заблуждениях рядовых админов в отношении этого механизма. О чём писать-то?
-
mgl
- заказчик
- Сообщения: 178
- Зарегистрирован: Чт, 20/09/2007 07:40
- Имя Фамилия: Михаил Львович
- Откуда: Мелькомбинат
- Контактная информация:
Механизм новый, может потому и широко и не распространен, потому что мало о нем знаем.cruger писал(а):Дамир Ибатуллин
Михаил Львович
Вообще этот топик задумывался как некое "развенчивание мифов", уточнение тонких неочевидных мест. А что неочевидного или непонятного в UseSQLRole? В документации вроде бы достаточно информации для применение. Само применение пока широко не распостранено, посему мне неизвестно о заблуждениях рядовых админов в отношении этого механизма. О чём писать-то?
Хотелось бы конкретный пример.
И еще вопрос, есть настройка -сетевое имя- , не могу понять как этим воспользоваться, поле недоступно, у некоторых пользователей оно то заполнено, то нет.
Если не в тему, извините.
-
cruger
- топ-софт
- Сообщения: 566
- Зарегистрирован: Пт, 21/09/2007 15:19
- Имя Фамилия: Фёдор Терсин
- Откуда: Галактика Софт
- Контактная информация:
Михаил Львович
Не очень понятно, что значит "конкретный пример"?
Например:
1 Устанавливаете БД
2 Заводите группы
3 Заводите пользователей
4 Заводите права для групп
5 Раскидываете пользователей (некоторых или всех) по группам (при этом пользователь может входить в несколько групп)
6 Если необходимо, даёте дополнительные права пользователям; но лучше не надо
7 Включаете UseSQLRole и рассчитываете права
Устроит?
Не очень понятно, что значит "конкретный пример"?
Например:
1 Устанавливаете БД
2 Заводите группы
3 Заводите пользователей
4 Заводите права для групп
5 Раскидываете пользователей (некоторых или всех) по группам (при этом пользователь может входить в несколько групп)
6 Если необходимо, даёте дополнительные права пользователям; но лучше не надо
7 Включаете UseSQLRole и рассчитываете права
Устроит?
-
mgl
- заказчик
- Сообщения: 178
- Зарегистрирован: Чт, 20/09/2007 07:40
- Имя Фамилия: Михаил Львович
- Откуда: Мелькомбинат
- Контактная информация:
Нетcruger писал(а):Михаил Львович
Не очень понятно, что значит "конкретный пример"?
Например:
1 Устанавливаете БД
2 Заводите группы
3 Заводите пользователей
4 Заводите права для групп
5 Раскидываете пользователей (некоторых или всех) по группам (при этом пользователь может входить в несколько групп)
6 Если необходимо, даёте дополнительные права пользователям; но лучше не надо
7 Включаете UseSQLRole и рассчитываете права
Устроит?
Вы описываете как было раньше, а теперь появился UseSQLRole , зачем? , в чем принципиальное отличие, где выйгрыш и в чем ?
-
den
- заказчик
- Сообщения: 117
- Зарегистрирован: Пт, 26/10/2007 14:16
- Имя Фамилия: Денис Кучин
- Откуда: Геомостпроект НПО
Цитаты из документа, предоставленного ТП официально мне году где то в 2003 :
.............
С целью ускорения работы MSSQL сервера, а также всего ПК «Галактика» вводится новый режим – «раздача прав пользователей через MSSQL роли», далее РЕЖИМ.
Раньше при создании в support’е групп и выдачи им прав, реальные права (права в MSSQL сервере) выдавались каждому пользователю. Это приводило к тому, что неиндексированные системные таблицы MSSQL - sysprotects и syspermissions содержали слишком большое количество записей (росшее пропорционально количеству пользователей), в результате чего MSSQL сервер тратил на работу с ними практически все доступное процессорное время, а не на обслуживание запросов от ПК «Галактика»
После включения РЕЖИМА, в MSSQL стали создаваться роли (симметрично группам support’а) и все права support групп стали выдаваться этим ролям. При занесении пользователей в support группы – пользователи заносятся в соответствующие MSSQL роли. В результате количество записей в вышеперечисленных таблицах резко уменьшается и не зависит напрямую от количества пользователей, а MSSQL сервер занимается только обработкой запросов от ПК «Галактика»
Включение режима использования SQL ролей
Если группы уже созданы и через них выданы права:
1. Удалить у всех ролей GR#…. в MSSQL все права на таблицы используя Enterprise Manager или выполнив в Query Analyzer скрипт «drop_r.sql»
2. У каждого администратора, который будет администрировать БД, в support.cfg установить параметр UseSQLRole = on в секции SQLDriver
......
.............
С целью ускорения работы MSSQL сервера, а также всего ПК «Галактика» вводится новый режим – «раздача прав пользователей через MSSQL роли», далее РЕЖИМ.
Раньше при создании в support’е групп и выдачи им прав, реальные права (права в MSSQL сервере) выдавались каждому пользователю. Это приводило к тому, что неиндексированные системные таблицы MSSQL - sysprotects и syspermissions содержали слишком большое количество записей (росшее пропорционально количеству пользователей), в результате чего MSSQL сервер тратил на работу с ними практически все доступное процессорное время, а не на обслуживание запросов от ПК «Галактика»
После включения РЕЖИМА, в MSSQL стали создаваться роли (симметрично группам support’а) и все права support групп стали выдаваться этим ролям. При занесении пользователей в support группы – пользователи заносятся в соответствующие MSSQL роли. В результате количество записей в вышеперечисленных таблицах резко уменьшается и не зависит напрямую от количества пользователей, а MSSQL сервер занимается только обработкой запросов от ПК «Галактика»
Включение режима использования SQL ролей
Если группы уже созданы и через них выданы права:
1. Удалить у всех ролей GR#…. в MSSQL все права на таблицы используя Enterprise Manager или выполнив в Query Analyzer скрипт «drop_r.sql»
2. У каждого администратора, который будет администрировать БД, в support.cfg установить параметр UseSQLRole = on в секции SQLDriver
......
-
mgl
- заказчик
- Сообщения: 178
- Зарегистрирован: Чт, 20/09/2007 07:40
- Имя Фамилия: Михаил Львович
- Откуда: Мелькомбинат
- Контактная информация:
А это в описании Support_RES_54260.txt (Видимо новое это хорошо забытое старое )
ПРОБЛЕМА В ПИР: 103.3702
* ПЕРВОЕ РЕШЕНИЕ: 5.4.25.0
* КРАТКОЕ ОПИСАНИЕ: Очень медленно идет расчет прав на Oracle 10g
* ПРОЕКТ: Поддержка различных платформ баз данных
* ДЕТАЛИЗАЦИЯ: Oracle
# ЧТО ИЗМЕНЕНО:
Oracle
Утилита проверки БД
Расчет прав доступа
----- СУТЬ ПРЕДЛОЖЕНИЯ -----
Ускорить расчет прав доступа за счет использования
ролей на SQL-платформах, а также за счет оптимизации
алгоритма расчета прав доступа.
# КАК ИЗМЕНЕНО: Изменился алгоритм расчета прав. Теперь при расчете прав
пользователей сначала рассчитываются
права на группы, сохраняются в БД и потом используются при расчете прав
пользователей.
В случае использования ролей на SQL-платформах эти рассчитанные права групп
уходят на сервер БД;
и так далее ........................... про роли тоже
я имел в виду это. Видимо мы немного о разном (((
)ПРОБЛЕМА В ПИР: 103.3702
* ПЕРВОЕ РЕШЕНИЕ: 5.4.25.0
* КРАТКОЕ ОПИСАНИЕ: Очень медленно идет расчет прав на Oracle 10g
* ПРОЕКТ: Поддержка различных платформ баз данных
* ДЕТАЛИЗАЦИЯ: Oracle
# ЧТО ИЗМЕНЕНО:
Oracle
Утилита проверки БД
Расчет прав доступа
----- СУТЬ ПРЕДЛОЖЕНИЯ -----
Ускорить расчет прав доступа за счет использования
ролей на SQL-платформах, а также за счет оптимизации
алгоритма расчета прав доступа.
# КАК ИЗМЕНЕНО: Изменился алгоритм расчета прав. Теперь при расчете прав
пользователей сначала рассчитываются
права на группы, сохраняются в БД и потом используются при расчете прав
пользователей.
В случае использования ролей на SQL-платформах эти рассчитанные права групп
уходят на сервер БД;
и так далее ........................... про роли тоже
я имел в виду это. Видимо мы немного о разном (((