Partager via

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

  • Article

みなさん、こんにちは。

今回はパフォーマンスとセキュリティに関連するトピックをお届けします。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 サポート 中村 憲一郎

Comments

  • Anonymous
    August 03, 2014
    おせわになります。 上記につき質問させてください。 POAについてリペアレントを変更した際に、不要となったPOAレコードは削除されるのでしょうか。 レコードを削除することなくPOAレコードのみを削除したいと考えております。 またPOAテーブルのデータ量は算出できますか? よろしくおねがいします。

  • Anonymous
    August 04, 2014
    コメントありがとうございます。 不要となった PrincipalObjectAccess テーブルのレコードは削除されます。残っている場合セキュリティリスクとなるため基本的にはリアルタイムに削除されます。ただしレコードが削除された場合、関連するPOA テーブルのレコードは非同期で削除されます。これはすでにレコードがないためセキュリティリスクにはならないためです。 POA テーブルのデータ量は計算はカスタマイズやオペレーションによって変動が激しいため予測が困難でございます。関連しているレコードが多く、伝搬する場合は、1 件共有しただけでも複数の POA レコードが作成されるためです。

  • 中村 憲一郎
  • Anonymous
    August 04, 2014
    早速の回答ありがとうございます、大変参考になりました。