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

SQL Server コネクタの制限事項

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

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

このセクションの制限は、 Lakeflowコネクトのすべてのデータベースコネクタに適用されます。 コネクタ固有の制限事項については、引き続きお読みください。

  • スケジュールされたパイプラインを実行しても、アラートはすぐにはトリガーされません。代わりに、次の更新が実行されたときにトリガーされます。

  • ソース テーブルを削除しても、コピー先テーブルは自動的に削除されません。コピー先テーブルは手動で削除する必要があります。この動作は Lakeflow 宣言型パイプラインの動作と一致しません。

  • ソースのメンテナンス期間中は、Databricks がデータにアクセスできない場合があります。

  • ソース テーブル名が既存の宛先テーブル名と競合する場合、パイプラインの更新は失敗します。

  • マルチデスティネーションパイプラインのサポートはAPIのみです。

  • オプションで、取り込むテーブルの名前を変更できます。パイプライン内のテーブルの名前を変更すると、そのテーブルは API のみのパイプラインになり、UI でパイプラインを編集できなくなります。

  • パイプラインがすでに開始された後に列を選択した場合、コネクタは新しい列のデータを自動的にバックフィルしません。ヒストリカルデータを取り込むには、テーブルで完全な更新を手動で実行します。

  • Databricks では、同じパイプライン内で同じ名前の 2 つ以上のテーブルを取り込むことはできません (それらが異なるソース スキーマから来ている場合でも)。

  • ソース・システムは、カーソル列が単調に増加していると想定しています。

  • マネージドインジェストパイプラインは、AWS GovCloud リージョン (FedRAMP High) のワークスペースではサポートされていません。

  • マネージド インジェスト パイプラインは、 us-east-2 リージョンまたは us-west-1 リージョンの FedRAMP Moderate ワークスペースではサポートされていません。

  • タイプ 1 SCD 有効にすると、削除によってチェンジデータフィードに明示的な delete イベントは生成されません。 監査可能な削除の場合は、コネクターがサポートしている場合は、SCD タイプ 2 を使用します。詳しくは、 例: CDF ソース・データを使用した SCD タイプ 1 および SCD タイプ 2 の処理を参照してください。

  • サポートはプライマリ SQL Server インスタンスに限定されます。これは、変更の追跡とチェンジデータキャプチャがリードレプリカまたはセカンダリインスタンスでサポートされていないためです。

認証​

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

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

  • コネクタは、Azure SQL Database、Azure SQL Managed Instance、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 つのテーブル ( MyTable と MYTABLEなど) を取り込むことはできません。このような場合をサポートするには、ターゲット スキーマに発行する 2 つのゲートウェイ インジェスト パイプライン ペアを作成します。
  • source_catalog、 source_schema、および source_table の名前では、大文字と小文字が区別されます。たとえば、ソース・データベース・カタログが sys.databasesで Marketing として指定されている場合、ingestion_definitionで marketing として指定することはできません。
  • 1 つのパイプラインで複数のソースカタログまたはスキーマから取り込むことはできますが、同じ名前の 2 つのテーブルを取り込むことはできません。たとえば、 schema1.Marketing と schema2.Marketing の両方を同じパイプラインに取り込むことはできません。
  • 複数のテーブルまたはスキーマの仕様を ingestion_definitionの objects フィールドに含めることができます。ただし、異なるソーススキーマのソーステーブル名を重複させることはできません。これにより、インジェスト パイプラインが失敗します。
に最終更新