メインコンテンツまでスキップ

SQL Server コネクタの制限事項

備考

プレビュー

Microsoft SQL Server コネクタは パブリック プレビュー段階です。

このページでは、SQL Server を使用したDatabricksLakeFlow Connect 取り込みに関する制限事項と考慮事項を示します。

データベース・コネクターの一般的な制限

このセクションの制限は、 LakeFlow Connectのすべてのデータベースコネクタに適用されます。

  • スケジュールされたパイプラインを実行しても、アラートはすぐにはトリガーされません。代わりに、次の更新が実行されたときにトリガーされます。
  • ソース テーブルを削除しても、コピー先テーブルは自動的に削除されません。コピー先テーブルは手動で削除する必要があります。この動作は DLT の動作と一致しません。
  • ソースのメンテナンス期間中は、Databricks がデータにアクセスできない場合があります。
  • ソース テーブル名が既存の宛先テーブル名と競合する場合、パイプラインの更新は失敗します。
  • マルチデスティネーションパイプラインのサポートはAPIのみです。
  • オプションで、取り込むテーブルの名前を変更できます。パイプライン内のテーブルの名前を変更すると、そのテーブルは API のみのパイプラインになり、UI でパイプラインを編集できなくなります。
  • パイプラインがすでに開始された後に列を選択した場合、コネクタは新しい列のデータを自動的にバックフィルしません。ヒストリカルデータを取り込むには、テーブルで完全な更新を手動で実行します。
  • マネージド インジェスト パイプラインは、次のものではサポートされません。
    • AWS GovCloud リージョンのワークスペース
    • Azure GovCloud リージョンのワークスペース
    • FedRAMP 準拠のワークスペース

コネクタ固有

このセクションの制限は、SQL Server コネクタに固有のものです。

認証

  • コネクタは、ユーザー名とパスワードの認証のみをサポートします。
  • マルチサブネット フェールオーバー クラスタリング構成では、1 つの前面 IP アドレスを提供する必要があります。

データベースのバリエーション

  • このコネクタは、Azure SQL データベースと Amazon RDS SQL データベースをサポートしています。これには、Azure 仮想マシン (VM) と Amazon EC2 で実行されている SQL Server が含まれます。このコネクタは、Azure ExpressRoute と AWS Direct Connect ネットワークを使用したオンプレミスの SQL Server もサポートしています。

  • Microsoft チェンジデータキャプチャ (CDCを使用するには:

    • 2012 サービス パック 1 (SP1) SQL Server 累積的な更新プログラム パッケージ 3 (CU3) 以降が必要です。

      この更新により、 __$command_id 列が導入されました。この列がないと、インジェスト ゲートウェイはデータ変更操作の種類 (たとえば、同じ__$seqval値を持つDELETE-INSERTペアとして表示されるUPDATE操作) を確実に区別できません。これにより、データの不整合が発生する可能性があります。

    • SQL Server 2016 より前のバージョンでは、Enterprise Edition も必要です。

  • Microsoft 変更追跡を使用するには、SQL Server 2012 以降が必要です。

パイプライン

  • 各インジェスト パイプラインは、1 つのインジェスト ゲートウェイに関連付ける必要があります。
  • インジェスト パイプラインはサーバレス コンピュートで実行されますが、インジェスト ゲートウェイはクラシック コンピュートで実行する必要があります。

スキーマ進化

コネクタは、オプトアウトしない限り、新しい列と削除された列を自動的に処理します。

  • ソースに新しい列が表示されると、Databricks はパイプラインの次回実行時に自動的にその列を取り込みます。ただし、これを無効にすることができます。
  • 列がソースから削除されても、Databricks はそれを自動的に削除しません。代わりに、コネクタはテーブル プロパティを使用して、削除された列を宛先の inactive に設定します。後で inactive 列と競合する名前を持つ別の列が表示された場合、パイプラインは失敗します。この場合、テーブルの完全更新を実行するか、非アクティブな列を手動で削除できます。

これは、スキーマ全体を取り込む場合、スキーマ内の新しいテーブルと削除されたテーブルに当てはまります。

最後に、コネクタは列の名前を変更できますが、これにはテーブルの完全な更新が必要です。

追加のスキーマ変更 (データ型の変更など) も、ターゲットテーブルの完全な更新が必要です。

ステージング

ステージング・カタログをフォーリンカタログにすることはできません。

テーブル

  • Databricks では、パイプラインごとに取り込むテーブルを 250 個以下にすることをお勧めします。ただし、これらのオブジェクト内でサポートされる行または列の数に制限はありません。
  • Databricks では、1 つのパイプラインを使用して、大文字と小文字のみが名前が異なる 2 つのテーブル ( MyTableMYTABLEなど) を取り込むことはできません。このような場合をサポートするには、ターゲット スキーマに発行する 2 つのゲートウェイ インジェスト パイプライン ペアを作成します。
  • source_catalogsource_schema、および source_table の名前では、大文字と小文字が区別されます。たとえば、ソース・データベース・カタログが sys.databasesMarketing として指定されている場合、ingestion_definitionmarketing として指定することはできません。
  • 1 つのパイプラインで複数のソースカタログまたはスキーマから取り込むことはできますが、同じ名前の 2 つのテーブルを取り込むことはできません。たとえば、 schema1.Marketingschema2.Marketing の両方を同じパイプラインに取り込むことはできません。
  • 複数のテーブルまたはスキーマの仕様を ingestion_definitionobjects フィールドに含めることができます。ただし、異なるソーススキーマのソーステーブル名を重複させることはできません。これにより、インジェスト パイプラインが失敗します。
この記事は役に立ちましたか?