Azure SQL Managed Instance に関する既知の問題
適用対象: 
Azure SQL Managed Instance
この記事では、Azure SQL Managed Instance に関する現在の既知の問題と、解決日または考えられる回避策の一覧を示します。 Azure SQL Managed Instance の詳細については、「Azure SQL Managed Instance とは？」と「Azure SQL Managed Instance の新機能は？」を参照してください。
Note
Microsoft Entra ID の、旧称は Azure Active Directory（Azure AD）です。
既知の問題
回避策あり
Azure portal の長期バックアップの一覧には、同じ名前のアクティブなデータベースと削除されたデータベースのバックアップ ファイルが表示されます
[バックアップ] タブの Azure SQL Managed Instance の Azure portal ページで、長期的なバックアップを一覧表示および管理できます。このページには、アクティブまたは削除されたデータベース、長期的なバックアップに関する基本情報、バックアップを管理するためのリンクが一覧表示されます。 管理 リンクを選択すると、バックアップのリストが表示される新しい作業ウィンドウが開きます。 フィルター処理のロジックに問題があるため、一覧には、アクティブなデータベースと削除されたデータベースの両方のバックアップが同じ名前で一覧表示されます。 そのため、間違ったデータベースのバックアップを削除しないように、十分注意して削除するバックアップを選択してください。
回避策: 一覧に表示される バックアップ時刻 (UTC) 情報を使用して、異なる期間にインスタンスに存在していたのと同じ名前のデータベースに属するバックアップを区別します。 または、PowerShell コマンド Get-AzSqlInstanceDatabaseLongTermRetentionBackup と Remove-AzSqlInstanceDatabaseLongTermRetentionBackup を使用するか、CLI コマンド az sql midb ltr-backup list と az sql midb ltr-backup delete を使用して、パラメーターの DatabaseState と DatabaseDeletionTime の戻り値を使用してデータベースのバックアップをフィルター処理します。
system_health イベント セッションのevent_file ターゲットにアクセスできない
event_file イベント セッションの system_health ターゲットの内容を読み取ろうとすると、エラー 40538、「指定されたファイルパスの値として、「https://」 で始まる有効な URL が必要です。」が発生します。これは、SQL Server Management Studio で発生するか、sys.fn_xe_file_target_read_file 関数を使用してセッション データを読み取るときに発生します。
この動作の変更は、最近必要なセキュリティ修正が意図しない結果になります。 お客様がAzure SQL Managed Instanceで system_health セッションを安全に使用し続けることを可能にする追加の変更の実現可能性を調査しています。 それまでの間、お客様は、Azure Blob Storage で system_health ターゲットを使用して event_file セッションと同等の独自のセッションを作成することで、この問題を回避できます。 system_health に相当する独自のセッションを作成するために変更できる system_health セッションを作成する T-SQL スクリプトなどの詳細については、「system_health セッションの使用」を参照してください。
@query パラメーターの場合、プロシージャ sp_send_dbmail が失敗する可能性がある
@query パラメーターを使った場合、プロシージャ sp_send_dbmail が失敗する可能性があります。 sysadmin アカウントでストアド プロシージャが実行されると、エラーが発生します。
この問題は、sp_send_dbmail偽装の使い方に関連した既知のバグが原因です。
回避策: sysadmin アカウントではなく、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
EXEC 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.
EXEC 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
EXEC msdb.dbo.sysmail_add_principalprofile_sp @principal_name=N'user_name', @profile_name=N'profile_name', @is_default=0
GO
チリの 2022 年のタイム ゾーン更新に関する中間ガイダンス
2022 年 8 月 8 日、チリ政府は、夏時間 (DST) のタイム ゾーンの変更について公式に発表しました。 2022 年 9 月 10 日 (土) 午前 12:00 から 2023 年 4 月 1 日 (土) 午前 12:00 まで、公式時間を 60 分進めます。 この変更は 太平洋 SA 標準時間、イースター島標準時間、マガヤネス標準時間という 3 つのタイム ゾーンに影響を与えます。 これをサポートするための OS の更新プログラムが Microsoft によってリリースされ、Azure SQL Managed Instance サービスが OS レベルでその更新プログラムを取り込むまで、影響を受けるタイム ゾーンを使っている Azure SQL Managed Instances にはこの変更が反映されません。
回避策: マネージド インスタンスで影響を受けるタイム ゾーンを変更する必要がある場合は、制限に注意し、ドキュメントのガイダンスに従ってください。
フェールオーバー グループ エンドポイント経由の接続に影響しない接続の種類に変更します
インスタンスがフェールオーバー グループに参加している場合に、インスタンスの接続の種類を変更しても、フェールオーバー グループ リスナー エンドポイントを介して確立された接続では有効になりません。
回避策: 接続の種類を変更した後に、フェールオーバー グループを切断し、再作成します。
@query パラメーターの使用時、プロシージャ sp_send_dbmail が一時的に失敗する可能性がある
@query パラメーターの使用時、プロシージャが sp_send_dbmail 一時的に失敗する可能性があります。 この問題が発生した場合は、プロシージャ sp_send_dbmail の実行が 2 回に 1 回、エラー Msg 22050, Level 16, State 1 とメッセージ Failed to initialize sqlcmd library with error number -2147467259 で失敗します。 このエラーを正しく認識できるようにするには、パラメーター @exclude_query_output を既定値 0 にしてこのプロシージャを呼び出す必要があります。そうしないと、このエラーは伝達されません。
この問題は、sp_send_dbmail での権限借用と接続プールの使用方法に関連した既知のバグが原因で発生します。
この問題を回避するには、電子メールを送信するためのコードを、出力パラメーター @mailitem_id に依存する再試行ロジックにラップします。 実行が失敗した場合は、このパラメーターの値は NULL になり、メールを正常に送信するには sp_send_dbmail をもう 1 回呼び出す必要があることを示します。 この再試行ロジックの例を次に示します。
CREATE PROCEDURE send_dbmail_with_retry AS
BEGIN
DECLARE @miid INT
EXEC msdb.dbo.sp_send_dbmail
@recipients = 'name@mail.com', @subject = 'Subject', @query = 'select * from dbo.test_table',
@profile_name ='AzureManagedInstance_dbmail_profile', @execute_query_database = 'testdb',
@mailitem_id = @miid OUTPUT
-- If sp_send_dbmail returned NULL @mailidem_id then retry sending email.
--
IF (@miid is NULL)
EXEC msdb.dbo.sp_send_dbmail
@recipients = 'name@mail.com', @subject = 'Subject', @query = 'select * from dbo.test_table',
@profile_name ='AzureManagedInstance_dbmail_profile', @execute_query_database = 'testdb',
END
サーバー信頼グループからマネージド インスタンスを削除した後、分散トランザクションを実行できる
サーバー信頼グループは、分散トランザクションを実行するための前提条件である、マネージド インスタンス間の信頼を確立するために使用されます。 サーバー信頼グループからマネージド インスタンスを削除した後、またはグループを削除した後も、分散トランザクションを実行できる場合があります。 分散トランザクションを確実に無効にする回避策は、マネージド インスタンスでユーザーが手動でフェールオーバーを開始することです。
マネージド インスタンスのスケーリング操作の後、分散トランザクションを実行できない
サービス レベルや仮想コア数の変更を含む SQL Managed Instance のスケーリング操作を実行すると、バックエンドでサーバー信頼グループの設定がリセットされ、分散トランザクションの実行が無効になります。 回避するには、Azure portal でサーバー信頼グループを削除して、新しく作成します。
以前に削除された論理サーバーと同じ名前の SQL Managed Instance を作成できない
<name>.database.windows.com の DNS レコードは、Azure SQL Database 用の論理サーバーを Azure に作成したときと、SQL マネージド インスタンスを作成したときに作成されます。 DNS レコードは、一意である必要があります。 そのため、SQL Database 用の論理サーバーを作成してから削除した場合、レコードから名前が解放されるまでに 7 日間のしきい値期間があります。 その期間、削除された論理サーバーと同じ名前を持つ SQL マネージド インスタンスを作成することはできません。 回避策としては、SQL マネージド インスタンスに別の名前を使用するか、サポート チケットを作成して論理サーバー名を解放する必要があります。
サービス プリンシパルが Microsoft Entra ID と AKV にアクセスできない
場合によっては、Microsoft Entra ID (旧称 Azure Active Directory) および Azure Key Vault (AKV) サービスへのアクセスに使用されるサービス プリンシパルに問題が存在することがあります。 そのため、この問題は SQL Managed Instance での Microsoft Entra 認証および Transparent Data Encryption (TDE) の使用に影響します。 これは、断続的な接続の問題、または CREATE LOGIN/USER FROM EXTERNAL PROVIDER や EXECUTE AS LOGIN/USER などのステートメントを実行できない場合に発生する可能性があります。 新しい Azure SQL Managed Instance 上でカスタマー マネージド キーを使用して TDE を設定しても、状況によっては機能しないことがあります。
回避策: 更新コマンドを実行する前に SQL Managed Instance 上でこの問題が発生しないようにするには、または更新コマンドの後でこの問題が既に発生している場合は、Azure portal の SQL Managed Instance の [概要ページ] にアクセスします。 [設定] で、[Microsoft Entra ID] を選択して、SQL Managed Instance の Microsoft Entra ID 管理ページにアクセスします。 "Microsoft Entra ID にアクセスするには、Managed Instance にサービス プリンシパルが必要です。 サービス プリンシパルを作成するには、ここをクリックします" というエラー メッセージが表示されるかどうかを確認します。 このエラー メッセージが表示された場合は、それを選び、このエラーが解決されるまで、示されるステップバイステップの手順に従います。
ポータルを使用したフェールオーバー グループに対する手動フェールオーバーの制限
フェールオーバー グループが、異なる Azure サブスクリプションやリソース グループのインスタンスにまたがっている場合、フェールオーバー グループのプライマリ インスタンスから手動フェールオーバーを開始することはできません。
回避策:Geo セカンダリ インスタンスからポータル経由でフェールオーバーを開始します。
SQL エージェント ロールには、sysadmin 以外のログインに対する明示的な EXECUTE 権限が必要です
sysadmin 以外のログインが SQL Agent の固定データベース ロールに追加される場合、これらのログインを機能させるには、明示的な EXECUTE 権限を master データベースの 3 つのストアド プロシージャに付与する必要があるという問題が存在します。 この問題が発生した場合は、エラー メッセージ The EXECUTE permission was denied on the object <object_name> (Microsoft SQL Server, Error: 229) が表示されます。
回避策: SQL Agent 固定データベース ロール (SQLAgentUserRole、SQLAgentReaderRole、または SQLAgentOperatorRole) にログインを追加した後、これらのロールに追加された各ログインごとに、次の T-SQL スクリプトを実行して、一覧で示されているストアド プロシージャに明示的に EXECUTE アクセス許可を付与します。
USE [master];
GO
CREATE USER [login_name] FOR LOGIN [login_name];
GO
GRANT EXECUTE ON master.dbo.xp_sqlagent_enum_jobs TO [login_name];
GRANT EXECUTE ON master.dbo.xp_sqlagent_is_starting TO [login_name];
GRANT EXECUTE ON master.dbo.xp_sqlagent_notify TO [login_name];
インメモリ OLTP のメモリ制限が適用されない
Business Critical サービス レベルでは、メモリ最適化オブジェクトの最大メモリ制限が正しく適用されない場合があります。 SQL Managed Instance では、ワークロードが、インメモリ OLTP 操作に対してより多くのメモリを使用できる場合があり、これがインスタンスの可用性と安定性に影響を及ぼすことがあります。 インメモリ OLTP クエリは、制限に達しても、すぐには失敗しない可能性があります。 さらに多くのインメモリ OLTP メモリを使用するクエリは、制限に達するとすぐに失敗するようになります。
回避策: SQL Server Management Studio を使ってインメモリ OLTP ストレージの使用状況を監視し、使用可能な量を超えるメモリがワークロードによって使われないようにします。 仮想コアの数に応じてメモリ制限を増やすか、ワークロードを最適化して、使用するメモリを減らします。
空ではないファイルを削除しようとしたときに誤ったエラーが返される
SQL Server と SQL Managed Instance では、ユーザーは空でないファイルを削除できません。 ALTER DATABASE REMOVE FILE ステートメントを使って空でないデータ ファイルを削除しようとした場合、エラー Msg 5042 – The file '<file_name>' cannot be removed because it is not empty はすぐには返されません。 SQL Managed Instance では引き続きファイルの削除が試行されますが、操作は 30 分後に Internal server error で失敗します。
サービス レベルの変更とインスタンスの作成操作が、進行中のデータベースの復元によってブロックされる
進行中の RESTORE ステートメント、データ移行サービスの移行プロセス、組み込みのポイントインタイム リストアでは、復元プロセスが完了するまで、サービス レベルの更新や既存のインスタンスのサイズ変更、新しいインスタンスの作成がブロックされます。
復元プロセスでは、復元プロセスが実行されているのと同じサブネット内のマネージド インスタンスとインスタンス プールでこれらの操作がブロックされます。 インスタンス プール内のインスタンスは影響を受けません。 サービス レベルを作成または変更する操作が失敗したり、タイムアウトしたりすることはありません。復元プロセスが完了するかキャンセルされると、処理が続行されます。
回避策:サービス レベルの作成または更新操作の優先順位が高い場合は、復元プロセスが完了するか、復元プロセスがキャンセルされるまで待機します。
Business Critical サービス レベルの Resource Governor をフェールオーバー後に再構成しなければならない場合がある
ユーザー ワークロードに割り当てられるリソースを制限することを可能にする Resource Governor 機能では、フェールオーバー後、またはユーザーが開始したサービス レベルの変更 (たとえば、最大仮想コア数やインスタンスの最大ストレージ サイズの変更) 後に、一部のユーザー ワークロードが誤って分類されることがあります。
回避策:Resource Governor を使用している場合、ALTER RESOURCE GOVERNOR RECONFIGURE を定期的に、または、インスタンスの開始時に SQL タスクを実行する SQL Agent ジョブの一環として実行します。
サービス レベルのアップグレード後は、複数データベースにまたがる Service Broker のダイアログを再初期化する必要がある
サービス レベルの変更操作の後、複数データベースにまたがる Service Broker のダイアログで、他のデータベースのサービスにメッセージが配信されなくなります。 メッセージは "失われたわけではなく"、送信元のキューで見つかります。 SQL Managed Instance の仮想コア数やインスタンスのストレージ サイズを変更すると、すべてのデータベースについて、sys.databases ビューの service_broke_guid 値が変更されます。 BEGIN DIALOG ステートメントを使用して作成された、他のデータベースの Service Broker を参照する DIALOG は、ターゲット サービスにメッセージを配信しなくなります。
回避策:複数データベースにまたがる Service Broker ダイアログのメッセージ交換を使用するアクティビティはすべて、サービス レベルを更新する前に停止し、後で再初期化してください。 サービス レベルの変更後、未配信のままのメッセージがあった場合は、それらのメッセージをソース キューから読み取って、ターゲット キューに再送信します。
小さなデータベース ファイルによる記憶域の超過
インスタンスが Azure ストレージの制限に達する可能性があるため、CREATE DATABASE、ALTER DATABASE ADD FILE、および RESTORE DATABASE ステートメントが失敗することがあります。
SQL Managed Instance の各 General Purpose インスタンスには、Azure Premium ディスク領域用に予約された最大 35 TB のストレージがあります。 各データベース ファイルは、個別の物理ディスクに配置されます。 ディスク サイズとして、128 GB、256 GB、512 GB、1 TB、4 TB のいずれかを指定できます。 ディスク上の未使用領域については請求されませんが、Azure Premium ディスクのサイズ合計が 35 TB を超えることはできません。 場合によっては、内部の断片化のために、合計で 8 TB を必要としない Managed Instance が、記憶域のサイズに関する 35 TB の Azure での制限を超える場合があります。
たとえば、SQL Managed Instance の General Purpose インスタンスに、4 TB のディスクに配置されているサイズが 1.2 TB の大きなファイルが 1 つあるとします。 また、個別の 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 ディスク用に予約されている 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 を解決できないことがあります。 このエラーは一時的な問題です。
同じインスタンス内にある 2 つのデータベース上でトランザクション スコープがサポートされない
(2020 年 3 月に解決済み)TransactionScope クラス (.NET) は、同じトランザクション スコープ下では、同一インスタンス内にある 2 つのデータベースに対して 2 つのクエリが送信された場合に機能しません。
using (var scope = new TransactionScope())
{
using (var conn1 = new SqlConnection("Server=quickstartbmi.neu15011648751ff.database.windows.net;Database=b;User ID=myuser;Password=<password>;Encrypt=true"))
{
conn1.Open();
SqlCommand cmd1 = conn1.CreateCommand();
cmd1.CommandText = string.Format("insert into T1 values(1)");
cmd1.ExecuteNonQuery();
}
using (var conn2 = new SqlConnection("Server=quickstartbmi.neu15011648751ff.database.windows.net;Database=b;User ID=myuser;Password=<password>;Encrypt=true"))
{
conn2.Open();
var cmd2 = conn2.CreateCommand();
cmd2.CommandText = string.Format("insert into b.dbo.T2 values(2)"); cmd2.ExecuteNonQuery();
}
scope.Complete();
}
回避策 (2020 年 3 月以降は不要) :2 つの接続を使用する代わりに SqlConnection.ChangeDatabase(String) を使って、接続コンテキスト内で他のデータベースを使用します。
解決策なし
インスタンスが SQL Server にリンクされている場合、差分バックアップは作成されません
SQL Server と Azure SQL Managed Instance の間でリンクを構成すると、Managed Instance がプライマリ ロールにあるかどうかにかかわらず、Managed Instance 上で自動完全バックアップとトランザクション ログ バックアップが実行されます。 ただし、差分バックアップが現在実行されないため、復元時間が長くなる可能性があります。
トランザクション レプリケーションに使用されるシステム ログイン数の増加
Azure SQL Managed Instance サービスでは、トランザクション レプリケーションのためにシステム ログインが作成されます。 このログインは、SSMS (オブジェクト エクスプローラーの [セキュリティ] の [ログイン] セクション) またはシステム ビューsys.syslogins で確認できます。 ログイン名は 'DBxCy\WF-abcde01234QWERT' のような形式であり、ログインはパブリック サーバー ロールを持っています。 このログインは特定の条件下で再作成され、システム内の障害が原因で以前のログインは削除されません。 これにより、ログインの数が増える可能性があります。 これらのログインは、セキュリティ上の脅威を表すわけではありません。 これらは、無視しても問題ありません。 これらのログインは、少なくとも 1 つはトランザクション レプリケーションに使われているため、削除しないでください。
MICROSOFT Entra ログインとユーザーが SSDT でサポートされていない
SQL Server Data Tools では、Microsoft Entra のログインとユーザーが完全にはサポートされません。
Microsoft Entra のログインの種類の偽装がサポートされていない
次の Microsoft Entra プリンシパルの EXECUTE AS USER または EXECUTE AS LOGIN を使用した偽装はサポートされていません。
- エイリアス化された Microsoft Entra ユーザー。 この場合は
15517エラーが返されます。 - Microsoft Entra アプリケーションまたはサービス プリンシパルに基づく Microsoft Entra ログインとユーザー。 この場合は
15517および15406エラーが返されます。
geo フェールオーバーの後で、トランザクション レプリケーションを再構成する必要がある
フェールオーバー グループのデータベースでトランザクション レプリケーションが有効な場合、SQL Managed Instance 管理者は、別のリージョンへのフェールオーバーが発生した後で、古いプライマリ上のすべてのパブリケーションをクリーンアップしてから、新しいプライマリ上でそれらを再構成する必要があります。 詳細については、「レプリケーション」をご覧ください。
tempdb の構造と内容が再作成される
tempdb データベースは常に 12 個のデータ ファイルに分割され、ファイルの構造は変更できません。 ファイルあたりの最大サイズは変更できず、tempdb に新しいファイルを追加することはできません。 tempdb データベースは、インスタンスが開始またはフェールオーバーしたときに、常に空のデータベースとして再作成され、tempdb で行われたどの変更も保持されません。
エラー ログが非永続的である
SQL Managed Instance で利用可能なエラー ログは永続的ではなく、このログのサイズは、最大ストレージ上限には含まれません。 フェールオーバーが発生した場合、エラー ログは自動的に消去される可能性があります。 SQL Managed Instance が複数の仮想マシンで複数回移動されたことが原因で、エラー ログの履歴に欠落部分が生じる可能性があります。
スケーリング操作中に、フェールオーバーグループリスナーを使用して一時的なインスタンスにアクセスできない
マネージドインスタンスのスケーリングでは、インスタンスを、関連するサービスによって管理される DNS レコードと共に別の仮想クラスターへ移動することが必要になる場合があります。 マネージドインスタンスがフェールオーバーグループに参加している場合、関連付けられているフェールオーバーグループ リスナー (インスタンスが現在の geo プライマリの場合は読み取り/書き込みリスナー。つまり、インスタンスが現在の geo セカンダリの場合は読み取り専用リスナー) に対応する DNS レコードが新しい仮想クラスターに移動されます。
現在のスケーリング操作の設計では、マネージドインスタンス自体が新しい仮想クラスターに完全に移行される前に、リスナーの DNS レコードが元の仮想クラスターから削除されます。この場合、インスタンスの IP アドレスをリスナーを使用して解決できない時間が長くなる場合があります。 この間、リスナーエンドポイントを使用してスケーリングされているインスタンスにアクセスしようとしている SQL クライアントでは、ログインエラーが発生し、次のエラー メッセージが表示される場合があります。"エラー 40532: ログインによって要求されたサーバー "xxx.xxx.xxx.xxx" を開くことができません。 ログインに失敗しました。 (Microsoft SQL Server、エラー: 40532)"。
この問題は、スケーリング操作の再設計を行うと解決できます。
解決済み
msdbの手動バックアップ用テーブルでユーザー名は保持されません
(2023 年 8 月に解決) 最近、msdb で自動バックアップのサポートを導入しましたが、テーブルには現在ユーザー名情報が含まれていません。
外部テーブルについてのクエリがサポートされていないというエラー メッセージで失敗します
外部テーブルに対するクエリが以下の一般的なエラー メッセージで失敗することがあります。"このデータベースの現在のサービス層またはパフォーマンス レベルでは、外部テーブルに対するクエリはサポートされません。 データベースのサービス層またはパフォーマンス レベルのアップグレードを検討してください" Azure SQL Managed Instance でサポートされている外部テーブルの種類は、PolyBase 外部テーブル (プレビュー) だけです。 PolyBase の外部テーブルに対するクエリを許可するには、sp_configure コマンドを実行して、マネージド インスタンスで PolyBase を有効にする必要があります。
Azure SQL Database のエラスティック クエリ機能に関連する外部テーブルは、SQL Managed Instance ではサポートされていませんが、作成とクエリは明示的にブロックされていませんでした。 PolyBase 外部テーブルのサポートとともに新しいチェックが導入され、PolyBase が有効になっていない場合に、マネージド インスタンス内の "あらゆる" 種類の外部テーブルに対するクエリがブロックされます。
サポートされていないエラスティック クエリの外部テーブルを使って、マネージド インスタンスから Azure SQL Database または Azure Synapse のデータのクエリを実行する場合は、代わりにリンク サーバー機能を使う必要があります。 SQL Managed Instance から SQL Database へのリンク サーバー接続を確立するには、こちらの記事の手順に従ってください。 SQL Managed Instance から SQL Synapse へのリンク サーバー接続を確立するには、ステップバイステップの手順を確認してください。 リンク サーバー接続の構成とテストには時間がかかるため、一時的な解決策として、エラスティック クエリ機能に関連する外部テーブルのクエリを有効にすることでこれを回避できます。
回避策: 外部テーブルに対するクエリを有効にする次のコマンドを (インスタンスごとに 1 回) 実行します。
sp_configure 'polybase enabled', 1;
GO
RECONFIGURE;
GO
SQL Server 認証を使用している場合、"@" を含むユーザー名はサポートされない
中間に "@" 記号を含むユーザー名 ('abc@xy' など) では、SQL Server 認証を使ってサインインできません。
CHECKSUM を使用せずに手動バックアップを復元すると、失敗する恐れがあります
(2020 年 6 月に解決済み) 特定の状況では、CHECKSUM なしでマネージド インスタンスで作成されたデータベースの手動バックアップの復元に失敗する可能性があります。 このような場合は、成功するまでバックアップの復元を再試行してください。
回避策:CHECKSUM を有効にして、マネージド インスタンス上のデータベースの手動バックアップを実行します。
既存のジョブを変更、無効化、または有効化するとエージェントが応答しなくなる
状況によっては、既存のジョブを変更したり、無効にしたり、有効にしたりすると、エージェントが応答しなくなることがあります。 この問題は、検出されると自動的に軽減され、エージェント プロセスが再起動されます。
リソース グループに対するアクセス許可が SQL Managed Instance に適用されない
リソース グループ (RG) に SQL Managed Instance 共同作成者 Azure ロールが適用されている場合、SQL Managed Instance には適用されず、効果がありません。
回避策:ユーザーの SQL Managed Instance 共同作成者ロールをサブスクリプション レベルで設定します。
エージェント プロセスを再起動すると、SQL エージェント ジョブが中断されることがある
(2020 年 3 月に解決済み) SQL Agent では、ジョブが開始されるたびに新しいセッションが作成され、メモリ消費量が徐々に増加します。 内部メモリの制限に達してスケジュールされたジョブの実行がブロックされることのないように、エージェント プロセスのメモリ使用量がしきい値に達すると、エージェント プロセスが再起動されます。 これにより、再起動の時点で実行中のジョブの実行が中断される可能性があります。
sp_send_db_mail の @query パラメーターはサポートされない
sp_send_db_mail プロシージャの @query パラメーターは機能しません。
サービス プリンシパルの再作成を提案する、Azure portal の誤解を招くエラー メッセージ
Azure SQL Managed Instance に関する Azure portal の [Active Directory 管理者] ページでは、サービス プリンシパルが既に存在している場合でも、次のエラー メッセージが表示されることがあります。
"Microsoft Entra ID (旧称 Azure Active Directory) にアクセスするには、Managed Instance にサービス プリンシパルが必要です。 サービス プリンシパルを作成するには、ここをクリックします"
マネージド インスタンスのサービス プリンシパルが既に存在するか、マネージド インスタンスの Microsoft Entra 認証が機能している場合、このエラー メッセージを無視できます。
サービス プリンシパルが存在するかどうかを確認するには、Azure portal の [エンタープライズ アプリケーション] ページに移動し、[アプリケーションの種類] ドロップダウン リストから [マネージド ID] を選択し、[適用] を選択し、検索ボックスにマネージド インスタンスの名前を入力します。 インスタンス名が結果の一覧に表示された場合、サービス プリンシパルは既に存在しており、それ以上の操作は必要ありません。
既にエラー メッセージの指示に従って、エラー メッセージのリンクを選んだ場合、マネージド インスタンスのサービス プリンシパルは作成し直されているはずです。 その場合、Microsoft Entra 認証が正しく機能するように、新しく作成されたサービス プリンシパルに Microsoft Entra ID 読み取りアクセス許可を割り当ててください。 これは、Azure PowerShell でこちらの手順に従うことで実行できます
コンテンツの改善への協力
Azure SQL のドキュメントに投稿するには、Docs 共同作成者ガイドに関する記事をご覧ください。
関連するコンテンツ
SQL Managed Instance の更新情報と機能強化の一覧については、SQL Managed Instance サービスの更新情報に関するページを参照してください。
すべての Azure サービスの更新情報や機能強化については、サービスの更新情報を参照してください。