Azure SQL Managed Instance に関してよく寄せられる質問 (FAQ)

SQL Managed Instance でサポートされている機能の一覧については、Azure SQL Managed Instance の機能に関するページを参照してください。

Azure SQL Managed Instance と SQL Server 間での構文と動作の違いについては、T-SQL と SQL Server の相違点に関するページを参照してください。

使用可能なハードウェアの特性については、ハードウェアの構成間の技術的相違点に関するページを参照してください。 使用可能なサービス レベルとその特性については、サービス レベル間の技術的相違点に関するページを参照してください。

すべてのお客様は、任意のサービス レベルを利用できます。 ソフトウェア アシュアランスの対象となる Standard と Enterprise の両エディションは、Azure ハイブリッド特典 (AHB) を使用して、General Purpose (現在プレビュー段階の Next-gen General Purpose サービス レベルのアップグレードを含む) または Business Critical サービス レベルに交換できます。その際の交換比率は、1 Standard エディション = 1 General Purpose、1 Enterprise エディション = 1 Business Critical、1 Enterprise エディション = 4 General Purpose、4 General Purpose = 1 Enterprise エディションです。 詳細については、AHB の具体的な権利に関する記事を参照してください。

サポートされているサブスクリプションの種類の一覧については、「サポートされているサブスクリプションの種類」を参照してください。

マネージド インスタンスは、ほとんどの Azure リージョンで作成できます。詳細については、SQL Managed Instance でサポートされているリージョンに関する記事を参照してください。 現在サポートされていないリージョンでマネージド インスタンスが必要な場合には、Azure portal 経由でサポート リクエストを送信してください。

SQL マネージド インスタンスには、使用できるサブネットの数と、プロビジョニングできる仮想コアの数という 2 つの規定の制限があります。 制限は、サブスクリプションの種類とリージョンによって異なります。 サブスクリプションの種類ごとの、リージョン別のリソースの制限の一覧については、リージョン別のリソースの制限に関する記事を参照してください。 これらは、要求に応じて増やすことができるソフト制限です。 現在のリージョンでより多くのマネージド インスタンスをプロビジョニングする必要がある場合、Azure portal を使用してクォータを増やすためのサポート リクエストを送信します。 詳細については、「Azure SQL Database のクォータの増加を要求する」を参照してください。

SQL Managed Instance あたり 100 データベースの制限は、General Purpose および Business Critical サービス レベルでは変更できないハード リミットです。 Next-gen General Purpose サービス レベルでは、最大 500 個のデータベースを保有できます。

ワークロードに合う、以下のような他の Azure フレーバーに移行することをご検討ください。Azure SQL Database Hyperscale または Azure Virtual Machines 上の SQL Server があります。

Azure Virtual Machines 上の SQL Server またはメモリおよび CPU 最適化された Azure SQL Database への移行をご検討ください。

製品の欠陥や既知の問題については、「既知の問題」を参照してください。

新機能とプレビュー機能については、「新機能」を参照してください。

マネージド インスタンスは、Azure portal、PowerShell、Azure CLI、および ARM テンプレートからプロビジョニングできます。

はい。サブスクリプションがサポートされているサブスクリプションの種類に属している場合、既存のサブスクリプションでマネージド インスタンスをプロビジョニングできます。

これは、サブネット名を正規表現 ^[a-zA-Z_][^\/:*?"<>|`'^]*(?<![.\s])$ と照合して検証する、基になるコンポーネントによる現在の制限です。 正規表現および有効なサブネット名を渡すすべての名前は、現在サポートされています。

マネージド インスタンスは、Azure portal、PowerShell、Azure CLI または ARM テンプレートからスケーリングできます。

はい、できます。 手順については、リージョン間でリソースを移動する方法に関する記事を参照してください。

マネージド インスタンスは、Azure portal、PowerShell、Azure CLI または Resource Manager REST API を使用して削除できます。

新しいマネージド インスタンスの作成やサービス レベル (仮想コア、ストレージ) の変更にかかると予想される時間は、いくつかの要因に左右されます。 詳細については、「管理操作」を参照してください。

各データベースの復元は、定義された保有期間全体 (数秒後に作成されて削除されたデータベースも含む) の間保証されます。 データベースが作成、削除、または復元されると、データを保持するために異なる間隔でバックアップが作成されるため、特定の保持期間にわたって復元できます。 バックアップ操作が完了する前にデータベースが削除された場合、次のエラーで削除操作がブロックされることがあります。

Message database 'backup_restore_db_lkg_native_restore' already exists. Choose a different database name.

このエラーを回避するには、データベースを同じ名前で作成する前に、削除操作の状態を確認します。 詳細については、「sys.dm_operation_status」を参照してください。 操作の状態が [完了] と表示されると、同じ名前のデータベースを復元または作成できます。

次の一般的なユースケースにおいて、このエラーが発生する可能性があります。

• 複数のデータベースが削除され、短い時間に連続して同じ名前で再作成された場合。 データベースが削除されると、次の図に示されているように、削除操作が完了する前に、トランザクション ログの残りの末尾が同期的にバックアップされます。

  

  ログ末尾がバックアップされ、削除操作が完了するまで、同じ名前でデータベースを作成することはできません。 削除操作の順次の性質により、短い間に連続して削除されたデータベースはキューに格納され、データベース削除のプロセスが長引き、同じ名前での作成が遅延する可能性があります。

• データベースが復元され、完全バックアップが作成される前に削除された場合。 データベースを復元する場合、復元プロセスの最初の手順は、データベースの新しい完全バックアップを作成することです。 データベースを復元した後、完全バックアップが完了する前にデータベースをすぐに削除しようとすると、完全バックアップが作成されてデータベースの削除操作が完了するまで、データベースを削除して、同じ名前で別のデータベースを作成することはできません。 データベースのサイズによっては、完全バックアップに数時間かかることがあります。

サブスクリプションが無料の SQL Managed Instance の対象ではない可能性があります。 それ以外の場合は、サブスクリプションごとに 1 つの無料インスタンスとする制限があります。 別のインスタンスを 1 つ作成するには、既存の無料インスタンスを削除する必要があります。 無料インスタンスを最近削除した場合は、無料プランのバナーが再表示されるまでに最大 1 時間かかります。

その月のクレジットが不足している可能性があります。 Azure portal で SQL マネージド インスタンスに移動し、状態をチェックして、クレジットの不足によってインスタンスが停止状態になっているかどうかを確認します。

この機能は、現在使用できません。

はい。Azure Storage から自動バックアップの復元も、SQL Server Management Studio (SSMS) を使用するデータベース バックアップの復元もできます。

リソースの制限にもかかわらず、無料の SQL Managed は、影響を与えずにワークロードをテストできるように設計されています。 無料の SQL Managed Instance を使用する環境のパフォーマンスは、インスタンスの実稼働バージョンのパフォーマンスと同じです。

無料の SQL Managed Instance には、4 個と 8 個の仮想コア オプションが用意されています。 より多くのリソースを持つインスタンスが必要なビジネスの場合は、本格的な有料 SQL Managed Instance を作成します。

無料の SQL Managed Instance のバックアップ オプションは変更できません。

現在、Student サブスクリプションは対象外です。 対象となるサブスクリプションについては、「無料の SQL Managed Instance プランの前提条件」を確認してください。

マネージド インスタンス名の変更はサポートされていません。

はい。SQL Managed Instance の既定の DNS ゾーン .database.windows.net は自分で変更できます。 ただし、マネージド インスタンスの FQDN のホスト名の部分は同じままにする必要があります。

既定値の代わりに別の DNS ゾーン、たとえば .contoso.com などを使用するには、次のようにします。

• SQL Server クライアント ネットワーク ユーティリティ (CliConfg) を使用してエイリアスを定義します。 使用できるのはマネージド インスタンス ホスト名と、マネージド インスタンス ホスト名の後にカスタム ドメイン名を続けた名前のいずれかです。 CliConfg ツールは、64 ビット バージョン (C:\Windows\System32\cliconfg.exe) を使用するのかあるいは 32 ビット バージョン (C:\Windows\SysWOW64\cliconfg.exe) を使用するのかに応じて、エイリアスをレジストリの "HKLM\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo" あるいは "HKLM\SOFTWARE\WOW6432Node\Microsoft\MSSQLServer\Client\ConnectTo" の下に追加するだけなので、グループ ポリシーまたはスクリプトを使用して行うこともできます。 両方を使用すると、32 ビット プログラムと 64 ビット プログラムでエイリアスを解決できるようになります。
• CNAME レコードを DNS で使用し、マネージド インスタンス ホスト名がマネージド インスタンス FQDN を指すようにします。 この場合は、 Microsoft Entra ID (TrustServerCertificate=TRUE) による認証を使用する場合、 が必要になります。
• A レコードを DNS で使用し、マネージド インスタンス ホスト名がマネージド インスタンス IP アドレスを指すようにします。 IP アドレスを使用するのがお勧めできないのは、予告なく変更される場合があるからです。 この場合、Microsoft Entra 認証を使用するときは TrustServerCertificate=TRUE が必要です。

Azure SQL Managed Instance で提供されるコンピューティングおよびストレージ サイズあたりのパフォーマンス レベルは、Azure SQL Database の他のデプロイ オプションと同じです。 単一のインスタンスにデータを統合する場合、または単に SQL Managed Instance でのみサポートされている機能が必要な場合は、エクスポートおよびインポート (BACPAC) 機能を使用してデータを移行できます。 SQL Database の SQL Managed Instance への移行に関して検討可能な他の方法を、次に示します。

• Data Source External を使用する
• SQLPackage を使用する
• BCP を使用する

1 つの方法として、データベースを BACPAC にエクスポートし、その BACPAC ファイルをインポートします。 データベースが 100 GB 未満の場合は、これが推奨される方法です。

データベース内のすべてのテーブルに主キーがあり、データベース内にインメモリ OLTP オブジェクトが一切ない場合は、トランザクション レプリケーションを使用できます。

SQL Server インスタンスを移行するには、SQL Server から Azure SQL Managed Instance へのガイドに関する記事を参照してください。

他のプラットフォームからの移行に関する移行の情報については、Azure データベース移行ガイドを参照してください。

マネージド インスタンスと SQL Server のパフォーマンスを比較するために、まずは「Azure SQL Managed Instance と SQL Server のパフォーマンス比較に関するベスト プラクティス」の記事をご覧ください。

「SQL Managed Instance と SQL Server の間でパフォーマンスの差が生じる主な原因」を参照してください。 トランザクション ログ ファイルのサイズは、General Purpose SQL Managed Instance のパフォーマンスに影響を与える可能性があります。 詳しくは、General Purpose に対するログ ファイルのサイズの影響に関する記事をご覧ください。

次の方法で、マネージド インスタンスのパフォーマンスを最適化することができます。

• 自動チューニングでは、AI と機械学習に基づく継続的なパフォーマンス チューニングによって、最大限のパフォーマンスと安定したワークロードが実現されます。
• インメモリ OLTP では、トランザクション処理ワークロードのスループットと待機時間が改善され、ビジネスの分析情報がより迅速に提供されます。
• アプリケーションとデータベース チューニングのベスト プラクティスのいくつかを適用します。
• ワークロードが多数の小さなトランザクションで構成されている場合は、待機時間を短縮しスループットを向上させるために接続の種類をプロキシからリダイレクト モードに切り替えます。

General Purpose インスタンスのパフォーマンスを向上させるには、データ ファイルのサイズを大きくするすることを検討してください。 General Purpose インスタンスでストレージ パフォーマンスを最適化するには、General Purpose レベルのストレージ ベスト プラクティス ガイドラインに関するページを参照してください。

「SQL Managed Instance の待機統計値を分析する」を参照してください。 待機統計値は、クエリ時間が長い理由を理解し、待機中のクエリをデータベース エンジンの中から特定する目的で役立つ情報です。

MSSQLSERVER_833 は、I/O 要求の完了に 15 秒以上かかったことを示します。 Azure SQL Managed Instance でのこのエラーは、ワークロードではなく、インフラストラクチャの全体的な状態に関連しています。 クラウド環境とリモート ストレージを利用するシステムには、1 つの I/O 要求に影響を与える複数のアーキテクチャ レイヤーがあります。 この動作は想定されており、一時的なネットワークの問題や Azure ストレージ リソースが一時的に使用できなくなったことが一般的に発生するサービスの既知の制限です。 通常、システムは介入なしで回復します。

この状況はまれであり、リモート ストレージへの I/O 要求の平均待機時間には影響しません。 I/O 要求を開始するワークロードまたはスレッドによっては、特定のシナリオで SQL コマンドのタイムアウトと待機時間の増加が観察される場合もあれば、影響を受ける可能性はほとんどありません。 たとえば、先行読み取りページ アクセスなど、実行時間の長い I/O 要求のブロック操作はすべて影響を受けないことがよくあります。

次世代 General Purpose サービス レベルのアップグレード (現在パブリック プレビュー段階) を使用すると、追加コストなしでパフォーマンスと信頼性が向上するため、この問題を軽減するのに役立ちます。 お客様は、サービス品質を向上させるためにそれを探索することをお勧めします。

このエラーが永続的に発生する場合は、ワークロード パターン、ストレージ パフォーマンス、ネットワーク構成を確認することを検討してください。 さらに、I/O 待機時間の要件が低いアプリケーション向けに設計されているため、Business Critical サービス レベルの使用を検討してください。

SQL Managed Instance の使用状況とパフォーマンスを監視してアラートを生成するためのすべてのオプションについては、「Azure SQL Managed Instance の監視オプションに関するブログ投稿」を参照してください。 SQL Managed Instance のリアルタイムのパフォーマンス監視については、Azure SQL Managed Instance のリアルタイム パフォーマンス監視に関する記事を参照してください。

監視とパフォーマンス チューニングに関する記事を参照してください。

Azure SQL Managed Instance のリアルタイム パフォーマンス監視に関する記事を参照してください。

はい。SQL Profiler は SQL Managed Instance でサポートされています。 詳細については、SQL Profiler に関する記事を参照してください。 ただし、監視対象インスタンスへの影響が少ない "トレース" アクティビティのための拡張イベントを代わりに検討する必要があります。 詳細については、拡張イベントに関する記事を参照してください。

いいえ、これらはサポートされていません。 DMV と クエリ ストアを SQL Profiler と XEvent と共に使用して、データベースを監視できます。

「SQL Server と Azure SQL で CPU 使用率を監視する」を参照してください。

はい。 詳細については、SQL Managed Instance のアラートの作成に関する記事を参照してください。 ヒントとテクニックについては、ブログを参照してください。

できません。アラート メトリックは、マネージド インスタンスでのみ使用できます。 Managed Instance 内の個々のデータベースのアラート メトリックは使用できません。

SQL Managed Instance のストレージ サイズは選択したサービス レベル (General Purpose、Next-gen General Purpose または Business Critical) に応じて異なります。 これらのサービス レベルのストレージ制限については、「リソースの制限」を参照してください。

インスタンスで使用可能なストレージの最小量は 32 GB です。 ストレージは、最大ストレージ サイズになるまで、32 GB ずつ追加できます。 最初の 32 GB は無料です。

はい。コンピューティングとは別に、アドオン ストレージをある程度まで購入できます。 この表にある "インスタンスの予約済み最大ストレージ" を参照してください。

ストレージのパフォーマンスを最適化するには、「General Purpose でのストレージのベスト プラクティス」を参照してください。

いいえ。バックアップ ストレージがマネージド インスタンス ストレージ領域から差し引かれることはありません。 バックアップ ストレージはインスタンス ストレージ領域から独立しており、サイズは制限されていません。 バックアップ ストレージは、インスタンス データベースのバックアップを保持する期間に制限があり、35 日まで構成可能です。 詳細については、「自動バックアップ」を参照してください。

SQL マネージド インスタンスで自動バックアップがいつ実行されたかを追跡するには、バックアップ アクティビティの監視に関する記事をご覧ください。

はい。Azure Blob Storage にコピーのみの完全バックアップを作成できます。ただし、これはマネージド インスタンスにのみ復元できます。 詳細については、「コピーのみのバックアップ」を参照してください。 ただし、暗号化に使用される証明書にアクセスできないため、データベースがサービス マネージド TDE によって暗号化されている場合、コピーのみのバックアップは不可能です。 このような場合、ポイントインタイム リストア機能を使用して、データベースを別のマネージド インスタンスに移動するか、カスタマー マネージド キーに切り替えてください。

はい。SQL Server 2005 以降のバージョンでサポートされており、使用可能です。 ネイティブ復元を使用するには、.bak ファイルを Azure Blob Storage にアップロードし、T-SQL コマンドを実行します。 詳細については、「URL からのネイティブ復元」を参照してください。

はい。ただし、SQL Server 2022 を対象として、SQL Server 2022 のメインストリーム サポート期間中だけです。 将来的には、データベースの形式の変更を必要とする機能が Azure SQL Managed Instance に導入され、バックアップと SQL Server の最新バージョンとの間に互換性がなくなる可能性があります。 そのような機能にアクセスするには、明示的なオプトインが必要です。

システム データベースは、フェールオーバー グループのセカンダリ インスタンスにはレプリケートされません。 そのため、オブジェクトがセカンダリに手動で作成されていない限り、セカンダリ インスタンスではシステム データベースのオブジェクトに依存するシナリオは実現できません。 回避策については、「システム データベースのオブジェクトに依存するシナリオを実現させる」を参照してください。

必要な NSG と UDR のルールは「サービス支援サブネット構成」に記載されており、サービスによって自動的に設定されます。 これらのルールは、あくまでもサービスを維持するために必要なものであることに注意してください。 マネージド インスタンスに接続してさまざまな機能を使用するには、管理が必要な、機能固有のルールを追加で設定する必要があります。

SQL Managed Instance は、管理ポートにルールを設定する役割を担います。 これは、サービス支援サブネット構成という機能によって実現されます。 これは、SLA を満たすために、管理トラフィックが中断されないようにするためです。

はい。 Network Watcher フロー ログを構成することで、ネットワーク セキュリティ グループを介して送信されるトラフィックを分析できます。

はい。 マネージド インスタンスがプロビジョニングされたら、ポート 1433 へのインバウンド アクセスを制御する NSG を設定できます。 IP 範囲をできるだけ絞り込むことをお勧めします。

いいえ。 これは、いくつかの理由によりサポートされていません。

• 受信した管理要求への応答を表すトラフィックのルーティングは非対称であり、機能しない可能性があります。
• Azure Storage にルーティングされるトラフィックは、処理能力の制約と待機時間の影響を受けるため、期待されるサービスの品質と可用性は提供できません。
• これらの構成はエラーが発生しやすく、サポートされていません。

はい。 これを実現する最も簡単な方法は、NVA 経由でトラフィックをルーティングするために、マネージド インスタンス サブネットに関連付けられている UDR に 0/0 ルールを追加することです。

サブネットには、十分な数の利用可能な IP アドレスが含まれている必要があります。 SQL Managed Instance の VNet サブネットのサイズを決定するには、「Azure SQL Managed Instance に必要なサブネット サイズおよび範囲を決める」を参照してください。

SQL マネージド インスタンスをプロビジョニングするサブネットに十分な IP アドレスが存在しない場合は、新しいサブネットを作成して、それに SQL マネージド インスタンスを移動します。 また、新しいサブネットを作成するときは、将来の更新操作で同様の状況が発生しないよう、IP アドレスを多めに確保しておくことをお勧めします。 方法については、「Azure SQL Managed Instance を複数のサブネットに移動する」を参照してください。

いいえ。 空のサブネット、または既にマネージド インスタンスが含まれているサブネットのいずれかを使用できます。

マネージド インスタンスが含まれている場合は、できません。 これは、Azure のネットワーク インフラストラクチャの制限です。 アドレス空間は、空のサブネットにしか追加できません。

はい。 SQL マネージド インスタンスは、同じ仮想ネットワーク内の別のサブネット、またはオンラインで別の仮想ネットワーク内の別のサブネットに、移動できます。 方法については、「Azure SQL Managed Instance を複数のサブネットに移動する」を参照してください。

これはは必須ではありません。 Azure SQL Managed Instance 用の仮想ネットワークを作成するか、または Azure SQL Managed Instance の既存の仮想ネットワークを構成することができます。

いいえ。 現時点では、他のリソースの種類が既に含まれているサブネットに Managed Instance を配置することはサポートされていません。

いいえ、サポートされていません。 マネージド インスタンスのホスト名は、マネージド インスタンスの仮想クラスターの前にあるロード バランサーにマップされます。 1 つの仮想クラスターが複数の Managed Instance をホストすることが可能なため、名前を指定しないで適切な Managed Instance に接続をルーティングすることはできません。 SQL Managed Instance 仮想クラスターのアーキテクチャの詳細については、「仮想クラスターの接続アーキテクチャ」を参照してください。

現時点では、Managed Instance に静的 IP アドレスを付与できるのはプライベート エンドポイントのみに限定されています。

まれに必要な状況では、サービスのセキュリティと信頼性の向上を目的としたテクノロジ スタックの変更により、マネージド インスタンスを新しい仮想クラスターまたは仮想クラスター内の別の仮想マシン グループにオンラインで移行する場合があります。 新しい仮想マシン グループまたは仮想クラスターに移行すると、マネージド インスタンスのホスト名にマップされている IP アドレスが変更されます。 マネージド インスタンス サービスは、静的 IP アドレスのサポートを提供することはなく、定期的なメンテナンス サイクルの一環として、そのIP アドレスを予告なしに変更する権限を有しています。

上記の理由から、VNet ローカルとパブリックのエンドポイントには、関連付けられているドメイン名を介してのみアクセスする必要があります。 IP アドレスの不変性に依存すると、サービスは正常であるのに、長時間使用できなくなる可能性があるため、依存しないことを強くお勧めします。

仮想ネットワークの外部から到達可能な静的 IP アドレスが必要な場合は、フロントエンドのパブリック IP アドレスを使用して Azure Firewall をデプロイし、受信トラフィックを Managed Instance のプライベート エンドポイントに変換するように NAT 規則を構成します。 次に、DNS 解決を設定するか、SQL クライアントが Managed Instance の完全修飾ドメイン名を介してファイアウォールのパブリック IP アドレスに接続するようにクライアント エイリアスを構成します。

はい。パブリック エンドポイントを有効にして、インターネットからのインバウンド トラフィックが SQL Managed Instance に到達できるようにすることができます。 詳しくは、パブリック エンドポイントでの SQL Managed Instance の使用および SQL Managed Instance でのパブリック エンドポイントの構成に関する記事をご覧ください。

いいえ。カスタム ポートは使用できません。 SQL Managed Instance は、VNet ローカル エンドポイントの場合は既定のポート番号 1433 を使用し、パブリック データ エンドポイントの場合は既定のポート番号 3342 を使用します。

異なるリージョン内の 2 つのマネージド インスタンスを接続するには、グローバル仮想ネットワーク ピアリング (VNet ピアリング) と Azure Virtual WAN の両方が推奨される方法です。 Express Route 回線ピアリングはもう 1 つのオプションです。 環境内でどちらのオプションも使用できない場合、他の接続方法はサイト間 VPN 接続のみです。 Azure portal、PowerShell、または Azure CLI を使用してサイト間 VPN を構成します。

新しく作成された仮想クラスターのグローバル仮想ネットワーク ピアリング (VNet ピアリング) のサポートが、2020 年 9 月 22 日に Azure SQL Managed Instance に追加されました。 そのため、仮想ネットワーク ピアリングは、2020 年 9 月 22 日以降に空のサブネットで作成されたマネージド インスタンスでサポートされます。 この日付より前にデプロイされたインスタンスについては、グローバル仮想ネットワーク ピアリングの制約のために、ピアリングのサポートが同じリージョン内のネットワークに制限されます。 詳細については、Azure Virtual Networks のよく寄せられる質問に関する記事の関連セクションを確認してください。

2020 年 9 月より前に作成されたインスタンスでグローバル VNet ピアリングを使用するには、メンテナンス期間を構成するか、インスタンスを新しいサブネットに移動することを検討してください。どちらのオプションも、グローバル仮想ネットワーク ピアリングをサポートする新しい仮想クラスターにインスタンスが移動されるためです。

必要に応じて、仮想クラスターでグローバル仮想ネットワーク ピアリングがサポートされているかどうかを確認する方法を参照してください。

データ窃盗リスクを軽減するために、以下に示す一連のセキュリティ設定および制御を適用することをお勧めします。

• すべてのデータベースで Transparent Data Encryption (TDE) を有効にする。
• 共通言語ランタイム (CLR) を無効にする。 これは、オンプレミスでも推奨される設定です。
• Microsoft Entra 認証のみを使用してください。
• 低特権の DBA アカウントでインスタンスにアクセスする。
• sysadmin アカウント用に Jumpbox への JIT アクセスを構成する。
• SQL 監査を有効にしてアラート メカニズムと統合する。
• Microsoft Defender for SQL スイートから脅威検出を有効にする。
• サービス エンドポイント ポリシーをサブネットに適用して、Azure Storage へのアウトバウンド トラフィックを制御する。
• CREATE EXTERNAL TABLE AS SELECT (CETAS) は既定で無効になっています。 allowPolyBaseExport サーバー構成オプションを使って CETAS を有効にするには、「CREATE EXTERNAL TABLE AS SELECT (CETAS)」をご覧ください。

はい。 Azure SQL Managed Instance でのプライベート DNS 名の解決に関する記事をご覧ください。

はい。 Azure SQL Managed Instance でのプライベート DNS 名の解決に関する記事をご覧ください。

タイム ゾーン構成は、マネージド インスタンスの初回プロビジョニング時に設定できます。 既存のマネージド インスタンスのタイム ゾーンの変更はサポートされていません。 詳細については、タイム ゾーンの制限に関する記事を参照してください。

対処方法としては、適切なタイム ゾーンで新しい Managed Instance を作成し、手動バックアップおよび復元を実行するか、クロスインスタンスのポイントインタイム リストア (推奨) を実行します。

はい。お客様は、sysadmin ロールのメンバーであるログインを作成できます。 sysadmin 権限を持つお客様は、インスタンスを運用する責任を負うことになり、これは SLA コミットメントに悪影響を与える可能性があります。 sysadmin サーバー ロールにログインを追加するには、「Microsoft Entra 認証」を参照してください。

はい。Azure SQL Managed Instance では Transparent Data Encryption (TDE) がサポートされています。 詳細については、SQL Managed Instance の Transparent Data Encryption に関する記事を参照してください。

はい。BYOK シナリオの Azure Key Vault は、Azure SQL Managed Instance で使用できます。 詳細については、カスタマー マネージド キーを使用した Transparent Data Encryption に関する記事を参照してください。

はい、できます。 暗号化された SQL Server データベースを移行するには、既存の証明書をエクスポートして SQL Managed Instance にインポートした後、データベースの完全バックアップを実行してマネージド インスタンスに復元する必要があります。

また、Azure Database Migration Service を使用して、TDE で暗号化されたデータベースを移行することもできます。

Azure Cloud Shell を使用して SQL Managed Instance の TDE プロテクターをローテーションできます。 手順については、「Azure Key Vault の独自のキーを使用した SQL Managed Instance での Transparent Data Encryption」を参照してください。

はい。SQL Managed Instance に復元するために、データベースを復号化する必要はありません。 暗号化されたバックアップ ファイルからデータを読み取れるように、ソース システム上で暗号化キーの保護機能として使用される証明書またはキーを SQL Managed Instance に提供する必要があります。 その方法は次の 2 つです。

• SQL Managed Instance に証明書の保護機能をアップロードする。 これを実行できるのは、PowerShell を使用した場合のみです。 このサンプル スクリプトにプロセス全体が記述されています。
• 非対称キーの保護機能を Azure Key Vault にアップロードし、SQL Managed Instance がその保護機能を指すように指定する。 この方法は、暗号化キーの格納にも Key Vault 統合を使用する Bring Your Own Key (BYOK) TDE のユース ケースに似ています。 キーを暗号化キーの保護機能として使用せず、SQL Managed Instance によって暗号化されたデータベースが復元される際にキーを利用できるようにするだけの場合は、BYOK TDE の設定手順を実行し、 [選択したキーを既定の TDE 保護機能にします] チェック ボックスはオフにしてください。

暗号化保護機能を SQL Managed Instance で利用できるようにしたら、標準のデータベース復元手順を進めることができます。

SQL Managed Instance には、仮想コアベースの購入モデルが用意されています。

Azure SQL の特典を活用して、次の方法でコストを削減できます。

• オンプレミスのライセンスに対する既存の投資を最大化し、Azure ハイブリッド特典で最大 55% 節約できます。
• コンピューティング リソースの予約にコミットし、Azure Reservations 特典を して最大 33% 節約できます。 これと Azure ハイブリッド特典を組み合わせて、最大 82% の節約を実現できます。
• Azure Dev/Test の価格特典を利用して、進行中の開発とテストのワークロードを割引料金により、定価よりも最大 55% お得になります。

予約インスタンス特典の利用資格を得るには、お客様のサブスクリプションの種類がエンタープライズ契約 (プラン番号:MS-AZR-0017P または MS-AZR-0148P) または従量課金制料金の個々の契約 (プラン番号:MS-AZR-0003P または MS-AZR-0023P)。 予約の詳細については、「Azure Reservations」を参照してください。

一定の制限付きで、予約の取り消し、交換、または返金を行うことができます。 詳しくは、「Azure の予約のセルフサービスによる交換と払戻」を参照してください。

SQL Managed Instance の価格オプションの詳細については、「価格ページ」を参照してください。

これを行うには、Microsoft Cost Management ソリューションを使用します。 Azure portal で [サブスクリプション] に移動し、 [コスト分析] を選択します。

[累積コスト] オプションを使用し、その後 [リソースの種類] を microsoft.sql/managedinstances としてフィルター処理します。

SQL Managed Instance には、互換性のある Microsoft またはサード パーティ製のクライアント ツールを使用してアクセスできます。Azure 請求書に追加コストが発生することはありません。 ただし、一部のツールでライセンスが必要な場合は、合法的にライセンスが供与されたソフトウェアが必要です。 これは、各ツールの製造元との個別の契約によって管理されます。

設定されているバックアップの保有期間にかかわらず、購入した予約済みのデータ ストレージ スペースと同じ量のバックアップ ストレージが無料で確保されます。 バックアップ ストレージの使用量が、割り当てられている無料のバックアップ ストレージ スペース以内であれば、Azure SQL Managed Instance の自動バックアップには追加のコストはかかりません。そのため、無料で利用できます。 無料の容量を超えてバックアップ ストレージを使用すると、追加コストがかかります。 詳細については、価格ページのバックアップ ストレージのセクションを参照してください。 SQL Managed Instance の自動バックアップの技術的な詳細については、バックアップ ストレージの使用量に関するページの説明をご覧ください。

バックアップ ストレージのコストは、Azure portal を使用して監視できます。 手順については、自動バックアップのコストを監視する方法に関する記事を参照してください。

バックアップ ストレージのコストを最適化するには、SQL Managed Instance でのバックアップの微調整に関する記事を参照してください。

SQL Managed Instance のケース スタディ:

• Komatsu
• KMD
• PowerDETAILS
• Allscripts

Azure SQL Managed Instance のデプロイに関連する利点、コスト、リスクについて理解を深めるための、Forrester による調査結果をもあります: The Total Economic Impact of Microsoft Azure SQL Managed Instance databases。

SQL Managed Instance の SQL ログイン用のパスワード ポリシーは、マネージド インスタンスを保持する仮想クラスターを形成している VM に適用された Azure プラットフォーム ポリシーを継承します。 現時点では、これらの設定は Azure によって定義され、マネージド インスタンスによって継承されるため、変更することはできません。

各ログインでは、サインイン時にパスワードを設定し、有効期間の上限に達したらそのパスワードを変更する必要があります。

はい。CHECK_POLICY および CHECK_EXPIRATION フィールドをログイン レベルで制御できます。 現在の設定を確認するには、以下の T-SQL コマンドを実行します。

SELECT *
FROM sys.sql_logins

その後、以下を実行して、指定されているログイン設定を変更できます。

ALTER LOGIN <login_name> WITH CHECK_POLICY = OFF;
ALTER LOGIN <login_name> WITH CHECK_EXPIRATION = OFF;

("test" を目的のログイン名に置き換え、ポリシーと有効期限の値を調整してください。)

Azure SQL Database と SQL Managed Instance のための証明書ローテーションに関する記事を参照してください。

SQL Managed Instance での Azure メンテナンス イベントの計画に関するページを参照してください。

SQL Managed Instance フィードバック フォーラムで、新しい SQL Managed Instance 機能に投票したり新しい改善案を作成したりすることができます。 これにより、製品開発に貢献いただくことができ、これは今後の改善の優先順位を決める上で役立ちます。

Azure サポート リクエストを作成する方法については、Azure サポート リクエストを作成する方法に関する記事を参照してください。

2022 年 11 月の機能ウェーブで導入された変更と機能は、ほとんどのインスタンスに統合され、現在はデフォルトで使用できます。 インスタンスを登録するために別のアクションを実行する必要がなくなったため、2022 年 11 月の機能ウェーブに挙げられたオプションは Azure portal から削除されました。

機能ウェーブは、対象となるサブネット内のインスタンスで使用できます。 新しい機能が表示されない場合は、SQL Managed Instance を含むサブネットがまだ登録プロセス中のため、対象となっていない可能性があります。 ウェーブに登録されていないサブネット内のインスタンスには、引き続き Azure portal の [Feature Wave] ページが表示されます。

フェールオーバー グループ内のインスタンスの場合、Next-gen General Purpose レベルとの間でサービス レベルを変更することはサポートされていません。 最初にフェールオーバー グループを削除してからいずれかのレプリカを変更し、変更が有効となった後にフェールオーバー グループを再作成する必要があります。

ゾーン冗長は、Next-gen General Purpose サービス レベルでは現在サポートされていません。

いいえ。現在、Next-gen General Purpose サービス レベルのアップグレードは、インスタンス プールまたはプール内のインスタンスではサポートされていません。