Azure SQL Managed Instanceに関する既知の問題

適用対象:Azure SQL Managed Instance

この記事では、Azure SQL Managed Instance に関する現在知られている問題とその解決日または考えられる回避策を示します。 Azure SQL Managed Instance についてさらに詳しく知りたい場合は、Azure SQL Managed Instance とはおよびAzure SQL Managed Instance の新機能を参照してください。

既知の問題

回避策あり

SQL Managed Instance に移行した後の復元操作の失敗

高速データベース復旧を有効にして SQL Server 2019 以降のバージョンから Azure SQL Managed Instance にデータベースを移行し、永続的バージョン ストア (PVS) を PRIMARY ファイル グループ以外に設定して構成した場合、ターゲット SQL マネージド インスタンスで復元操作エラーが発生する可能性があります。

この問題を回避するには、SQL Managed Instance に移行する前に、ソース SQL Server データベースの 永続バージョン ストア (PVS) を PRIMARY に設定してください。 PVS を PRIMARY に設定せずにデータベースを既に移行している場合は、ソース SQL Server データベースでデータベースを設定してから、データベースを SQL Managed Instance に再移行できます。

SQL Managed Instance に移行した後に高速データベース復旧を使用できない

SQL Server 2019 以降では、データベースを Azure SQL Managed Instance に移行し、ソース データベースの 高速データベース復旧 が無効になっている場合、ターゲット SQL マネージド インスタンスで高速データベース復旧を使用することはできません。

この問題を回避するには、SQL Managed Instance に移行する前に、ソース SQL Server データベースで 高速データベース復旧を有効に してください。 データベースの高速復旧を有効にせずに既にデータベースを移行している場合は、ソース SQL Server データベースでデータベースを有効にしてから、データベースを SQL マネージド インスタンスに再移行できます。

SQL Server 2017 以前のバージョンでは、高速データベース復旧はサポートされていないため、この問題は、これらのバージョンの SQL Server から移行されたデータベースには適用されません。

SQL Managed Instance に移行した後に Service Broker を使用できない

データベースを Azure SQL Managed Instance に移行し、 ソース データベースで Service Broker が無効になっている場合、ターゲット SQL マネージド インスタンスで Service Broker を使用することはできません。

この問題を回避するには、SQL Managed Instance に移行する前に、ソース SQL Server データベースで Service Broker を有効にしてください。 Service Broker を有効にせずにデータベースを既に移行している場合は、ソース SQL Server データベースでデータベースを有効にしてから、データベースを SQL Managed Instance に再移行できます。

無料プランのバックアップ保有期間の変更

無料の SQL マネージド インスタンス内のデータベースのバックアップ保持ポリシーは、REST API、PowerShell、および Azure CLI コマンドを使用してのみ変更できます。 Azure ポータルを使用してバックアップ保持ポリシーを変更することはできません。

"HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING" を長時間待機しているため、read-secondary へのログインに失敗しました

このエラーは、Microsoft OLE DB Driver 19 for SQL Server ドライバーの例外として、フェイルオーバー グループの読み取り専用セカンダリ レプリカに接続しようとする場合や、Managed Instance リンクを通じてレプリケートされたデータベースにおいて表示されることがあります。

このエラーは、セカンダリ レプリカが再起動またはリサイクルされたときに実行中のトランザクションに対して行バージョンが見つからないため、セカンダリ レプリカがログインに使用できない場合に発生します。これは、メンテナンスの場合でも、フェールオーバーが原因で発生した場合です。 インスタンスが再起動またはフェールオーバーされると、 tempdb に格納されているバージョン管理データがクリアされます。 フェールオーバーまたは再起動の前に開始された実行時間の長いアクティブ なトランザクションがある場合、セカンダリ読み取りクエリは中止されます。

この問題を解決するには、プライマリ レプリカでアクティブなトランザクションをロールバックまたはコミットします。 このエラーを回避するには、プライマリ レプリカで実行時間の長い書き込みトランザクションを最小限に抑えます。

SQL Managed Instanceから発生したSQL Server データベースで DBCC CHECKDB を実行する場合のエラー 8992

インデックスや、インデックスを含むテーブルを削除した後、Azure SQL Managed Instance から作成された、またはバックアップ ファイルの復元や SQL Managed Instance リンク機能を経由して作成された SQL Server 2022 データベースに対して DBCC CHECKDB コマンドを実行すると、次のエラーが表示される場合があります。

Msg 8992, Level 16, State 1, Line <Line_Number>
Check Catalog Msg 3853, State 1: Attribute (%ls) of row (%ls) in sys.sysrowsetrefs does not have a matching row (%ls) in sys.indexes.

この問題を回避するには、まず、Azure SQL Managed Instance上のソースデータベースからインデックスまたはインデックスを含むテーブルを削除します。その後、データベースを復元またはリンクさせて、再びSQL Server 2022に接続します。 ソース Azure SQL Managed Instanceからデータベースを再作成できない場合は、Microsoft サポートに問い合わせてこの問題を解決してください。

Azure ポータルの長期バックアップの一覧には、同じ名前のアクティブなデータベースと削除されたデータベースのバックアップ ファイルが表示されます

長期バックアップは、Backups タブのAzure SQL Managed Instance Azureポータル ページに表示および管理できます。このページには、アクティブまたは削除されたデータベース、長期的なバックアップに関する基本情報、バックアップを管理するためのリンクが一覧表示されます。 管理 リンクを選択すると、バックアップのリストが表示される新しい作業ウィンドウが開きます。 フィルター処理のロジックに問題があるため、一覧には、アクティブなデータベースと削除されたデータベースの両方のバックアップが同じ名前で一覧表示されます。 そのため、間違ったデータベースのバックアップを削除しないように、十分注意して削除するバックアップを選択してください。

回避策: 一覧に表示される バックアップ時刻 (UTC) 情報を使用して、異なる期間にインスタンスに存在していたのと同じ名前のデータベースに属するバックアップを区別します。 または、PowerShell コマンド Get-AzSqlInstanceDatabaseLongTermRetentionBackup と Remove-AzSqlInstanceDatabaseLongTermRetentionBackup を使用するか、または CLI コマンド az sql midb ltr-backup list と az sql midb ltr-backup delete を使用して、 DatabaseState パラメーターと DatabaseDeletionTime 戻り値を使用してデータベースのバックアップをフィルター処理します。

パラメーターを使用すると、プロシージャ sp_send_dbmail@query 失敗する場合があります

sp_send_dbmail パラメーターを使用すると、@query ストアド プロシージャが失敗する可能性があります。 sysadmin アカウントでストアド プロシージャが実行されると、エラーが発生します。

この問題は、 sp_send_dbmail が偽装を使用する方法に関連する既知のバグが原因で発生します。

回避策: sp_send_dbmail アカウントではなく、作成した適切なカスタム アカウントでを呼び出してください。

専用アカウントを作成し、 sp_send_dbmail経由で電子メールを送信する既存のオブジェクトを変更する方法の例を次に示します。

USE [msdb];
GO

-- Step 1: Create a user mapped to a login to specify as a runtime user.
CREATE USER [user_name] FOR LOGIN [login_name];
GO

EXECUTE msdb.dbo.sp_update_jobstep
    @job_name = N'db_mail_sending_job',
    @step_id = db_mail_sending_job_id,
    @database_user_name = N'user_name';
GO

-- Step 2: Grant DB Mail permissions to the user who created it.
ALTER ROLE [DatabaseMailUserRole] ADD MEMBER [user_name];
GO

-- Step 3: If the database of the job step is not msdb, the permission error cannot be avoided even if it is a member of the role, so set it to msdb.
EXECUTE msdb.dbo.sp_update_jobstep
    @job_name = N'db_mail_sending_job',
    @step_id = db_mail_sending_job_id,
    @database_name = N'msdb';
GO

-- Step 4: Set a principal in the email profile
EXECUTE msdb.dbo.sysmail_add_principalprofile_sp
    @principal_name = N'user_name',
    @profile_name = N'profile_name',
    @is_default = 0;
GO

分散トランザクションは、サーバー信頼グループから SQL マネージド インスタンスを削除した後に実行できます

サーバー信頼グループは、分散トランザクションを実行するための前提条件である、マネージド インスタンス間の信頼を確立するために使用されます。 サーバー信頼グループから SQL マネージド インスタンスを削除した後、またはグループを削除しても、分散トランザクションを実行できる場合があります。 分散トランザクションが無効になっていることを確認するには、SQL マネージド インスタンスで ユーザーが開始した手動フェールオーバー を実行します。

以前に削除した論理サーバーと同じ名前のSQL Managed Instanceを作成できません

Azure SQL Database または SQL Managed Instance の論理サーバーを Azure 内に作成すると、システムによって の DNS レコードが作成されます。 この DNS レコードは一意である必要があります。 SQL Database 用の論理サーバーを作成して削除した場合、名前は 7 日間予約されたままです。 この期間中は、削除された論理サーバーと同じ名前のSQL Managed Instanceを作成することはできません。 回避策として、SQL Managed Instanceに別の名前を使用するか、サポート チケットを作成して論理サーバー名を解放します。

サービス プリンシパルが Microsoft Entra ID および AKV にアクセスできない

状況によっては、Microsoft Entra ID (formerly Azure Active Directory) および Azure Key Vault (AKV) サービスにアクセスするために使用されるサービス プリンシパルに問題が存在します。 その結果、この問題は、SQL Managed InstanceでのMicrosoft Entra認証と透過的なデータ暗号化 (TDE) の使用に影響します。 断続的な接続の問題としてこの問題が発生する場合や、 CREATE LOGIN/USER FROM EXTERNAL PROVIDER や EXECUTE AS LOGIN/USERなどのステートメントを実行できない場合があります。 新しいAzure SQL Managed Instanceでカスタマー マネージド キーを使用して TDE を設定しても、状況によっては機能しない場合があります。

Workaround: SQL Managed Instanceでこの問題が発生しないようにするには、更新コマンドを実行する前に、または更新コマンドの後にこの問題が既に発生した場合は、Azure ポータルのSQL managed instanceの Overview ページに移動します。 Settings で、Microsoft Entra ID を選択して、SQL Managed Instance Microsoft Entra ID管理ページにアクセスします。 次のエラー メッセージを探します。

Managed Instance needs a Service Principal to access Microsoft Entra ID. Click here to create a Service Principal.

このエラー メッセージが表示された場合は、それを選択し、このエラーが解決されるまでの手順に従います。

空ではないファイルを削除しようとしたときに誤ったエラーが返される

SQL ServerとSQL Managed Instance 空でないファイルをユーザーが削除することはできません。 ALTER DATABASE REMOVE FILE ステートメントを使用して空でないデータ ファイルを削除しようとすると、次のエラーが発生します。

Msg 5042 - The file '<file_name>' cannot be removed because it is not empty` isn't immediately returned. SQL Managed Instance keeps trying to drop the file, and the operation fails after 30 minutes with `Internal server error.

サービス レベルの変更とインスタンスの作成操作が、進行中のデータベースの復元によってブロックされる

進行中の RESTORE ステートメント、Data Migration Service 移行プロセス、組み込みのポイントインタイム リストアでは、復元プロセスが完了するまで、サービス レベルの更新をブロックしたり、既存のインスタンスのサイズを変更したり、新しいインスタンスを作成したりできます。

復元プロセスでは、復元プロセスが実行されているのと同じサブネット内のマネージド インスタンスとインスタンス プールでこれらの操作がブロックされます。 インスタンス プール内のインスタンスは影響を受けません。 サービス レベルを作成または変更する操作が失敗したり、タイムアウトしたりすることはありません。復元プロセスが完了するかキャンセルされると、処理が続行されます。

回避策:サービス レベルの作成または更新操作の優先順位が高い場合は、復元プロセスが完了するか、復元プロセスがキャンセルされるまで待機します。

読み取り可能なセカンダリ レプリカのResource Governorは、フェールオーバー後に再構成する必要があります

ユーザー ワークロードに割り当てられているリソースを制限できる リソース ガバナー 機能では、フェールオーバー後の一部のユーザー ワークロードや、ユーザーが開始したサービス レベルの変更 (仮想コアの最大サイズや最大インスタンス ストレージ サイズの変更など) が誤って分類される可能性があります。

回避策: ALTER RESOURCE GOVERNOR RECONFIGURE 定期的に実行するか、 リソース ガバナーを使用している場合に読み取り可能なセカンダリ レプリカが開始されたときに SQL タスクを実行する SQL エージェント ジョブの一部として実行します。

小さなデータベース ファイルによる記憶域の超過

CREATE DATABASE、ALTER DATABASE ADD FILE、および RESTORE DATABASE ステートメントは失敗する可能性があります。これは、インスタンスが General Purpose サービス レベルのAzure Storage制限に達したが、Next-gen General Purpose サービス レベルのアップグレード または Business Critical サービス レベルに達していないためです。

SQL Managed Instanceの各 General Purpose インスタンスには、Azure Premium ディスク領域用に予約された最大 35 TB のストレージがあります。 各データベース ファイルは、個別の物理ディスクに配置されます。 ディスク サイズとして、128 GB、256 GB、512 GB、1 TB、4 TB のいずれかを指定できます。 ディスク上の未使用領域に対して課金されることはありませんが、Premium ディスク サイズAzure合計が 35 TB を超えることはできません。 場合によっては、合計で 8 TB を必要としない SQL マネージド インスタンスが、内部断片化のためにストレージ サイズの 35 TB Azure制限を超える可能性があります。

たとえば、SQL Managed Instanceの General Purpose インスタンスには、サイズが 1.2 TB の大きなファイルが 4 TB のディスクに配置されている場合があります。 また、個別の 128 GB のディスクに配置される、それぞれ 1 GB のファイルが 248 個あるとします。 例としては、

• 割り当てられるディスク ストレージの合計サイズは、1 x 4 TB + 248 x 128 GB = 35 TB となります。
• インスタンス上のデータベースの予約済み領域の合計は、1 x 1.2 TB + 248 x 1 GB = 1.4 TB となります。

この例は、特定の状況では、特定のファイルの配布により、SQL Managed Instanceのインスタンスが、予期しない場合に、接続された Azure Premium Disk 用に予約されている 35 TB の制限に達する可能性があることを示しています。

この例では既存のデータベースは引き続き機能し、新しいファイルを追加しない限りは問題なく拡張できます。 すべてのデータベースの合計サイズがインスタンス サイズの制限に達していない場合でも、新しいディスク ドライブに十分な領域がないため、新しいデータベースを作成または復元できません。 返されるエラーは明確ではありません。

システム ビューを使用して、残りのファイルの数を特定できます。 この制限に達した場合は、DBCC SHRINKFILE ステートメントを使用して、より小さなファイルをいくつか空にして削除してみるか、この制限のない Business Critical レベルに切り替えてください。

データベース名の代わりに GUID 値が表示される

複数のシステム ビュー、パフォーマンス カウンター、エラー メッセージ、XEvent、およびエラー ログ エントリで、実際のデータベース名ではなく GUID データベース識別子が表示されています。 これらの GUID 識別子は、将来、実際のデータベース名に置き換えられる可能性があるため、それには依存しないでください。

回避策: sys.databases ビューを使用して、GUID データベース識別子の形式で示されている物理データベース名から実際のデータベース名を解決します。

SELECT name AS ActualDatabaseName,
       physical_database_name AS GUIDDatabaseIdentifier
FROM sys.databases
WHERE database_id > 4;

CLR モジュールとリンク サーバーでローカル IP アドレスを参照できないことがある

SQL Managed Instanceおよびリンク サーバー内の CLR モジュール、または現在のインスタンスを参照する分散クエリでは、ローカル インスタンスの IP を解決できない場合があります。 このエラーは一時的な問題です。

解決策なし

無効な資格情報を使用して読み取りレプリカに接続するときの誤解を招くエラー メッセージ

ApplicationIntent=ReadOnlyと無効な資格情報を使用して Business Critical 層インスタンスの読み取りセカンダリ レプリカに接続しようとすると、master データベースが読み取り専用であることを示すエラーがインスタンスから報告されます。 インスタンスが資格情報が無効であることを正しく報告しません。

インスタンスがSQL Serverにリンクされている場合、差分バックアップは作成されません

SQL ServerとAzure SQL Managed Instanceの間で link を構成すると、SQL マネージド インスタンスがプライマリ ロールにあるかどうかにかかわらず、自動完全バックアップとトランザクション ログ バックアップが実行されます。 ただし、差分バックアップが現在実行されないため、復元時間が長くなる可能性があります。

トランザクション レプリケーションに使用されるシステム ログイン数の増加

Azure SQL Managed Instanceサービスは、トランザクション レプリケーションのためにシステム ログインを作成します。 このログインは、SSMS (Object Explorer>Security>Logins) または sys.syslogins システム ビューにあります。 ログイン名の形式は DBxCy\WF-abcde01234QWERTのように見え、ログインには パブリック サーバーロールがあります。 特定の条件下では、このログインは再作成され、内部的な問題のため、以前のログインは削除されません。 このエラーにより、ログインの数が増加する可能性があります。 これらのログインはセキュリティ上の脅威を表すものではないため、無視しても問題ありません。 トランザクション レプリケーションに少なくとも 1 つが使用されているため、これらのログインは削除しないでください。

Microsoft Entra ログインとユーザーは SSDT ではサポートされていません

SQL Server Data Toolsでは、Microsoft Entraのログインとユーザーを完全にはサポートされていません。

Microsoft Entra ログインの種類の偽装はサポートされていません

EXECUTE AS USER または EXECUTE AS LOGIN を使用した偽装は、次のMicrosoft Entra プリンシパルではサポートされていません。

• エイリアス化されたMicrosoft Entraユーザー。 この場合、操作はエラー 15517を返します。
• Microsoft Entra アプリケーションまたはサービス プリンシパルに基づいたMicrosoft Entraのログインとユーザー。 この場合、操作はエラー 15517 と 15406を返します。

geo フェールオーバーの後で、トランザクション レプリケーションを再構成する必要がある

フェールオーバー グループ内のデータベースでトランザクション レプリケーションを有効にする場合、SQL Managed Instance管理者は、別のリージョンへのフェールオーバーが発生した後、古いプライマリのすべてのパブリケーションをクリーンアップし、新しいプライマリでパブリケーションを再構成する必要があります。 詳細については、「レプリケーション」をご覧ください。

エラー ログが非永続的である

SQL Managed Instanceで使用できるエラー ログは保持されず、そのサイズは最大ストレージ制限に含まれません。 フェールオーバーが発生した場合、エラー ログは自動的に消去される可能性があります。 複数の仮想マシンでSQL Managed Instanceが複数回移動されたため、エラー ログ履歴にギャップが存在する可能性があります。

解決済み

パラグアイの2024年タイムゾーン更新に関する中間ガイダンス

(2026 年 2 月に解決済み)

2024年10月14日、パラグアイ政府はタイムゾーン政策の永続的な変更を発表した。 現在、パラグアイは夏時間 (DST) を通年で残り、UTC-3 を標準時として効果的に採用しています。 その結果、2025 年 3 月 23 日午前 12:00 に、以前の予定どおり、クロックは 60 分進んでいませんでした。 この変更は、パラグアイ標準タイム ゾーンに影響します。 Microsoft は、関連する Windows 更新プログラムを 2025 年 2 月と 3 月にリリースしました。 影響を受けるタイム ゾーンを使用する SQL マネージド インスタンスは、この変更を反映し、新しい UTC-3 オフセットに合わせて調整します。

接続の種類の変更が、フェールオーバー グループ エンドポイント経由の接続に影響しない

(2025 年 11 月に解決済み)

インスタンスがフェールオーバー グループに参加している場合に、インスタンスの接続の種類を変更しても、フェールオーバー グループ リスナー エンドポイントを介して確立された接続では有効になりません。

スケーリング操作中に、フェールオーバーグループリスナーを使用して一時的なインスタンスにアクセスできない

(2025 年 4 月に解決済み)

SQL マネージド インスタンスをスケーリングするには、関連付けられているサービスによって管理される DNS レコードと共に、インスタンスを別の仮想クラスターに移動することが必要になる場合があります。 SQL マネージド インスタンスがフェールオーバー グループに参加している場合、関連付けられているフェールオーバー グループ リスナー (インスタンスが現在の geo プライマリ読み取り専用リスナーの場合は読み取り/書き込みリスナー) に対応する DNS レコードが、新しい仮想クラスターに移動されます。

現在のスケーリング操作の設計では、SQL マネージド インスタンスを新しい仮想クラスターに完全に移行する前に、リスナーの DNS レコードが元の仮想クラスターから削除されます。 場合によっては、この設計により、インスタンスの IP アドレスをリスナーを使用して解決できない時間が長くなる場合があります。 この間、リスナー エンドポイントを使用してスケーリングされるインスタンスにアクセスしようとしている SQL クライアントは、次のエラー メッセージを含むログイン エラーを予期できます。

Error 40532: Cannot open server "xxx.xxx.xxx.xxx" requested by the login. The login failed. (Microsoft SQL Server, Error: 40532).

この問題は、スケーリング操作の再設計を行うと解決できます。

msdbの手動バックアップ用テーブルでユーザー名は保持されません

(2023 年 8 月に解決済み) 最近導入された msdb での自動バックアップのサポートには、現在、ユーザー名情報は含まれません。

SQL Server認証を使用する場合、'@' を持つユーザー名はサポートされません

中央に @ 記号を含むユーザー名 (たとえば、abc@xy) は、SQL Server認証を使用してサインインできません。

CHECKSUM を使用せずに手動バックアップを復元すると失敗することがある

(2020 年 6 月に解決済み) 状況によっては、 CHECKSUM なしで SQL マネージド インスタンスで作成したデータベースの手動バックアップを復元できない場合があります。 このような場合は、成功するまでバックアップの復元を再試行してください。

回避策: CHECKSUM が有効になっている SQL マネージド インスタンス上のデータベースの手動バックアップを作成します。

SQL Managed Instanceに適用されていないリソース グループに対するアクセス許可

SQL Managed Instance共同作成者Azure ロールをリソース グループ (RG) に適用しても、SQL Managed Instanceには適用されないため、影響はありません。

Workaround: サブスクリプション レベルでユーザーのSQL Managed Instance共同作成者ロールを設定します。

Azure ポータルにおけるサービス プリンシパルの再作成を勧める誤解を招くエラーメッセージ

Azure SQL Managed Instance用ポータルの Active Directory admin Azure ページには、サービス プリンシパルが既に存在していても、次のエラー メッセージが表示される場合があります。

Managed Instance needs a Service Principal to access Microsoft Entra ID. Click here to create a Service Principal.

SQL マネージド インスタンスのサービス プリンシパルが既に存在する場合や、Microsoft Entra 認証が SQL マネージド インスタンスで機能している場合は、このエラー メッセージを無視できます。

サービス プリンシパルが存在するかどうかを確認するには、Azure ポータルの Enterprise applications ページに移動します。 アプリケーションの種類ドロップダウン リストから > を選択し、 Apply を選択し、検索ボックスに SQL マネージド インスタンスの名前を入力します。 インスタンス名が結果の一覧に表示された場合、サービス プリンシパルは既に存在しており、それ以上の操作は必要ありません。

エラー メッセージの指示に既に従い、リンクを選択した場合は、SQL マネージド インスタンスのサービス プリンシパルが再作成されます。 その場合、Microsoft Entra認証が正しく機能するように、新しく作成されたサービス プリンシパルにMicrosoft Entra IDの読み取り権限を割り当てます。 この手順は、instructions に従ってAzure PowerShellで実行することもできます。

system_health イベント セッションのevent_file ターゲットにアクセスできない

(2025 年 5 月に部分的に解決)event_file イベント セッションのsystem_healthターゲットの内容を読み取ろうとすると、エラー 40538"https://で始まる有効な URL が、指定された任意のファイルパスの値として必要です。

もともと、この問題は SQL Server Management Studio (SSMS) で発生したか、sys.fn_xe_file_target_read_file 関数を使用してセッション データを読み取るときに発生しました。

2025 年 5 月に、SSMS からセッション データを読み取る際にこの問題が解決されました。 sys.fn_xe_file_target_read_file関数を使用してイベント データを読み取る場合、この問題は解決されません。

この動作の変更は、必要なセキュリティ修正の意図しない結果です。 この問題を回避するには、Azure Blob Storageで system_health ターゲットを使用して、独自の同等の event_file セッションを作成します。 system_health に相当する独自のセッションを作成するために変更できる system_health セッションを作成する T-SQL スクリプトなどの詳細については、「system_health セッションの使用」を参照してください。

サービス レベルのアップグレード後にデータベース間の Service Broker ダイアログを再初期化する必要がある

(2020 年 1 月に解決済み) サービス レベルの変更操作後に、データベース間の Service Broker ダイアログが他のデータベースのサービスにメッセージを配信しなくなります。 メッセージは "失われたわけではなく"、送信元のキューで見つかります。 SQL Managed Instanceで仮想コアまたはインスタンスのストレージ サイズを変更すると、service_broke_guid ビューの 値がすべてのデータベースに対して変更されます。 他のデータベースの Service Broker を参照する DIALOG ステートメントを使用して作成されたは、ターゲット サービスへのメッセージの配信を停止します。

回避策:複数データベースにまたがる Service Broker ダイアログのメッセージ交換を使用するアクティビティはすべて、サービス レベルを更新する前に停止し、後で再初期化してください。 サービス レベルの変更後も未配信のメッセージが残っている場合は、ソース キューからメッセージを読み取り、ターゲット キューに再送信します。

コンテンツの改善への協力

Azure SQLドキュメントに投稿するには、Docs 共同作成者ガイドを参照してください。

関連するコンテンツ

• SQL Managed Instance更新プログラムと機能強化の一覧については、「SQL Managed Instance サービスの更新プログラムを参照してください。

• すべてのAzure サービスの更新と機能強化については、「Service 更新プログラム」を参照してください。