Azure SQL Database のミラーリング
Fabric でのミラーリングでは、複雑な ETL (変換読み込みの抽出) を回避し、既存の Azure SQL データベース資産を Microsoft Fabric の残りのデータと統合する簡単なエクスペリエンスが提供されます。 既存の Azure SQL データベースを Fabric の OneLake に継続的に直接レプリケートできます。 Fabric 内では、強力なビジネス インテリジェンス、人工知能、データ エンジニア、データ サイエンス、データ共有のシナリオのロックを解除できます。
Fabric でのミラーリングのための Azure SQL Database の構成に関するチュートリアルについては、「チュートリアル: Azure SQL データベースから Microsoft Fabric ミラー化データベースを構成する」を参照してください。
Fabric での Azure SQL データベースのミラーリングのデモの詳細と視聴については、次の「Data Exposed のエピソード」をご覧ください。
Fabric でミラーリングを使用する理由
Fabric のミラーリングを使用すると、複数のベンダーの異なるサービスをまとめる必要はありません。 代わりに、高度に統合された、エンドツーエンドで使いやすい製品を楽しむことができます。この製品は分析ニーズを簡素化するよう設計されており、Microsoft、Azure SQL データベース、およびオープンソースの Delta Lake テーブル形式を読み取ることができる 1000 のテクノロジ ソリューション間のオープン性とコラボレーションのために構築されています。
どのような分析エクスペリエンスが組み込まれていますか?
ミラー化されたデータベースは、Fabric データ ウェアハウスの項目であり、ウェアハウスや SQL 分析エンドポイントとは異なります。
ミラーリングでは、Fabric ワークスペースに次の 3 つの項目が作成されます。
- ミラー化データベースの項目。 ミラーリングでは、データの OneLake へのレプリケーションと Parquet への変換が、分析対応形式で管理されます。 これにより、データ エンジニアリング、データ サイエンスなどのダウンストリーム シナリオが可能になります。
- SQL 分析エンドポイント
- 既定のセマンティック モデル
ミラー化された各 Azure SQL データベースには自動生成された SQL 分析エンドポイントがあり、ミラーリング プロセスによって作成された Delta テーブルに加えて、豊富な分析エクスペリエンスが提供されます。 データ オブジェクトを定義とクエリを実行できる使い慣れた T-SQL コマンドにアクセスできますが、これは読み取り専用のコピーであるため、SQL 分析エンドポイントからデータを操作することはできません。 SQL 分析エンドポイントで実行できるアクションは、次のとおりです。
- Azure SQL データベースから Delta Lake テーブル内のデータを参照するテーブルについて説明します。
- ノー コード クエリとビューを作成し、コード行を記述することなく、視覚的にデータを調査します。
- T-SQL でセマンティクスとビジネス ロジックをカプセル化するための SQL ビュー、インライン TVF (テーブル値関数)、およびストアド プロシージャを開発します。
- オブジェクトに対するアクセス許可を管理します。
- 同じワークスペース内の他のウェアハウスとレイクハウスのデータのクエリを実行します。
Microsoft Fabric SQL クエリ エディターに加えて、SQL Server Management Studio、Visual Studio Code の mssql 拡張機能、さらには GitHub Copilot など、SQL 分析エンドポイントのクエリを実行できるツールの広範なエコシステムがあります。
ネットワークの要件
現在、ミラーリングでは、Azure 仮想ネットワークまたはプライベート ネットワークの内側にある Azure SQL データベース論理サーバーはサポートされていません。 プライベート ネットワークの内側に Azure データベース インスタンスがある場合、Azure SQL データベース ミラーリングを有効にすることはできません。
- 現時点では、パブリック ネットワーク アクセスを許可するように Azure SQL 論理サーバーのファイアウォール規則を更新する必要があります。
- Azure SQL データベース論理サーバーに接続するには、[Azure サービスを許可する] オプションを有効にする必要があります。
アクティブなトランザクション、ワークロード、レプリケーター エンジンの動作
- アクティブなトランザクションは、トランザクションがコミットされ、ミラー化 Azure SQL データベースが追いつくか、トランザクションが中止されるまで、トランザクション ログの切り捨てを保留し続けます。 長期トランザクションにより、トランザクションログが通常より多くなる可能性があります。 トランザクション ログが満たされないように、ソース データベースのトランザクション ログを監視する必要があります。 詳細については、「トランザクション ログは、長期トランザクションと CDC が原因で増加する」を参照してください。
- ユーザーのワークロードはそれぞれ異なります。 初期スナップショット中に、CPU と IOPS の両方 (ページを読み取るための 1 秒あたりの入出力操作) について、ソース データベースのリソース配分状況が増える可能性があります。 テーブルの更新/削除操作により、ログの生成が増加する可能性があります。 Azure SQL データベースのリソースを監視する方法の詳細について説明します。
- レプリケーター エンジンは、各テーブルの変更を個別に監視します。 ソース テーブルに更新がない場合、レプリケーター エンジンはバックオフを開始し、そのテーブルの期間が指数関数的に増加し、最大で 1 時間になります。 一時的なエラーが発生し、データの更新を妨げる場合にも同じ問題が発生する可能性があります。 更新されたデータが検出されると、レプリケーター エンジンは定期的なポーリングを自動的に再開します。
階層と購入モデルのサポート
ソースの Azure SQL データベースは、単一データベースまたは Elastic Pool のデータベースのいずれかになります。
- 仮想コア購入モデルのすべてのサービス レベルがサポートされています。
- DTU (データベース トランザクション ユニット) 購入モデルでは、100 DTU 未満の Free、Basic、または Standard サービス レベルで作成されたデータベースはサポートされません。