ご要望またはご協力できることがございましたらお気軽にお問い合わせください
一般的なお問い合わせと所在地情報
お問い合わせ
Control-M + Microsoft MSSQL
あなたの Microsoft MSSQL ワークフローは、ストアドプロシージャが実行される前に始まり、上流で何かが壊れると失敗する可能性があります。Azure Blob Storage 抽出が遅れて到着する。SSIS パッケージが夜間処理ウィンドウを逃す。Control-M は、Azure Blob ファイルの到着、SSIS 変換、Microsoft MSSQL 実行、ダウンストリーム分析の配信を調整します。
一般的なワークフローの問題
これはあなたの週のように聞こえますか？
これらは稀なケースではありません。これらは、複数のツールでMicrosoft MSSQLパイプラインを運営しているチームにとっての通常の運用条件です。Control-Mがそれぞれをどのように処理するか見てみましょう。
遅延ファイル到着
あなたの午前2:00のAzure Blob抽出が遅れています。SQLはそれでも開始します。
Control-Mは、実際の上流ファイル到着に基づいてMSSQLジョブを依存させます。独立したスケジュールではなく、前提条件が満たされたときにのみストアドプロシージャが開始され、データベースワークフローに不完全なデータが入るのを防ぎます。
SSIS失敗
あなたのSSISパッケージが失敗しました。下流のストアドプロシージャはまだ待っています。
Control-MはSSISパッケージをエンドツーエンドのワークフローの一部として監視し、その完了ステータスを検出し、下流の依存関係を適切に制御します。失敗した処理は、依存するMSSQL作業を静かに解放することはなく、失敗を伝播する前に含めます。
接続失敗
SQL Serverが接続を失います。あなたの夜間パイプラインは午前3:17に停止します。
Control-Mはデータベース接続が失敗したときに構成可能な接続再試行回数と再試行タイムアウトを適用します。手動の介入を即座に必要とする代わりに、一時的な接続問題は自動的に再試行できます — SQL Serverが再び到達可能になるときに夜間処理を維持します。
クロスツール依存関係
あなたのストアドプロシージャが終了しました。Power BIのリフレッシュはまだ昨日のデータのままです。
Control-MはMSSQL実行を同じワークフロー内の下流処理に接続します。データベースステップの完了は次のジョブへの明示的な依存関係となります — 切り離されたスケジュールをデータパイプライン全体で調整されたハンドオフに置き換えます。
SLAリスク
すべてのSQLジョブが成功しました。あなたの午前6:00の分析配信はSLAを逃しました。
Control-Mは、データベース完了を最終結果として扱うのではなく、エンドツーエンドのワークフロー内でMSSQL処理を追跡します。チームは完全な処理チェーン全体で依存関係とSLAの約束を監視でき、ビジネスの締切が逃される前に納品リスクを明らかにします。
Control-M + Microsoft MSSQL
Control-M + Microsoft MSSQL
|
ワークロードタイプ |
ストアドプロシージャ · SQL スクリプト · 埋め込みクエリ · SSIS パッケージ · MSSQL エージェントジョブ |
|
トリガータイプ |
ファイル到着 · 上流ジョブ完了 · 時間スケジュール · Control-M イベント · クロスワークフロー依存関係 |
|
クロスツール依存関係 |
SSIS パッケージ完了 · Azure Blob ファイル到着 · Power BI リフレッシュ · Airflow DAG · REST API コール · ファイル配信確認 |
|
クラウドプラットフォーム |
Microsoft SQL Server · Microsoft Azure · ハイブリッド環境 · Control-M SaaS · オンプレミスの Control-M |
|
エラーハンドリング |
接続リトライ (1–24 回の試行) · 接続リトライタイムアウト (1–300 秒) · 依存関係の失敗処理 · ダウンストリームカスケード防止 · ジョブの再実行 · SLA モニタリング |
|
スループット |
同時データベース接続 · 1–512 接続制限 · 並列データベースジョブ · 中央集中型接続プロファイル · リモートデータベース実行 |
|
可視性 |
ジョブ実行状況 · ジョブ出力 · 依存関係の可視性 · SLA トラッキング · 中央集中型ワークフローモニタリング · 実行履歴 |
エンドツーエンドオーケストレーション
1つのプロダクションワークフロー。スタック内のすべてのツール。
Control-M は、Microsoft MSSQL、SSIS、Airflow、Azure Blob Storage、Power BI、およびファイル転送にまたがるワークフローを単一のジョブフローで調整します。これにより、依存関係の追跡、SLA の可視性、および自動回復が可能になります。
- クロスツール依存関係: Azure Blob → SSIS → MSSQL ストアドプロシージャ → Power BI リフレッシュ
- データ認識トリガー: ファイル到着、API イベント、SSIS 完了、クエリ結果
|
Microsoft MSSQL |
ストアドプロシージャ · SQL スクリプト · 埋め込みクエリ · データベース実行 |
|
SSIS |
パッケージ実行 · パッケージ依存関係 · ワークフロー調整 |
|
Azure Blob Storage |
ファイル到着 · 上流データ依存関係 · 転送調整 |
|
Apache Airflow |
DAGトリガー · ステータストラッキング · クロスワークフロー依存関係 |
|
Power BI |
データセット更新 · 下流分析ハンドオフ · ワークフロー調整 |
|
ファイル転送 |
管理転送 · 到着検出 · 配信確認 |
airflowの共存
Control-MはあなたのAirflow DAGを置き換えません。それはその上のレイヤーを実行します。
反対意見は一般的です：「私たちはすでにAirflowを使用しています。」問題はAirflowが何をするかではなく、Airflowが実行される前後に何が起こるかです。それがパイプラインが実際に失敗する場所です。
AirflowはそのDAGを管理します。Control-Mはそれを取り囲むすべてを管理します。
airflowは処理します
データパイプライン内でのDAGレベルのオーケストレーション
- DAGレベルのタスクオーケストレーションデータパイプライン内
- Pythonオペレーター、センサー、およびタスク依存関係
- パイプライン内で実行されるジョブの実行グラフ
- 単一DAGコンテキスト内での再試行を管理
control-mが追加されます
あなたのDAGの周りの調整レイヤー
- DAGの周りの調整レイヤー — 上流の条件に基づいてAirflowをトリガーします：ファイル到着、APIイベント、他のツールの完了
- 各DAGのSLA貢献をフルエンドツーエンドのワークフロー全体で追跡します、単独のルーチンだけではなく
- 上流の依存関係が失敗したときの障害回復を管理します、Airflowが開始する前に
- 既存のDAGを再作成または移行する必要はありません
パイプラインを監視
MSSQLジョブを完全なデータパイプラインで監視します。
SQL Serverはデータベース内で何が起こったかを示しますが、データチームはそれを取り巻くシステム全体の可視性を必要とします。Control-Mは上流と下流のワークフローコンテキストを持つMSSQL実行を集中管理することで、チームが完全なパイプラインを監視できるようにします:
-
データベースジョブ実行状況
-
ジョブ出力とランタイム
-
上流および下流依存関係
-
クロスプラットフォームワークフロー状況
-
SLAリスク可視性
SLA保証
MSSQLパイプラインをビジネスの配信SLAに合わせて保つ。
成功したストアドプロシージャは、完全なデータプロダクトが時間通りに到着したことを意味しません。Control-Mは、MSSQLジョブをそのエンドツーエンド依存関係チェーン内で管理し、チームが全体のワークフローが配信の約束に沿っているかどうかを追跡できるようにします:
-
エンドツーエンドSLA追跡
-
ツール間依存関係の可視性
-
ワークフロー完了監視
-
失敗した依存関係の封じ込め
-
集中型例外管理
複雑なワークフローに秩序をもたらす
Control-Mがチームに、より大きな可視性、調整、制御を持って複雑なプロセスをオーケストレーションする方法を学びます。
