web-dev-qa-db-ja.com

ディメンションのProcessUpdateは、キューブ内のすべてのメジャーグループのすべてのパーティションの処理をトリガーします

同じメジャーグループに接続されているアカウントと顧客のディメンションがキューブにあります（キューブには約15〜20のメジャーグループがあります）。

XMLAコマンドを実行して、次のようにこれら2つのディメンションを更新します。

<Batch>
    <Parallel>
        <Process>
            <Object>
                <DatabaseID>My Database</DatabaseID>
                <DimensionID>Dim Customer</DimensionID>
            </Object>
            <Type>ProcessUpdate</Type>
            <WriteBackTableCreation>UseExisting</WriteBackTableCreation>
        </Process>
    </Parallel>
</Batch>

アカウントディメンションの場合、すべてのメジャーグループのすべてのパーティションの処理がトリガーされないため、数分で終了します。 But Customerディメンションの場合、すべてのメジャーグループのすべてのパーティションの処理がトリガーされるため、このディメンションのプロセス更新は続行されますキューブ全体の完全な処理よりも長くなります。

一方のディメンションの場合、もう一方のディメンションの場合ではなく、ディメンションがこのすべての処理をトリガーする理由が何であるかはわかりません。両方のディメンションで、[影響を受けるオブジェクトを処理する]が[処理しない]に設定されています。どこを見ればいいのか、何をチェックすればいいのか、どういうわけかこの再処理が起こらないようにできますか？

ありがとう！

ssasmdx
1
vldmrrdjcc

「影響を受けるオブジェクトの処理」をどこにも指定せずにパーティションが処理されることに少し驚いています。
出力された「パーティション処理操作」と実際のパーティション処理を混同している可能性があります。

ディメンションを更新するときにパーティションを処理するロジックはこれです。

  • ディメンションの更新を処理し、新しいメンバーのみが追加された場合、パーティションは影響を受けません
  • ディメンションの更新を処理して変更が加えられた場合（削除、顧客が顧客グループ/郵便番号を変更したなどのディメンション関係の変更）、パーティションの集計データとビットマップインデックスの一部が削除されます。

集計データとビットマップインデックスのドロップは、プロファイラーに「パーティション処理操作」として表示されます。

ただし、これによってパーティションにアクセスできなくなることはないため、速度は遅くなりますが、メジャーは引き続きクエリに使用できます。

ProcessAffectedObjectsがtrueに設定されている場合、集約/インデックスが削除されたパーティションでは、集約とインデックスが再構築されます（ただし、パーティション全体が再処理されるわけではありません）。

したがって、「パーティション処理操作」というメッセージをパーティションの実際の再処理と混同していると思います。顧客ディメンションは、アカウントパーティションよりも処理に時間がかかります（おそらく、メンバー/階層/関係などが多いため）。 。

参考までに、$SYSTEM.DISCOVER_PARTITION_DIMENSION_STAT dmvのスクリプトを提供するこのリンクにアクセスして、これが何が起こっているかを検証できます。 簡単な言葉でさまざまな種類のSSAS処理 。

[影響分析]ボタンは、キューブ定義を使用して、影響を受ける可能性のあるパーティションを確認するだけです。ディメンションの実際の処理が完了するまで、SSASはどのパーティションが影響を受けるかを認識しません。

2
Tom V - try topanswers.xyz