サマリの昇格¶
必要なサマリを定義したら、以下の手順を実行し、異なる環境 (テスト環境から本番環境へなど) にサマリを昇格します。
Scheduler で、以下の VDPDataLoad ジョブ を作成し、サマリが常に更新されるようにします。
サマリを完全に更新するジョブです。昇格の間、このジョブは、1) サマリが初めて昇格されるときと、2) サマリの定義が変更されるたびに実行する必要があります。
サマリで増分ロードが許可される場合、増分ロード構成によって 2 つ目の Scheduler ジョブを定義します。
昇格中にこのジョブは実行されません。増分ジョブは、データを最新に保つよう定期的に実行されます。
Solution Manager で、上記のサマリと Scheduler ジョブを含む リビジョンを作成します 。
ターゲット環境にすでにサマリが存在し、構成や定義が異なる新しいサマリを使用して、既存のサマリを置き換える場合は、以下を実行します。
[Replace existing elements] オプションでリビジョンを作成します。
サマリを完全に更新する Scheduler ジョブを含めて (ジョブが変更されていない場合でも)、[Execute job when revision is deployed] を選択します。
以下のセクションでは、新規サマリおよび変更されたサマリの昇格プロセスについて詳しく説明します。
新規サマリの昇格プロセス¶

サマリが初めて昇格される場合、サマリコンテンツを含むテーブルがまだ存在しないため、VDP サーバーはサマリの状態を needs_refresh に設定します。サマリを完全に更新する Scheduler ジョブをリビジョンに含め、[Execute job when revision is deployed] を選択する必要があります。

Scheduler ジョブが最初のノードで実行されると、選択したデータソースにテーブルが作成され、サマリのステータスが Valid に変更されます。

最後に、同じサマリが 2 番目のノードに昇格されます。2 番目の VDP サーバーは、テーブルがすでにデータベースに存在することを確認し、新しいサマリを Valid に設定します。

サマリ更新の昇格プロセス¶
サマリコンテンツが保存されているクエリやデータソースなど、サマリ定義に何らかの変更加えることにした場合、リビジョンで [Replace existing elements] を選択し、ターゲットに対してサマリを完全に更新する Scheduler ジョブを含めることが重要です。
この場合、メカニズムは同じですが、考慮すべきことがわずかに異なります。
以前と同様に、Solution Manager はサマリを最初の VDP サーバーに昇格します。サーバーはテーブルがすでに存在することを確認します。データソースの詳細やテーブルの列が変更された場合、VDP サーバーは既存のサマリが有効ではなくなっていることを認識し、サマリのステータスを「needs_recreate」に設定します。

次に、デプロイプロセスは、サマリを更新する Scheduler ジョブを実行します。VDP サーバーはサマリテーブルを再作成し、サマリのステータスを Valid に変更します。

最後に、同じサマリが 2 番目のノードに昇格されます。2 番目の VDP サーバーは、テーブルがすでにデータベースに存在し、スキーマが正しいことを確認して、サマリのステータスを Valid に設定します。

注釈
クエリオプティマイザーは、サマリのステータスが 'Valid’ の場合のみ、そのサマリを使用します。サマリのステータスは、読み込みに成功した場合のみ 'Valid’ に設定されます。つまり、サマリのステータスが 'Needs Refresh' または 'Needs Recreate' の場合、クエリオプティマイザーは、クエリのアクセラレーションにそのサマリを使用することはありません。