目次

Search

  1. はじめに
  2. パイプラインのパーティション化について
  3. パーティションポイント
  4. パーティションタイプ
  5. プッシュダウンの最適化
  6. プッシュダウンの最適化およびトランスフォーメーション
  7. リアルタイム処理
  8. コミットポイント
  9. 行エラーのロギング
  10. ワークフローリカバリ
  11. 停止と強制終了
  12. コンカレントワークフロー
  13. グリッド処理
  14. ロードバランサ
  15. ワークフロー変数
  16. セッションのパラメータおよび変数
  17. パラメータファイル
  18. FastExport
  19. 外部データのロード
  20. FTP
  21. セッションのキャッシュ
  22. 差分集計
  23. セッションログインタフェース
  24. バッファメモリについて
  25. 高精度データ

詳細ワークフローガイド

詳細ワークフローガイド

アップデートストラテジトランスフォーメーション

アップデートストラテジトランスフォーメーション

次の表に、アップデートストラテジトランスフォーメーションをプッシュできる各データベースのプッシュダウンタイプを示します。
データベース
プッシュダウンタイプ
Amazon Redshift
完全
Greenplum
ターゲット側
IBM DB2
完全
Microsoft SQL Server
完全
Netezza
完全
Oracle
完全
PostgreSQL
ソース側、完全
SAP HANA
ソース側、ターゲット側、完全
Snowflake
ソース側、完全
Sybase ASE
完全
Teradata
完全
Vertica
完全
Microsoft Azure SQL Data Warehouse
完全
アップデートストラテジトランスフォーメーションのロジックをデータベースにプッシュするように統合サービスを設定する際には、次のルールおよびガイドラインを使用してください。
  • 更新操作でアップデートストラテジトランスフォーメーション用に生成されたSQLは、複雑になる可能性があります。セッションをプッシュダウン最適化ありまたはなしで実行して、どちらの設定の方が高速かを確認します。
  • 同一行に対して複数の操作が存在している場合、統合サービスとデータベースとで異なる操作が実行される可能性があります。新しい行をデータベースにプッシュしたときに削除または更新されないようにするには、トランザクション削除、トランザクション更新、トランザクション挿入の順序でソース行を処理します。
  • トランスフォーメーションに複数の挿入、更新、または削除操作が含まれる場合、統合サービスにより連続して、挿入、更新、削除のSQL文が生成、実行されます。これら3つの文は必要でない場合でも統合サービスによって実行されます。この結果、パフォーマンスが低下する可能性があります。
  • 完全なプッシュダウン最適化が使用されているときは、拒否行が統合サービスに無視されます。拒否行は拒否ファイルに書き込まれません。
以下の条件のいずれかに当てはまる場合、統合サービスによってアップデートストラテジトランスフォーメーションが処理されます。
  • 統合サービスで更新方式の式がデータベースにプッシュできない場合。例えば、データベースにプッシュできない演算子が式の中に含まれている場合、統合サービスではその式はデータベースにプッシュされません。
  • トランスフォーメーションに挿入操作以外の操作が使用されていて、統合サービスが必ずしもすべてのトランスフォーメーションをデータベースにプッシュできるとは限らない。
  • アップデートストラテジ式が、数値でもブールでもない値を返す。