Администрирование
22
Янв
0

Шара или размышления о производительности

Во время проектирования структуры Подразделений CRM, из-за ограничений модели безопасности может возникнуть идея использовать функционал Общего доступа, чтобы преодолеть эти ограничения. А это в свою очередь, приводит нас к проблеме производительности. Дело в том, что при расшаривании записей в CRM информация об этом добавляется в таблицу PrincipalObjectAccess (POA). Казалось бы и хрен бы с ней… ан нет. Каждый раз при принятии решения о том, какие записи доступны для просмотра пользователю (например, при прорисовке Представлений), система, помимо определения доступа на основе Ролей и Подразделений еще и смотрит в эту табличку, ища там записи, которые расшарены на текущего пользователя. И чем больше будет эта таблица, тем дольше будет производиться ее чтение. Поэтому нужно стараться держать ее как можно меньшего размера.

Записи в таблицу POA попадают одним из четырех способов:

  • Расшаривание записи на предыдущего владельца.
    Есть в Системных настройках такая опция, благодаря которой при назначении (assign) нового Ответственного за запись CRM, предыдущий Ответственный продолжает иметь к ней доступ. Это обеспечивается за счет использования функции Общий доступ. И всякий раз, когда для записи назначается новый Ответственный, в таблицу POA попадает новая запись (визуально Вы можете это наблюдать в диалоговом окне Общего доступа).
    Записи в таблице POA, обеспечивающие этот функционал имеют заполненный столбец AccessRightsMask;
  • Прямое расшаривание. Ну, тут все понятно: когда пользователь использует функционал Общего доступа, при расшаривание каждой записи на очередного пользователя (или Рабочую группу) в таблице POA появляется новая запись. Такие записи имеют заполненным столбец AccessRightsMask;
  • Изменение родителя.
    Настройка связей в CRM имеют такую опцию как Переподчинение. Если эта опция имеет значение Каскад для всех, то дочерние записи CRM будут расшариваться на владельца родительской записи.
    Например: User1’у принадлежит Account1. User2 имеет доступ к Account1 и создает Case1 для Account1. Из-за настройки Переподчинение, в таблице POA будет создана запись, которая предоставит доступ User1 к созданному Case1. У этих записей в таблице в POA будет заполнено поле InheritedAccessRights;
  • Косвенное расшаривание.
    Когда расшаривание происходит напрямую, или через назначение нового Ответственного, или через Переподчинение, в таблице POA будут созданы дополнительные записи, чтобы дать соответствующие права на дочерние записи пользователю, получившему доступ к родительской записи. У этих записей в таблице POA будет заполнен столбец InheritedAccessRightsMask.

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

  • Расшаривайте только при необходимости (как банально 🙂 );
  • При возможности минимизируйте число Подразделений. Это поможет уменьшить потребность в расшаривании. Если пользователи находятся в разных подразделениях, то единственный способ (помимо всеобщего доступа) предоставить доступ к записям одного подразделения пользователям другого – Общий доступ. А если пользователи находятся в одном подразделении достаточно будет дать им соответствующие Роли;
  • Рассмотрите возможность переместить каких-либо Пользователей вверх по иерархии Подразделений, чтобы предоставить им необходимый доступ к записям дочерних Подразделений.
  • Измените настройки безопасности, чтобы позволить Пользователям видеть информацию за пределами своего Подразделения. Радикально, но тоже способ 🙂
  • Как только запись перестает нуждаться в Общем доступе – отмените его;
  • Включите в реестре ключ EnableRetrieveMultipleOptimization. Если этот ключ включен, то SQL запросы в отношении MS CRM будут выполняться во временной таблице. А после чего рассмотрите возможность перенести TempDB на отдельный физический диск (или RAID массив).
    P.S. http://support.microsoft.com/kb/2535245;
  • Обеспечьте частые запросы к таблице POA соответствующими индексами.
Комментарии (0)

*

code