Japan Dynamics CRM Team Blog

Microsoft Dynamics CRM technical information for partners and customers

Dynamics CRM : PrincipalObjectAccess テーブルサイズが肥大化する原因

Dynamics CRM : PrincipalObjectAccess テーブルサイズが肥大化する原因

  • Comments 3

みなさん、こんにちは。

今回はパフォーマンスとセキュリティに関連するトピックをお届けします。Microsoft
Dynamics CRM では、CRM ユーザーが適切なレコードにのみアクセスできるよう、
セキュリティの機能を提供しています。

セキュリティの機能は多岐に渡りますが、その中で 「共有」 と呼ばれる機能があり、
任意のレコードを任意のユーザーに共有することが可能です。この場合、ユーザー
が所有しているセキュリティロールに依存することなくレコードを参照できますが、
その情報は個別にデータベースに格納します。

しかしながら、時としてその情報が膨大になることでパフォーマンスに影響することも
事実であり、パフォーマンスチューニング時によく話題になります。

今回はこの共有機能に関連した記事を US チームブログより紹介します。

※記事のタイトルでは Microsoft Dynamics CRM 4.0 とありますが、現行バージョン
にも共通する内容となっています。

元記事 : Excessive PrincipalObjectAccess Table Growth in CRM 4.0 from the Reparent - Cascade All Setting

私は Microsoft Dynamics CRM システムで巨大なデータを扱うお客様とお仕事を
する機会がよくあります。そのようなシステムにおいて各種テーブルのデータ量を
見ていると、PrincipalObjectAccess (POA) テーブルのデータ量が期待より遥かに
多い場合があります。POA テーブルは、特定のレコードをユーザーがアクセス
できるよう情報を保持しており、POA の 1 レコードは 1 件の CRM レコードと、それに
アクセスできる CRM ユーザーの情報となります。

POA テーブルにレコードが作成されるタイミングは以下の 4 つです。

システムの設定 - 元の所有者と再割り当てされたレコードを共有する

こちらの設定が 「はい」 の場合は、レコードの割り当てを行う度に、元の所有者と
割り当てられた CRM レコードの情報が POA テーブルに作成されます。アクセス
権の情報は AccessRightsMask 列に格納されます。

レコードの共有操作

ユーザーがレコードを他のユーザーと共有した場合、共有したユーザーとレコード
の情報が POA テーブルに作成されます。アクセス権の情報は AccessRightsMask
列に格納されます。

関連付けの動作 - リペアレント

エンティティ同士が関連を持つ場合、関連付けの動作をそれぞれの操作において
指定できます。リペアレントが 「伝播」 になっている場合、共有されたレコードの
子レコードについても、自動的に共有が設定されます。例えば CRM ユーザー 1 が
取引先企業レコード A を所有していて、CRM ユーザー 2 が取引先企業レコード A
に対してアクセス権がある場合、CRM ユーザー 2 が、取引先企業レコード A に
対して 1 件のサポート案件を作成したとします。この場合、作成されたサポート案件
の所有者は CRM ユーザー 2 となりますが、POA テーブルに対して CRM ユーザー
1 が作成されたサポート案件にアクセスできるよう、レコードが 1 件作成されます。
アクセス権は InheritedAccessRightsMask 列に格納されます。

暗黙の共有

上記の設定と操作の組み合わせで、レコードを共有した場合や割り当てられた
場合、必要に応じてレコードが POA テーブルに作成されます。この場合アクセス
権は InheritedAccessRightsMask 列に格納されます。

上記の中でも、リペアレントの設定によりお客様が期待したより多くのレコードが
POA テーブルに作成されていることが多くあります。多くの環境で関連付けの
動作は既定値の 「すべてのレコードに伝播」 になったままです。しかしながら、
もし多くの CRM ユーザーがセキュリティロールの設定により、必要なレコードに
アクセスできる場合、POA テーブルの情報は利用されません。

関連付けの動作は、「伝播しない」 に設定することも可能です。この場合 POA
テーブルに対して暗黙の共有によるレコード作成は行われません。先ほどの
例の場合には、CRM ユーザー 2 が取引先企業レコード A に対してサポート案件
を作成しても、CRM ユーザー 1 用のレコードは POA には作成されません。

もしユーザーがセキュリティロールの設定により、必要なレコードにアクセス
出来る場合には、リペアレントの設定で伝播を行う必要はありません。

まとめ

POA テーブルは、セキュリティを保ちつつ共有機能を利用する場合には、とても
重要な要素です。ただしユーザーが組織レベルのアクセス権を持つ場合では
個別のレコードに対してアクセス権情報を保持する必要はありません。

必要に応じて設定を見直していただくことで POA テーブルのレコード数が
最適化され、パフォーマンスが向上する可能性があります。

‐ Dynamics CRM サポート 中村 憲一郎

  • Loading...
Leave a Comment
  • Please add 6 and 7 and type the answer here:
  • Post