可能な場合は、ソース、宛先またはターゲット・ルールで階層の最上位の使用は避けてください。
データベースは効率的ですが、コンパクトなルール定義があるとさらに効率的になります。
たとえば、"AllAccounts"、"AllEntities"、"AllCompanies"および"AllProducts"として定義されているソースでは、勘定科目、エンティティ、会社および製品のそれぞれに1000個のレベル0メンバーがあり、データベースでソース・データに対して10004 (1兆)個の可能性のある場所をスキャンする必要があります。
配賦の宛先で「ソースと同じ」オプションを使用します。宛先をソースと同じに設定を参照してください。
単一のルールを使用して多くのソースの組合せを処理し、一部のディメンションでは配賦を"待機"させて他のディメンション間では分散させることができます。
多くの場合、1つのEnterprise Profitability and Cost Managementルールで、レガシー・システムの多くのルールを置き換えることができます
ソース・メンバー選択は、親メンバーを優先する必要があります
親を選択できる場合、個別の子の選択を避けてください。またはルール処理用に設計された代替階層を使用して、共通の親のメンバーをグループ化します。
Oracle Essbaseは、多くの場合、それぞれの子に複数のパスを作成するのではなく、ある親のすべての子孫を処理できるほうが高速になります。
問題のあるソースと宛先の組合せは、疑う必要があります。
たとえば、ソースと宛先の両方が「エンティティ合計」の場合、エンティティ組合せのクロス積が大きくなります。