データベース内最適化に関する詳細
データベース内最適化は、処理のために ID がデータベースから IBM® Campaign サーバーにコピーされるのを可能な限り回避します。このオプションで、フローチャートのパフォーマンスを向上させることができます。
データベース内最適化は、以下を決定します。
- 操作をデータベース・サーバーで行うかローカル IBM Campaign サーバーで行うか。
- 操作の結果をどこに保管するか。
データベース内最適化がオンの場合は、以下のようになります。
- データのソート、結合、およびマージなどの処理タスクは、可能な場合は常にデータベース・サーバー上で実行されます。
- プロセスの出力セルは、データベース・サーバー上の一時テーブル内に保管されます。
データベース内最適化は、次のように CPU 使用量に影響を与えます。
- データベース内最適化がオンの場合、データベース・サーバーの CPU 使用量が多くなります。
- データベース内最適化がオフの場合、IBM Campaign サーバーの CPU 使用量が多くなります。
データベース内最適化をグローバルに適用し、個々のフローチャートについてそのグローバル設定をオーバーライドすることができます。ベスト・プラクティスは、グローバル構成プロパティー (データベース内最適化の使用) をオフにし、フローチャート・レベルでオプションを設定する方法です ()。
重要: 出力セル・サイズに何らかの制限を指定した場合、またはプロセスに対して一時テーブルが使用不可になっている場合、データベース内処理は実行できません。
データベース内最適化の制限
- データベース内最適化は、一部のデータベースではサポートされません。
- 必要とされるロジックによっては、データベース内処理がオンになっていても、一部の機能は依然として IBM Campaign サーバー上で実行されます。以下にいくつかの例を挙げます。
- 照会がさまざまなデータ・ソースにあるテーブルを使用する。
例えば、選択プロセスがさまざまなデータ・ソースに照会する場合、IBM Campaign はそれらのケースの ID リストをアプリケーション・サーバーに自動的に保管します。
- 照会に非 SQL マクロまたはユーザー定義フィールドが含まれている。
例えば、ユーザー定義フィールドを計算するために、IBM Campaign はユーザー定義フィールドの式を評価して、計算の一部を SQL を使用して実行できるかどうかを調べます。単純な SQL ステートメントを使用できる場合、計算はデータベース内で行われます。その計算を実行できない場合は、その計算を処理し、フローチャート内の各プロセスでその結果を保持するために IBM Campaign サーバー上に一時テーブルが作成されます。
- 照会がさまざまなデータ・ソースにあるテーブルを使用する。
マクロに含まれる未加工 SQL の処理
未加工 SQL ステートメントから成るカスタム・マクロは、以下のガイドラインの規定内で、データベース内で処理できます。
- すべての未加工 SQL カスタム・マクロが select で始まり、またテキストの 残りに from が 1 つだけ含まれています。
- <TempTable> 構文への挿入のみをサポートするデータベースの場合は、未加工 SQL カスタム・マクロと同じオーディエンス・レベルの同じデータ・ソースに、ベース・テーブルを少なくとも 1 つマップする必要があります。未加工 SQL カスタム・マクロによって選択されたフィールドが一時テーブルのフィールドにとってサイズが大きすぎる場合は、ランタイム・エラーが発生します。
- 入力セルがある選択プロセスで未加工 SQL 照会を使用する場合、正しいオーディエンス ID リストを取得するためには、<TempTable> トークンを使用する必要があります。さらに、<OutputTempTable>トークンを使用して、データベースから IBM Campaign サーバーにオーディエンス ID が再取得されないようにします。
- データベース内最適化を設定して未加工 SQL を使用する場合は、上流プロセスからの一時テーブルと結合するように未加工 SQL をコーディングする必要があります。そうしないと、結果の有効範囲が上流プロセスの結果で限定されません。