次の方法で共有

自分のデータベースの持ち込み (BYOD)

メモ

コミュニティの関心グループが Yammer から Microsoft Viva Engage に移行されました。 Viva Engage コミュニティに参加し、最新のディスカッションに参加するには、「 Finance and Operations Viva Engage Community へのアクセスを要求する 」フォームに入力し、参加するコミュニティを選択します。

この記事では、管理者がアプリケーションからのデータ エンティティを自分の Microsoft Azure SQL データベースにエクスポートする方法について説明します。 この機能は、自分のデータベースの持ち込み (BYOD) とも呼ばれます。

BYOD 機能により、管理者は、独自のデータベースを構成し、アプリケーションで使用できる 1 つまたは複数のデータ エンティティをデータベースにエクスポートできます。 (現時点では、1,700 以上のデータ エンティティが使用可能です。) 具体的には、この機能により次のタスクを実行できます。

  • エンティティ データをエクスポートできる 1 つ以上の SQL データベースを定義します。
  • すべてのレコードをエキスポート (完全にプッシュ) するか、変更または削除されたレコードのみをエキスポート (増分プッシュ) します。
  • 定期的なエクスポートを有効にするには、バッチ フレームワークの豊富なスケジューリング機能を使用します。
  • トランザクション SQL (T-SQL) を使用してエンティティ データベースにアクセスし、さらにテーブルを追加してデータベースを拡張します。

エンティティ格納または BYOD か

Microsoft Power BI 統合についてのブログ記事 のシリーズに従った場合、エンティティ格納に精通できます。 エンティティ格納は運用データ ウェアハウスです。 エンティティ格納では、Power BI の実稼働レポートの組み込み統合を提供します。 既製のレポートと分析ワークスペースでエンティティ格納を使用します。 アプリケーションの環境のデータを使用して Power BI レポートを作成する場合は、エンティティ格納を使用する必要があります。

ただし、次のシナリオでは BYOD 機能をお勧めします。

  • データを独自のデータ ウェアハウスにエクスポートする必要があります。
  • Power BI 以外の分析ツールを使用し、これらのツールはデータに対して T-SQL アクセスを必要とします。
  • 他のシステムとのバッチ統合を実行する必要があります。

メモ

アプリケーションは、運用データベースへの T-SQL 接続を許可しません。 財務と運用の以前のバージョンをアップグレードする場合、データベースへの直接的な T-SQL アクセスを必要とする統合ソリューションがある場合は、BYOD は推奨するアップグレード パスになります。

エンティティ格納または BYOD のいずれかを使用できます。 使用可能な既定の業務レポートは、埋め込み Power BI とエンティティ格納を利用します。 最初の選択として、既定の業務レポートを使用することをお勧めします。 また、要件に合わせて、既成のオペレーション レポートを拡張することができます。 BYOD を必要に応じて利用する補足的なオプションと見なす必要があります。

SQL データベースを作成しています

エンティティのエクスポート オプションを構成して BYOD 機能を使用する前に、Azure portal を使用して SQL データベースを作成する必要があります。

1 ボックス開発環境では、ローカルの Microsoft SQL Server データベースでデータベースを作成できます。 ただし、このデータベースは、開発およびテスト目的でのみ使用される必要があります。 運用環境については、Azure SQL データベースを作成する必要があります。

また、データベースにサインインするには、SQL ユーザー アカウントを作成する必要があります。 サーバー名、データベース名、および SQL ユーザー ID とパスワードを記述します。 この情報は、次のセクションで、エンティティのエクスポート オプションを構成するときに使用します。

分析目的で統合の BYOD 機能を使用している場合、縦棒ストア インデックス: 概要の説明に従って、クラスター化された縦棒ストア インデックスの使用を考慮する必要があります。

メモ

ご利用の BYOD データベースは、財務と運用アプリからアクセスできる必要があります。 BYOD にアクセスできない問題が発生した場合は、BYOD のファイアウォール規則が適切に構成されていることを確認する必要があります。 セルフ サービスの配置の詳細については、セルフ サービスの配置に関するよく寄せられる質問 を参照してください。

想定されるパフォーマンスを保護するには、正しいサービス層と計算サイズを選択する必要があります。 これを行う際には、財務と運用エクスポートに基づく負荷だけではなく、対象となるワークロードの全体を考慮することが重要です。 運用環境の場合は、少なくとも次の表に指定されている最小レベルを使用することをお勧めします:

エディション 最小層
Premium P4 またはそれ以上
Standard S6 またはそれ以上
Business Critical BC_Gen5_8以上
Hyperscale HS_Gen5_24以上
General Purpose GP_Gen5_8以上

特定の BYOD を使用する場合、サービス層が上記の最小値を超えている必要がある場合があります。 層と計算サイズの詳細については、SQL Azure サービス層 および リソースの制限の詳細 を参照してください。 DTU の必要または使用率を決定するには、ワークロードに必要な DTU を決定するを参照してください

エンティティのエクスポート オプションのコンフィギュレーション

  1. クライアントを起動し、データ管理ワークスペースで、データベースへのエンティティ エクスポートのコンフィギュレーション タイルを選択します。

  2. いくつかのデータベースを構成した場合、一覧が表示されます。 それ以外の場合、新しいデータベースをコンフィギュレーションする必要があります。 この場合、新規を選択して、新しいデータベースに一意の名前と説明を入力します。 複数のデータベースにエンティティをエクスポートできます。

  3. 次の形式で、接続文字列を入力します。

    データ ソース =< 論理サーバー名 >、1433。最初のカタログ =< DB名 >。統合セキュリティ = False。ユーザー ID =< SQL ユーザー ID > 。パスワード =< パスワード >

    この接続文字列では、論理サーバー名を nnnn.database.windows.net のようにする必要があります。 Azure ポータル内の論理サーバー名を検索できる必要があります。 次の図は、接続文字列の例を示します。

メモ

前の画像に表示されている既定の拡張子フィールドは、BYOD には適用されません。

  1. 検証 を選択し、接続が正常に行われたことを確認します。

    • クラスター化された縦棒ストア インデックスを作成オプションは、コピーされるエンティティの縦棒ストア インデックスを定義することで選択したクエリの出力先データベースを最適化します。
    • ターゲット データベースでトリガーを有効にする オプションは、ターゲット データベースで SQL トリガーを有効にするためにジョブを設定します。 このオプションを使用すると、レコードを挿入した後に開始する必要がある操作を調整するために、ダウンストリーム プロセスをトリガーにフックできます。 1 つのトリガーは一括挿入の操作ごとにサポートされています。 一括挿入のサイズは、データ管理フレームワークの 最大挿入コミット サイズ パラメーターによって決まります。

BYOD から読み込む分析アプリケーション データのシナリオの場合、同期の実行中に、レポート システムが BYOD から一貫したデータを取得することを確認するという課題が常にあります。 BYOD プロセスで作成されたステージング テーブルから分析データ アプリを直接読み込まないことにより、この結果を達成することができます。 ステージング テーブルは、データがインスタンスから同期されている間データを保持するため、常に変化します。 SQL トリガー機能を使用して、データ同期が完了した時点を判断し、下流の分析データ シナリオへのデータの変換と入力を行います。

検証に合格すると、次の図に示すように、エンティティに向けてコンフィギュレーションされたデータベースがデータベースのリストに表示されます。

エンティティのデータベース。

メニュー上で 公開 オプションを選択することにより、1 つまたは複数のエンティティを新しいデータベースに公開することができるようになりました。

エンティティ スキーマをデータベースに公開

発行 ページは、いくつかのシナリオを有効にします。

  • データベースに新しいエンティティを公開します。
  • 以前に公開されたエンティティをデータベースから削除します。 (たとえば、スキーマを再作成することができます。)
  • 公開されたエンティティをエンティティ スキーマと比較します。 (たとえば、新しいフィールドを後で追加する場合、フィールドをデータベース スキーマと比較できます。)
  • データの差分更新を可能にする変更追跡機能をコンフィギュレーションします。

次のセクションでは、各オプションについて説明します。

パブリッシュ

発行 オプションは、ターゲット データベースにエンティティ データベース スキーマを定義します。 1 つまたは複数のエンティティを選択してから、公開 オプションを選択すると、バッチ ジョブが開始します。 このジョブは、出力先データベースにエンティティを作成します。 データベース定義ジョブが完了すると、メッセージが表示されます。このメッセージには、右上のベル記号を使用してアクセスできます。

実際のデータの更新は、データをエクスポートするときに実行されます。 この時点では、スキーマを作成するだけです。

エンティティの削除

エンティティを削除 オプションは、出力先のデータベースからデータとエンティティ定義を削除します。

ソース名の比較

ソース名を比較オプションでは、出力先のエンティティ スキーマをアプリケーション内のエンティティ スキーマと比較することができます。 このオプションは、バージョン管理に使用されます。 また、出力先テーブルから不要な列を削除するためにこのオプションを使用することができます。

変更追跡のコンフィギュレーション

変更の追跡は、SQL Server および SQL データベースで提供される機能です。 変更追跡を使用すると、データベースでテーブルに加えられた変更 (削除を含む) を追跡できます。 変更の追跡を使用して、トランザクションとしてテーブルに加えられた変更を識別します。 ただし、アプリケーションはデータ エンティティ レベルで変更を追跡する必要があるため、この機能が動作するための SQL 変更追跡の上により多くのロジックがあります。 変更追跡を有効にする手順については、このセクションで後述します。

発行 ページの 変更の追跡 オプションでは、基になるエンティティの変更の追跡方法を設定できます。

基礎となるエンティティの変更追跡。

次のテーブルでは、使用可能な変更追跡オプションについて説明します。

オプション 説明
プライマリ テーブルの有効化 エンティティは複数のテーブルで構成されます。 エンティティの主テーブルに加えられたすべての変更を追跡するには、このオプションを選択します。 プライマリ テーブルに変更を加えると、対応するレコードが出力先データベースに挿入されるか、またはそのデータベース内で更新されます。 エンティティ全体からのデータは出力先テーブルに書き込まれますが、プライマリ テーブルが変更された場合にのみ、システムの挿入または更新オプションがトリガーされます。
エンティティ全体の有効化 エンティティのすべての変更を追跡するには、このオプションを選択します。 (これらの変更は、エンティティを構成するすべてのテーブルへの変更を含みます。) エンティティへの変更を加えるときに、対応する更新が宛先に対して行われます。
カスタム クエリの有効化 このオプションを使用すると、開発者は、システムが変更を評価するために実行するカスタム クエリを提供できます。 このオプションは、選択したフィールドのセットのみから変更を追跡するという複雑な要件がある場合に便利です。 エクスポートされるエンティティが入れ子になったビューの階層を使用して構築されたときも、このオプションを選択することができます。 詳細については、エンティティの変更追跡の有効化 を参照してください。

変更追跡を使用するには、データ管理で上に示すように変更追跡オプションを有効にする必要があります。 このアクションは、に移動し、> リスト ページで使用できます。 データ エンティティで変更追跡を有効にするには、エンティティを選択し、上のオプションのいずれかから選択する必要があります。

出力先のデータベースに存在するエンティティを再発行する場合、システムでは、既存のデータが新しい操作が原因で削除されることを警告されます。

発行操作を確認すると、システムがスキーマをデータベースに発行し、その操作が完了すると通知を受け取ります。

公開ページで公開済のみを表示オプションを選択することにより、指定した出力先データベースに公開されたエンティティのみを表示できます。 発行機能は、データベース内のエンティティ スキーマを作成します。 データベースに移動して、対応するインデックスとともに、作成されたテーブル スキーマを表示することができます。

メモ

現在、データベースに複合エンティティをエクスポートするのに BYOD を使用することはできません。 複合エンティティの各エンティティをエクスポートする必要があります。

データベースへのエクスポート データ

エンティティが宛先データベースに公開された後、データ管理ワークスペースのエクスポート機能を使用してデータを移動することができます。 エクスポート関数を使用すると、1 つまたは複数のエンティティが含まれるデータ移動ジョブを定義できます。

エクスポート ページを使用すると、データをコンマ区切り値 (CSV) ファイルなどの多くのターゲット データ書式にエクスポートすることができます。 このページは、別の宛先として SQL データベースもサポートしています。

ページのエクスポート。

複数のエンティティを持つデータ プロジェクトを作成することができます。 バッチ フレームワークを使用することにより、このデータ プロジェクトの実行をスケジュールすることができます。 また、バッチ処理でのエクスポート オプションを選択することにより、データ エクスポート ジョブを定期的に実行するようにスケジュールします。

会社間でのデータのエクスポート

バッチで実行されるジョブは、複数の会社間でデータをエクスポートする場合にも使用できます。 このバッチ エクスポートには、 の下で、> オプションを有効にする必要があります。 BYOD データベースに同じエンティティを同時にエクスポートすると DTU の使用率が高くなることがあり、差分エクスポートでデータが失われることがあります。 このリスクを避けるため、バージョン 10.0.16 からは、会社間におけるすべての実行は会社ごとに順次行われます。 つまり、エンティティと会社が多数のジョブの実行時間は長くなります。

エクスポートの時間全体を短縮するには、次の方法を考慮してください:

  • 同じデータ エンティティが複数のプロジェクトに含まれておらず、プロジェクトが相互に競合することなく実行できることを確認します。
  • 実行に時間がかかるエンティティは、別個のプロジェクトに設定します。 これにより、他のプロジェクトはより速く実行できます。
  • データ サイズが小さい場合、差分のみエクスポートの代わりに、フル プッシュのみのエクスポートを使用します。 たとえば、一部のエンティティのレコード数が 1,000 以下の場合に、この操作を行うことができます。
  • 会社ごとにデータを個別にエクスポートする必要がない場合は、会社間エンティティを作成します。

会社間エンティティを作成するには:

  1. 会社エンティティごとに現在のものをコピーします。
  2. コピーされたエンティティの PublicCollectionName および PubliceEntityName の名前を変更します。
  3. 必要に応じて、DataAreaId の列を追加します。
  4. エクスポート中、主な会社によってフィルター処理されないように、PrimaryCompanyContext の値を削除します。
  5. ステージング テーブルを生成し、新しいエンティティをビルドして配置します。
  6. 新しいエンティティをテストし、正しく動作し、必要なスケールで適切に実行されていることを確認します。
  7. すべての会社間でエクスポートするオプションを選択せずに、新しいエンティティに対してバッチ内でエクスポート ジョブをスケジュールします。

メモ

BYOD 用のエクスポート プロジェクトに複数のエンティティを追加する場合、BYOD エクスポートの全体的な信頼性が損なわれないように注意して実行する必要があります。 同じプロジェクトに追加する エンティティ の数を決定する場合は、異なるパラメータを考慮する必要があります。 これらのパラメータには、エンティティの複雑度、予想されるエンティティごとのデータ量、ジョブレベルでのエクスポート完了までの全体的な時間が含まれている必要があります。 数百のエンティティを追加することは避ける必要があります。 エンティティの数が少ない複数のジョブを作成することをお勧めします。

BYOD のために 管理 > 定期的なデータ ジョブの管理 で定期的なエクスポートを使用することはサポートされていません。 バッチ処理でのエクスポート オプションを使用する必要があります。

差分エクスポート

データ エクスポートのエンティティを追加するとき、増分エクスポート (増分プッシュとも呼ばれます) またはフル プッシュをするかを選択できます。 作業する増分プッシュについては、この記事で前述されているように、データベースで変更追跡オプションを有効にし、適切な変更追跡オプションを指定する必要があります。

メモ

完全なプッシュは、エンティティからすべての既存のレコードを削除し、選択したエンティティから現在のレコードのセットを挿入します。

広域増分プッシュを選択した場合、最初のプッシュは常に完全なプッシュになります。 後続の変更を追跡できるようにするために、SQL でどのレコードが「追跡済み」であるかを知る必要があるため、このプッシュは完全です。 新しいレコードが挿入される、またはレコードが追加または削除されるたびに、対応する変更が宛先エンティティに反映されます。

最初のプッシュは常に完全なプッシュであるため、変更の追跡を有効にする前に、明示的な完全プッシュの実行は推奨しません。

最初に変更トラッキングを有効にし、増分プッシュでエクスポート ジョブをスケジュールすることをお勧めします。 この変更により、最初の完全プッシュと後続の増分エクスポートが処理されます。

メモ

増分のプッシュ設定が特定のシナリオで完全なプッシュのように機能する場合は、次の2つの理由があります。

  1. エンティティが増分プッシュを使用して初めてエクスポートされる場合、エンティティは完全なプッシュとして動作します。
  2. データ損失を防ぐために、増分のプッシュ エクスポートが保持期間中に実行されない場合、エクスポートは自動的に完全なプッシュ設定に戻ります。

タイムアウト

BYOD エクスポートの既定のタイムアウトは、切り捨て操作では 10 分、実際の一括挿入操作では 1 時間に設定されています。 ボリュームが多い場合、これらのタイムアウト設定が十分でなく、更新する必要がある場合があります。 データ管理>フレームワーク パラメーター>自分のデータベースの持ち込みに移動して、タイムアウト設定を更新することができます。 タイムアウトは会社ごとに固有の設定となるため、会社ごとに個別に設定する必要があります。

既知の制限

BYOD 機能には、次の制限があります。

同期中、データベースにアクティブなロックが存在してはいけません

BYOD は独自のデータベースであるため、データが同期されているときは Azure SQL データベースにアクティブなロックがないことを確認する必要があります。 同期中にデータベースにアクティブなロックがあると、書き込み速度が低下したり Azure SQL データベースへのエクスポートの完全な失敗につながる可能性もあります。

独自のデータベースに複合エンティティをエクスポートすることはできません。

現在、複合エンティティがサポートされていません。 複合エンティティを構成する個々のエンティティをエクスポートする必要がありますが、これは同じデータ プロジェクト内で行うことができます。

固有キーを持たないエンティティは、増分プッシュを使用してエクスポートすることは不可能

この制限は特に、数個の既製エンティティからレコードを段階的にエクスポートする場合に直面する可能性があります。 これらのエンティティはデータをインポートできるように設計されているため、固有のキーはありません。 ただし、変更追跡を、固有のキーがあるエンティティに対してのみ有効にすることができます。 したがって、増分プッシュには制限があります。 1 つの回避策は、必要なエンティティを拡張し、固有のキーを定義することです。

トラブルシューティング

増分プッシュが正常に機能しません

問題- あるエンティティに対して完全プッシュが発生すると、SELECT ステートメントにより BYOD に大量のレコードが表示される可能性があります。 ただし、増分プッシュの結果は BYOD のレコード数個だけになります。 増分プッシュによってすべてのレコードが削除され、BYOD で変更されたレコードのみが追加されます。

ソリューション - このような場合、対象のエンティティの変更追跡を無効にしてから再度有効にすることをお勧めします。 SQL変更追跡テーブルの状態が、予期された状態になっていない可能性があります。 また、同じテーブル (DMF、MR、Retail) をカバーする他の増分エクスポートがないことを確認してください。

SSIS エラーコード DTS_E_OLEDBERROR。 OLE DB エラーが発生しました。 エラー コード: 0x80004005

問題 - BYOD へのエクスポートが失敗し、SSIS 例外が発生します。

An OLE DB error has occurred. Error code: 0x80004005.

An OLE DB record is available. Source: "Microsoft SQL Server Native Client 11.0"  Hresult: 0x80004005  Description: "Communication link failure".

An OLE DB record is available. Source: "Microsoft SQL Server Native Client 11.0"  Hresult: 0x80004005  Description: "TCP Provider: An existing connection was forcibly closed by the remote host.

Failed to open a fastload rowset for <entityStaging>. Check that the object exists in the database.

OLE DB Destination failed the pre-execute phase and returned error code 0xC0202040.

解決策 - AZURE SQL BYOD サーバーの接続ポリシーがプロキシに設定されている場合に、この問題が発生することがあります。 SQL DB 接続アーキテクチャ の説明に従って、このポリシーを「リダイレクト」に変更する必要があります

  • Last updated on