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

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

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

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

すべてのお客様は、任意のサービス レベルを利用できます。 ソフトウェア アシュアランスの対象となる Standard エディションと Enterprise エディションの両方のライセンスを SQL Server データベース エンジンに割り当てるには、General Purpose サービス レベル (次世代 General Purpose サービス レベルのアップグレード、現在プレビュー段階を含む) または Business Critical サービス レベルの Azure ハイブリッド特典 (AHB) を使用します。 Azure ハイブリッド特典では、1 Standard エディション = 1 General Purpose、1 Enterprise Edition = 1 Business Critical、1 Enterprise Edition = 4 General Purpose、4 General Purpose = 1 Enterprise Edition の交換比率が使用されます。 詳細については、「 Azure ハイブリッド特典の特定の権限」を参照してください。

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

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

SQL Managed Instance には、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 への移行をご検討ください。

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

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

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

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

サブネット名を数字で始めるのは、正規表現に対してサブネット名を検証する基になるコンポーネントの現在の制限です。

^[a-zA-Z_][^\\\/\:\*\?\"\<\>\|\`\'\^]*(?<![\.\s])$

正規表現および有効なサブネット名を渡すすべての名前は、現在サポートされています。

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

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

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

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

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

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 マネージド インスタンス名の変更はサポートされていません。

はい。SQL Managed Instance の既定の DNS ゾーン .database.windows.net は、自分で変更できます。 ただし、ランダム化されたサブゾーン (例: .database.windows.netの前にsqlmiFQDN.randomized-subzone) を含む、その FQDN の SQL マネージド インスタンスのホスト名部分は同じままである必要があります。

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

• SQL Server クライアント ネットワーク ユーティリティ (CliConfg) を使用してエイリアスを定義します。 SQL マネージド インスタンスのホスト名、または SQL マネージド インスタンスのホスト名の後にカスタム ドメイン名のみを使用できます。 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 ビット プログラムの両方でエイリアスを解決できるようにしておく必要があります。
• SQL マネージド インスタンスの FQDN を指す SQL マネージド インスタンスのホスト名と共に、DNS の CNAME レコードを使用します。 この場合は、 Microsoft Entra ID (TrustServerCertificate=TRUE) による認証を使用する場合、 が必要になります。
• SQL マネージド インスタンスの IP アドレスを指す SQL マネージド インスタンスのホスト名と共に、DNS の A レコード を使用します。 IP アドレスを使用するのがお勧めできないのは、予告なく変更される場合があるからです。 この場合、Microsoft Entra 認証を使用するときは TrustServerCertificate=TRUE が必要です。

Azure SQL Managed Instance で提供されるコンピューティングおよびストレージ サイズあたりのパフォーマンス レベルは、Azure SQL Database の他のデプロイ オプションと同じです。 1 つのインスタンスにデータを統合する場合、または 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 Database Migration Guides を参照してください。

SQL マネージド インスタンスと SQL Server のパフォーマンス比較については、 Azure SQL Managed Instance と SQL Server のパフォーマンス比較のベスト プラクティスに関する記事を参照することをお勧めします。

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

SQL マネージド インスタンスのパフォーマンスは、次の方法で最適化できます。

• 自動チューニングでは、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 のアラートの作成に関する記事を参照してください。 ヒントとテクニックについては、ブログを参照してください。

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

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

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

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

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

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

SQL マネージド インスタンスで自動バックアップが実行されるタイミングを追跡するには、 バックアップ アクティビティの監視を確認します。

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

はい。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 マネージド インスタンスに接続し、さまざまな機能を使用するには、他の機能固有のルールを設定し、それらを維持する必要があります。

管理ポートでインバウンド NSG 規則を設定するには、どうすればよいですか?

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

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

はい。 SQL マネージド インスタンスがプロビジョニングされたら、ポート 1433 への受信アクセスを制御する NSG を設定できます。 可能な限り IP 範囲を狭くすることをお勧めします。

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

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

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

サブネットには、十分な数の使用可能な IP アドレスが必要です。 SQL Managed Instance の仮想ネットワーク サブネット サイズを確認するには、「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 の既存の仮想ネットワークを構成することができます。

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

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

現時点では、SQL マネージド インスタンスへの プライベート エンドポイント のみが静的 IP アドレスを保証します。

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

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

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

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

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

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

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

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

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

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

• すべてのデータベースで 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 名の解決に関する記事をご覧ください。

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

回避策としては、適切なタイム ゾーンを使用して新しい SQL マネージド インスタンスを作成し、手動バックアップと復元を実行するか、 インスタンス間のポイントインタイム リストアを実行することをお勧めします。

はい。お客様は 、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 にインポートする必要があります。 次に、データベースの完全バックアップを作成し、SQL マネージド インスタンスに復元します。

また、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 統合を使用して暗号化キーを格納する BYOK (Bring Your Own-Key) 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 請求書に追加コストが発生することはありません。 ただし、一部のツールでライセンスが必要な場合は、合法的にライセンスが供与されたソフトウェアが必要です。 この要件は、個々のツール製造元との個別の契約によって管理されます。

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

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

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

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

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

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

はい。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 メンテナンス イベントの計画に関するページを参照してください。

2022 年 11 月の機能ウェーブで導入された変更と機能は、既定ですべてのインスタンスで使用できるようになりました。 インスタンスを登録するために別のアクションを実行する必要がなくなったため、2022 年 11 月の機能ウェーブに言及するオプションは Azure portal から削除されました。

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

Azure サポート要求を作成する方法については、Azure サポート 要求を作成する方法に関するページを参照してください。

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

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

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