FabricのDatabase Hubに関するよくある質問(プレビュー)

それらは補完的なものです。 OneLakeは分析のための統合データストレージを提供します。 データベースハブは統一された運用制御を提供します。 それらはミラーリング、分析準備、在庫共有などのシナリオを通じて交差します。 Database Hubはデータカタログではありません。 運用メタデータ、シグナル、アクションに焦点を当てています。 適切な場合は、PurviewやFabricの分析体験にリンクしています。

Database Hubは行動志向でありながら意図的に保守的です。 アクションは明示的で、常にエンドユーザーの承認を得ています(必要な権限が必要です)。 例としては、ネイティブの画面を開いたり、サポート対象のエージェント提案による推奨事項を確認したうえで適用したりすることが含まれます。 すべてのアクションは役割の権限を尊重し、承認が必要です。 データベースハブは意図と範囲を検証し、その後実行を権威あるサービスに委任します。 バルクアクションやより広範な設定変更は時間をかけて導入可能です。

No. データベースを移す必要はありません。 例えば、オンプレミスのSQL ServerインスタンスはAzure Arc経由で接続し、オンプレミスに留まりながらDatabase Hubに表示されます。 Azureデータベースはサブスクリプションのままです。 データベースハブは運用メタデータ、信号、アクションを集中管理します。 運用データを集中管理するものではありません。 Fabric OneLakeおよびFabricミラーリングは分析シナリオに使用できますが、これらはオプションであり、管理とは別です。

No. 必要なのは、ワークスペースに割り当てられたFabricライセンスか容量だけです。 少なくとも無料のFabricライセンスが必要です。 Database Hubは完全に無料です。

データベースハブのインベントリおよびセキュリティ・ポスチャーAPIはFabric容量を必要としません。 これらのコントロールプレーン操作は、Azure Resource Manager、Azure Resource Graph、Fabric catalog、そして健康監視ビューの場合はKustoにクエリを行います。 彼らは顧客のコンピュートをプロビジョニングしたり、基盤となるデータベースデータをFabricにコピーして表示するだけではいません。 データベースのストレージとコンピュートは、AzureまたはFabricデータベースがプロビジョニングされたリージョンに留まります。 FabricはテナントホームリージョンをFabricデータのデフォルトロケーションとして識別し、Database Hubのコントロールプレーン操作はそのリージョン内で実行されます。

Database Hubは公開データベース接続を必要としません。 Azure Resource GraphのメタデータやSQLのパフォーマンスシグナルを用いて、プライベートエンドポイントの背後にあるデータベースも含めて、健康状態やコンプライアンスのシグナルを表示します。

ワークスペースのアウトバウンドアクセス保護は、サポートされているワークスペースアイテムタイプにのみ適用され、サポートされたFabric F SKU上でホストされたワークスペースが必要です。 Database Hubの容量なしAPIはOAP保護のアイテムタイプとしてリストされていません。 Database HubがOAPサポートマトリックスに明示的に含まれ、必要な接続ルールでテストされるまでは、サポートされていないものとして扱ってください。

Microsoft FabricはGDPRやLGPDの義務を満たすためのアーキテクチャの一部として利用できます。 Database HubはMicrosoftのプライバシー、データ保護、コンプライアンスの枠組みに従っています。 Database Hubは主にリソースメタデータ、構成姿勢、識別子、選択された健康指標を処理し、データベースアプリケーション行は扱いません。 これらの値は依然として規制データとして扱われます。 コンプライアンスは共同責任です 地域配置、アクセス制御、保持、テレメトリー、プライベート接続、データ主体手続き、および該当するMicrosoft契約および監査文書をレビューしてください。

Microsoft Fabricは2026年9月にGovernment Community Cloud(GCC)Highでパブリックプレビューを開始しました。 ワークロードや機能の利用可能性は時間とともに変動し、拡大します。

観測性は、CPU、I/O、接続性、エラー条件、姿勢、利用率などのエステートレベルの健康状態および圧力信号に焦点を当てています。 これらのシグナルは深刻度の状態にまとめられ、チャートよりも先に問題が浮かび上がります。 目標は、注意が必要な場所を特定し、個人やエージェントが分析できる範囲を明確に示すことです。 高度なエンジン特有の診断機能はネイティブツールで引き続き利用可能であり、ドリルスルーアクションを通じてアクセス可能です。

Estateビューをサブスクリプションまたはリソース グループでフィルター処理し、カスタム ビューを保存して共有します。 ビューを共有する場合、その構成は共有され、基盤となるリソースへのアクセスは共有されません。 受信者は既存の権限で許可されているリソースのみを見ることができます。

サードパーティツールは特定のエンジンや環境向けに深い機能を提供でき、別のセットアップやインフラが必要になることもあります。 Database HubはMicrosoftプラットフォームに組み込まれており、サポートされているSQL、NoSQL、オンプレミス、Azure、Fabricリソースを網羅しています。 インベントリ、スコープ、アクション、エージェント主導の洞察を統合し、より深い作業が必要な際には専門的なネイティブツールとつなげてくれます。 すべての専門的なツールを置き換えることを目指しているわけではありません。

Database Hubは人間主導とエージェント支援の両方のワークフローをサポートします。 エージェントはデータベースハブのコンテキストを利用し、調査を行い、アクションを提案できますが、実行は既存の権限や承認境界を尊重し続けます。

Yes. Copilotは会話型インターフェースです。 エージェントはその背後にある分析的かつ運用的なエンジンです。 CopilotはUIで見られる同じスコープデータとエージェントの調査結果を用いて、現実的な説明と要約を提供します。 Copilotがアクションを推奨する際、それは明示的なエージェント機能と監査可能な提案によって裏付けられます。 任意形式の実行はありません。

Yes. 現在のプレビューでは、Microsoft SQLデータベースはパフォーマンスデータを収集するために追加の設定が必要です。 手順については、「Microsoft SQLのパフォーマンス監視を有効にする」を参照してください。

No. Database Hubはこれらの技術を置き換えるのではなく、それを基盤に構築しています。 Azure Arcは、オンプレミスのSQL ServerインスタンスをAzureに接続する仕組みとして機能しています。 Azureポータルとネイティブツールは、設定と実行のための権威あるサーフェスとして機能しています。 データベースハブは、その上に特化した制御プレーンとして機能します。 統合されたインベントリ、スコープ付きのコンテキスト、エージェント駆動の洞察、明示的なアクションを提供し、実行を正しいネイティブサーフェスにルーティングします。 Azureポータル、SSMS、Azure Data Studio、Visual Studio Code、Fabricのツールは従来通り引き続き利用できます。

No. Database HubはMicrosoft Fabric経由でアクセスできますが、Azure上で動作するAzure Cosmos DBアカウントをどこでも検出できます。 これらのアカウントは既存のサブスクリプションのままです。ディスカバリーやエステートの監視は、データをFabricに移動またはミラーリングする必要はありません。

No. 検出は、既存のMicrosoft Entra IDとAzure RBAC権限に基づいて、Azure Cosmos DBアカウントに対して自動的に行われます。

エステートはAzure Cosmos DBアカウントをリストアップしており、その中のデータベースやコンテナは記載しません。

No. ベースラインディスカバリーはAzureリソースインベントリを使用し、ベースライン監視は既存のAzure Monitorメトリクスを利用します。 フリートアナリティクスは別のオプトインパイプラインです。

データベースやコンテナでデータを照会するには、別途Cosmos DBのデータプレーンロール割り当て(または許可されている場合はアカウントキー)が必要で、さらにアカウントへのネットワークアクセスが必要です。 アカウントをエ ステートで可視化するリソースレベル(管理面)アクセスはこれを許しません。

Azureアクセス、サインイン済みテナント、アクティブフィルター、選択したアカウント、または時間帯は異なる場合があります。 リンクやビューを共有しても追加のアクセス権は与えられません。 各人は自分のアイデンティティが閲覧権限を持つリソースだけを見ることができます。

選択されたリソースやフィルターを確認してください。 ダッシュボードの値はその選択内容を示しており、その範囲は Estate のインベントリより狭い場合があります。

ビューは異なるリソース、時間範囲、細分度、集計、リフレッシュ時間などを利用できます。 同じ指標を同じ期間の1つのアカウントで比較してください。

どちらでもない。 つまり、そのビューに対して利用可能な値が存在しないということです。 選択された区間、アカウントの活動、APIタイプごとの適用性、アクセス、処理遅延を確認してから結論を出してください。

パフォーマンスダッシュボードは、RU消費量、スロットリング、レイテンシ、可用性などのアカウントおよびエステートレベルの指標に焦点を当てています。 クエリレベルの診断、パーティションキーのホットスポット解析、診断ログ検索は提供していません。 これらの調査にはAzureポータル、Data Explorer、Cosmos DBの診断ログを使ってください。

No. Azureポータルや既存の自動化を使ってAzure Cosmos DBのスループットを変更してください。

対等を前提にしないでください。 Cosmos DB の監査ログ機能は、まだ評価されていません。 評価が利用できないからといって、コントロールが無効化されているわけではありません。

No. Database Hubの調査結果を、適用されるサービスやセキュリティツールとともに範囲のある指針として活用しましょう。 ここで説明するCosmos DBの監視ワークフローは、アカウントを自動的に修復するわけではありません。

SQLはデータベース作成時に一歩で容量を割り当てます。 Cosmos DBは、スループットなし、請求なしの軽量アカウント作成ステップと、スループット、パーティションキー、インデックス作成の設定と請求開始のコンテナ作成を分離しています。 Database Hubのインライン作成フローは最初のステップのみを反映しています。2番目のステップはAzureポータルへのリンクを提供します。

Yes. Database Hubから作成されたアカウントは、選択したサブスクリプションのAzureリソースです。 プロビジョニング済みまたは自動スループットを備えたデータベースとコンテナが作成されるまでは料金は発生しません。

No. Database HubはMicrosoft Fabric経由でアクセスできますが、サポートされているAzure Database for PostgreSQL Flexible ServerインスタンスをAzureで発見できます。 これらのサーバーは既存のサブスクリプションのままです。ディスカバリーやエステートの監視は、データをFabricに移動またはミラーリングする必要がありません。

No. 検出は、既存のMicrosoft Entra IDおよびAzure RBAC権限に基づいて、Azure Database for PostgreSQLのフレキシブルサーバーインスタンスに対して自動的に行われます。

PostgreSQLのインベントリエンティティはフレキシブルサーバーインスタンスです。 サーバーは複数のデータベースをホストできます。 サーバーの数をアプリケーションデータベースの数と解釈しないでください。

ベースラインディスカバリーはAzureリソースインベントリを使用し、ベースライン監視は既存のAzure Monitorメトリクスを利用します。 クエリ ストア、SQL監視拡張プロパティ、Arcのインストールは必要ありません。 テナントアクセス権とAzureリソース/メトリック権限は依然として適用されます。

AzureリソースアクセスとPostgreSQLデータベースアクセスは別々です。 接続するには、クライアントがネットワークの到達可能性と認可されたデータベースの識別情報が必要です。 Estate visibilityが接続を許可するとは思わず、柔軟なサーバーの認証やネットワーク設定を確認してください。

Azureアクセス、サインイン済みテナント、アクティブフィルター、選択したサーバー、または時間帯は異なる場合があります。 リソースやテレメトリが欠けていると判断する前に、これらの設定を比較してください。 共有リンクは追加のアクセス権を与えません。

選択されたリソースやフィルターを確認してください。 ダッシュボードの値はその選択内容を表しており、その対象範囲は Estate のインベントリより狭い場合があります。 また、価値を完全な遺産評価と解釈する前に、利用できないまたは適用できない指標がないかも確認してください。

ビューは異なるリソース、時間範囲、細分度、集計、リフレッシュ時間などを利用できます。 同じサーバーで同じ期間のメトリクスをまず比較してください。 遺産の概要は、単一サーバーのチャートと直接比較できるわけではありません。

どちらでもない。 つまり、そのビューに対して利用可能な値が存在しないということです。 選択された区間、サーバー状態、メトリクスの適用可能性、アクセス、処理遅延を確認してから結論を出してください。

現在のプレビューでは、PostgreSQL の監視は既存の Azure Monitor メトリックを使用しており、クエリ ストア に基づく上位クエリ、クエリ プラン、待機イベント分析、ログ検索などのクエリ レベルの診断は Database Hub には含まれません。 クエリレベルの調査にはAzureポータルとネイティブのPostgreSQLツールを使いましょう。

SQL専用の監視テンプレートやSQL ADXプロキシは、PostgreSQL Azure Monitorパスには含まれていません。 これらのPostgreSQLメトリクスに関するアクティベーターアラートは現在サポートされていません。 この制限はサービスの別個のAzure Monitorアラートオプションを取り除くものではありません。

現在のプレビューでは、Database HubがMicrosoft Entra認証が有効になっているか、Microsoft Entra認証が強制されているか、保存データの暗号化で顧客管理キーが使用されているか、そしてパブリックネットワークアクセスが無効化されているかをチェックします。 これらのチェックは完全なコンプライアンス監査ではありません。 権威あるAzureサービスおよびセキュリティツールを使ってセキュリティ要件を検証します。

No. Database Hubの調査結果を、適用されるサービスやセキュリティツールとともに範囲のある指針として活用しましょう。 証拠を確認し、適切なサービスを通じて許可された変更を適用してください。 ここで説明するPostgreSQLの監視ワークフローは、サーバーを自動的にリメディタリングするわけではありません。

Yes. Database Hubから作成されたフレキシブルサーバーは、選択したサブスクリプション内のAzureリソースです。 展開前に設定とコストを確認してください。

関連するコンテンツ

• データベースハブとは何ですか?