Azure SQL Database と SQL Managed Instance の新機能What's new in Azure SQL Database & SQL Managed Instance?

適用対象: Azure SQL Database Azure SQL Managed Instance

この記事では、現在パブリック プレビュー段階にある Azure SQL Database と Azure SQL Managed Instance の機能を示します。This article lists Azure SQL Database and Azure SQL Managed Instance features that are currently in public preview. SQL Database と SQL Managed Instance の更新情報や機能強化については、SQL Database と SQL Managed Instance サービスの更新情報に関するページを参照してください。For SQL Database and SQL Managed Instance updates and improvements, see SQL Database & SQL Managed Instance service updates. 他の Azure サービスの更新情報や機能強化については、サービスの更新情報を参照してください。For updates and improvements to other Azure services, see Service updates.

新機能What's new?

Azure SQL Database と Azure SQL Managed Instance のドキュメントは別々のセクションに分割されました。Documentation for Azure SQL Database and Azure SQL Managed Instance has been split into separate sections. また、Azure SQL Database マネージド インスタンス からマネージド インスタンスを参照する方法を Azure SQL Managed Instance へ更新しました。We've also updated how we refer to a managed instance from Azure SQL Database managed instance to Azure SQL Managed Instance.

これは、一部の特徴や機能が単一データベースとマネージド インスタンスの間で大きく異なるための処置です。個々の共有記事で Azure SQL Database と Azure SQL Managed Instance 間の複雑な差異を説明することはますます困難になっています。We've done this because some features and functionality vary greatly between a single database and a managed instance, and it has become increasingly challenging to explain complex nuances between Azure SQL Database and Azure SQL Managed Instance in individual shared articles.

さまざまな Azure SQL 製品間を明確に区別することで、Azure での SQL Server データベース エンジンの操作が簡素化され、合理化されます。これは、Azure SQL Database の単一マネージド データベースであるか、Azure SQL Managed Instance で複数のデータベースをホストする本格的なマネージド インスタンスであるか、それとも Azure の仮想マシンでホストされる使い慣れたオンプレミスの SQL Server 製品であるかを問いません。This clarification between the different Azure SQL products should simplify and streamline the process of working with the SQL Server database engine in Azure, whether it's a single managed database in Azure SQL Database, a fully fledged managed instance hosting multiple databases in Azure SQL Managed Instance, or the familiar on-premises SQL Server product hosted on a virtual machine in Azure.

これは進行中の作業であり、まだ更新されていない記事があることを考慮してください。Consider that this is a work in progress and not every article has been updated yet. たとえば、Azure SQL Database と Azure SQL Managed Instance 間で共有される Transact-SQL (T-SQL) ステートメントやストアド プロシージャ、その他多くの機能についてのドキュメント化はまだ完了していません。コンテンツの明確化作業が続く間、ご不便をおかけして申し訳ございません。For example, documentation for Transact-SQL (T-SQL) statements, stored procedures, and many features shared between Azure SQL Database and Azure SQL Managed Instance are not yet complete, so we thank you for your patience as we continue clarifying the content.

次の表は、用語の変更に関して簡単に比較しています。This table provides a quick comparison for the change in terminology:

新しい用語New term 従来の用語Previous term 説明Explanation
Azure SQL Managed InstanceAzure SQL Managed Instance Azure SQL Database マネージド インスタンスAzure SQL Database managed instance Azure SQL Managed Instance は、Azure SQL Database 内のデプロイ オプションではなく、Azure SQL ファミリ内の独自の製品です。Azure SQL Managed Instance is its own product within the Azure SQL family, rather than just a deployment option within Azure SQL Database.
Azure SQL DatabaseAzure SQL Database Azure SQL Database 単一データベースAzure SQL Database single database 明示的に指定しない限り、"Azure SQL Database" という製品名には、単一データベースと、エラスティック プールにデプロイされたデータベースの両方が含まれます。Unless explicitly specified otherwise, the product name Azure SQL Database includes both single databases and databases deployed to an elastic pool.
Azure SQL DatabaseAzure SQL Database Azure SQL Database エラスティック プールAzure SQL Database elastic pool 明示的に指定しない限り、"Azure SQL Database" という製品名には、単一データベースと、エラスティック プールにデプロイされたデータベースの両方が含まれます。Unless explicitly specified otherwise, the product name Azure SQL Database includes both single databases and databases deployed to an elastic pool.
Azure SQL DatabaseAzure SQL Database Azure SQL データベースAzure SQL Database この用語は同じままですが、単一データベースとエラスティック プールのデプロイにのみ適用され、マネージド インスタンスは含まれません。Though the term stays the same, it now only applies to single database and elastic pool deployments, and does not include managed instance.
Azure SQLAzure SQL 該当なしN/A これは、Azure で使用可能な SQL Server データベース エンジン製品のファミリを指します。Azure SQL Database、Azure SQL Managed Instance、および Azure VM 上の SQL Server。This refers to the family of SQL Server database engine products that are available in Azure: Azure SQL Database, Azure SQL Managed Instance, and SQL Server on Azure VMs.

パブリック プレビュー段階の機能Features in public preview

機能Feature 詳細Details
Elastic Database ジョブ (プレビュー)Elastic database jobs (preview) 詳しくは、「エラスティック ジョブの作成、構成、および管理」をご覧ください。For information, see Create, configure, and manage elastic jobs.
エラスティック クエリElastic queries 詳しくは、エラスティック クエリの概要に関する記事をご覧ください。For information, see Elastic query overview.
エラスティック トランザクションElastic transactions クラウド データベースにまたがる分散トランザクションDistributed transactions across cloud databases.
Azure portal のクエリ エディターQuery editor in the Azure portal 詳しくは、「Azure portal の SQL クエリ エディターを使用した接続とデータの照会」をご覧ください。For information, see Use the Azure portal's SQL query editor to connect and query data.
SQL AnalyticsSQL Analytics 詳細については、Azure SQL Analytics に関するページをご覧ください。For information, see Azure SQL Analytics.
 

新機能New features

2019 年下期の SQL Managed Instance の更新プログラムSQL Managed Instance H2 2019 updates

2019 年上期の SQL Managed Instance の更新プログラムSQL Managed Instance H1 2019 updates

2019 年上期の SQL Managed Instance のデプロイ モデルでは、次の機能が有効になっています。The following features are enabled in the SQL Managed Instance deployment model in H1 2019:

既知の問題Known issues

問題Issue 検出した日Date discovered StatusStatus 解決した日Date resolved
@query パラメーターの使用時、プロシージャ sp_send_dbmail が一時的に失敗する可能性があるProcedure sp_send_dbmail may transiently fail when @query parameter is used 2021 年 1 月Jan 2021 回避策ありHas Workaround
サーバー信頼グループからマネージド インスタンスを削除した後、分散トランザクションを実行できるDistributed transactions can be executed after removing Managed Instance from Server Trust Group 2020 年 10 月Oct 2020 回避策ありHas Workaround
マネージド インスタンスのスケーリング操作の後、分散トランザクションを実行できないDistributed transactions cannot be executed after Managed Instance scaling operation 2020 年 10 月Oct 2020 回避策ありHas Workaround
Azure SQL の BULK INSERT/OPENROWSET、およびマネージド インスタンスの BACKUP/RESTORE ステートメントで、Azure AD の Manage Identity を使用して Azure Storage に対する認証を実行できないBULK INSERT/OPENROWSET in Azure SQL and BACKUP/RESTORE statement in Managed Instance cannot use Azure AD Manage Identity to authenticate to Azure storage 2020 年 9 月Sep 2020 回避策ありHas Workaround
サービス プリンシパルから Azure AD および AKV にアクセスできませんService Principal cannot access Azure AD and AKV 2020 年 8 月Aug 2020 回避策ありHas Workaround
CHECKSUM を使用せずに手動バックアップを復元すると失敗することがあるRestoring manual backup without CHECKSUM might fail 2020 年 5 月May 2020 解決済みResolved 2020 年 6 月June 2020
既存のジョブを変更、無効化、または有効化するとエージェントが応答しなくなるAgent becomes unresponsive upon modifying, disabling, or enabling existing jobs 2020 年 5 月May 2020 解決済みResolved 2020 年 6 月June 2020
リソース グループに対するアクセス許可が SQL Managed Instance に適用されないPermissions on resource group not applied to SQL Managed Instance 2020 年 2 月Feb 2020 解決済みResolved 2020 年 11 月Nov 2020
ポータルを使用したフェールオーバー グループに対する手動フェールオーバーの制限Limitation of manual failover via portal for failover groups 2020 年 1 月Jan 2020 回避策ありHas Workaround
SQL Agent ロールには、sysadmin 以外のログインに対する明示的な EXECUTE 権限が必要ですSQL Agent roles need explicit EXECUTE permissions for non-sysadmin logins 2019 年 12 月Dec 2019 回避策ありHas Workaround
エージェント プロセスを再起動すると、SQL Agent ジョブが中断されることがあるSQL Agent jobs can be interrupted by Agent process restart 2019 年 12 月Dec 2019 解決済みResolved 2020 年 3 月Mar 2020
SSDT 内で Azure AD のログインとユーザーがサポートされないAzure AD logins and users are not supported in SSDT 2019 年 11 月Nov 2019 回避策なしNo Workaround
インメモリ OLTP のメモリ制限が適用されないIn-memory OLTP memory limits are not applied 2019 年 10 月Oct 2019 回避策ありHas Workaround
空ではないファイルを削除しようとしたときに誤ったエラーが返されるWrong error returned while trying to remove a file that is not empty 2019 年 10 月Oct 2019 回避策ありHas Workaround
サービス レベルの変更とインスタンスの作成操作が、進行中のデータベースの復元によってブロックされるChange service tier and create instance operations are blocked by ongoing database restore 2019 年 9 月Sep 2019 回避策ありHas Workaround
Business Critical サービス レベルの Resource Governor をフェールオーバー後に再構成しなければならない場合があるResource Governor on Business Critical service tier might need to be reconfigured after failover 2019 年 9 月Sep 2019 回避策ありHas Workaround
サービス レベルのアップグレード後は、複数データベースにまたがる Service Broker のダイアログを再初期化する必要があるCross-database Service Broker dialogs must be reinitialized after service tier upgrade 2019 年 8 月Aug 2019 回避策ありHas Workaround
Azure AD ログイン タイプの偽装がサポートされないImpersonation of Azure AD login types is not supported 2019 年 7 月Jul 2019 回避策なしNo Workaround
sp_send_db_mail の @query パラメーターはサポートされない@query parameter not supported in sp_send_db_mail 2019 年 4 月Apr 2019 解決済みResolved 2021 年 1 月Jan 2021
geo フェールオーバー後、トランザクション レプリケーションを再構成する必要があるTransactional Replication must be reconfigured after geo-failover 2019 年 3 月Mar 2019 回避策なしNo Workaround
一時的なデータベースが RESTORE 操作中に使用されるTemporary database is used during RESTORE operation 回避策ありHas Workaround
TEMPDB の構造と内容は再作成されるTEMPDB structure and content is re-created 回避策なしNo Workaround
小さなデータベース ファイルによる記憶域の超過Exceeding storage space with small database files 回避策ありHas Workaround
データベース名の代わりに GUID 値が表示されるGUID values shown instead of database names 回避策ありHas Workaround
エラー ログが非永続的であるError logs aren't persisted 回避策なしNo Workaround
同じインスタンス内にある 2 つのデータベース上でトランザクション スコープがサポートされないTransaction scope on two databases within the same instance isn't supported 回避策ありHas Workaround 2020 年 3 月Mar 2020
CLR モジュールとリンク サーバーでローカル IP アドレスを参照できないことがあるCLR modules and linked servers sometimes can't reference a local IP address 回避策ありHas Workaround
Azure Blob Storage からデータベースを復元した後、DBCC CHECKDB を使用してデータベースの整合性が検証されません。Database consistency not verified using DBCC CHECKDB after restore database from Azure Blob Storage. 解決済みResolved 2019 年 11 月Nov 2019
ソース データベースにインメモリ OLTP オブジェクトが含まれている場合、Business Critical レベルから General Purpose レベルへの組み込みのポイントインタイム データベース復元は成功しません。Point-in-time database restore from Business Critical tier to General Purpose tier will not succeed if source database contains in-memory OLTP objects. 解決済みResolved 2019 年 10 月Oct 2019
セキュリティで保護された接続を使用する外部 (Azure 以外) メール サーバーのデータベース メール機能Database mail feature with external (non-Azure) mail servers using secure connection 解決済みResolved 2019 年 10 月Oct 2019
包含データベースは、SQL Managed Instance 内でサポートされているContained databases not supported in SQL Managed Instance 解決済みResolved 2019 年 8 月Aug 2019

@query パラメーターの使用時、プロシージャ sp_send_dbmail が一時的に失敗する可能性があるProcedure sp_send_dbmail may transiently fail when @query parameter is used

@query パラメーターが使用されているとき、プロシージャ sp_send_dbmail が一時的に失敗する可能性があります。Procedure sp_send_dbmail may transiently fail when @query parameter is used. この問題が発生した場合は、プロシージャ sp_send_dbmail の実行が 2 回に 1 回、エラー Msg 22050, Level 16, State 1 とメッセージ Failed to initialize sqlcmd library with error number -2147467259 で失敗します。When this issue occurs, every second execution of procedure sp_send_dbmail fails with error Msg 22050, Level 16, State 1 and message Failed to initialize sqlcmd library with error number -2147467259. このエラーを正しく確認できるようにするには、パラメーター @exclude_query_output を既定値 0 にしてこのプロシージャを呼び出す必要があります。そうしないと、このエラーは伝達されません。To be able to see this error properly, the procedure should be called with default value 0 for the parameter @exclude_query_output, otherwise the error will not be propagated. この問題は、sp_send_dbmail での権限借用と接続プールの使用方法に関連した既知のバグが原因で発生します。This problem is caused by a known bug related to how sp_send_dbmail is using impersonation and connection pooling. この問題を回避するには、電子メールを送信するためのコードを、出力パラメーター @mailitem_id に依存する再試行ロジックにラップします。To work around this issue wrap code for sending email into a retry logic that relies on output parameter @mailitem_id. 実行が失敗した場合は、このパラメーター値が NULL になり、電子メールを正常に送信するには sp_send_dbmail をもう 1 回呼び出す必要があることを示します。If the execution fails, then parameter value will be NULL, indicating sp_send_dbmail should be called one more time to successfully send an email. この再試行ロジックの例を次に示します。Here is an example this retry logic.

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

サーバー信頼グループからマネージド インスタンスを削除した後、分散トランザクションを実行できるDistributed transactions can be executed after removing Managed Instance from Server Trust Group

サーバー信頼グループは、分散トランザクションを実行するための前提条件である、マネージド インスタンス間の信頼を確立するために使用されます。Server Trust Groups are used to establish trust between Managed Instances that is prerequisite for executing distributed transactions. サーバー信頼グループからマネージド インスタンスを削除した後、またはグループを削除した後も、分散トランザクションを実行できる可能性があります。After removing Managed Instance from Server Trust Group or deleting the group you still might be able to execute distributed transactions. 分散トランザクションを確実に無効にするための回避策を適用できます。それは、マネージド インスタンスで手動フェールオーバーを開始することです。There is a workaround you can apply to be sure that distributed transactions are disabled and that is user-initiated manual failover on Managed Instance.

マネージド インスタンスのスケーリング操作の後、分散トランザクションを実行できないDistributed transactions cannot be executed after Managed Instance scaling operation

サービス レベルまたは仮想コア数の変更といったマネージド インスタンスのスケーリング操作を実行すると、バックエンドのサーバー信頼グループの設定がリセットされ、分散トランザクションの実行が無効になります。Managed Instance scaling operations that include changing service tier or number of vCores will reset Server Trust Group settings on the backend and disable running distributed transactions. 回避するには、Azure portal でサーバー信頼グループを削除して、新しく作成します。As a workaround, delete and create new Server Trust Group on Azure portal.

BULK INSERT および BACKUP/RESTORE ステートメントで、マネージド ID を使用して Azure storage にアクセスできないBULK INSERT and BACKUP/RESTORE statements cannot use Managed Identity to access Azure storage

BULK INSERT、BACKUP、RESTORE ステートメント、および OPENROWSET 関数では、Azure storage に対する認証に、DATABASE SCOPED CREDENTIAL をマネージド ID と共に使用することはできません。Bulk insert, BACKUP, and RESTORE statements, and OPENROWSET function cannot use DATABASE SCOPED CREDENTIAL with Managed Identity to authenticate to Azure storage. 回避するには、Shared Access Signature 認証に切り替えます。As a workaround, switch to SHARED ACCESS SIGNATURE authentication. 次の例は、Azure SQL (データベースと Managed Instance の両方) では機能しません。The following example will not work on Azure SQL (both Database and Managed Instance):

CREATE DATABASE SCOPED CREDENTIAL msi_cred WITH IDENTITY = 'Managed Identity';
GO
CREATE EXTERNAL DATA SOURCE MyAzureBlobStorage
  WITH ( TYPE = BLOB_STORAGE, LOCATION = 'https://****************.blob.core.windows.net/curriculum', CREDENTIAL= msi_cred );
GO
BULK INSERT Sales.Invoices FROM 'inv-2017-12-08.csv' WITH (DATA_SOURCE = 'MyAzureBlobStorage');

回避策:Shared Access Signature を使用して、ストレージに対する認証を実行しますWorkaround: Use Shared Access Signature to authenticate to storage.

サービス プリンシパルから Azure AD および AKV にアクセスできませんService Principal cannot access Azure AD and AKV

場合によっては、Azure AD および Azure Key Vault (AKV) サービスへのアクセスに使用されるサービス プリンシパルに問題が存在することがあります。In some circumstances there might exist an issue with Service Principal used to access Azure AD and Azure Key Vault (AKV) services. そのため、この問題は SQL Managed Instance での Azure AD 認証および Transparent Database Encryption (TDE) の使用に影響します。As a result, this issue impacts usage of Azure AD authentication and Transparent Database Encryption (TDE) with SQL Managed Instance. これは、断続的な接続の問題として発生する可能性があります。または、CREATE LOGIN/USER FROM EXTERNAL PROVIDER または EXECUTE AS LOGIN/USER などのステートメントを実行できない場合に発生する可能性があります。This might be experienced as an intermittent connectivity issue, or not being able to run statements such are CREATE LOGIN/USER FROM EXTERNAL PROVIDER or EXECUTE AS LOGIN/USER. 新しい Azure SQL Managed Instance 上でカスタマー マネージド キーを使用して TDE を設定しても、状況によっては機能しないことがあります。Setting up TDE with customer-managed key on a new Azure SQL Managed Instance might also not work in some circumstances.

回避策:更新コマンドを実行する前に、ご利用の SQL Managed Instance 上でこの問題が発生しないようにするには、または更新コマンドの実行後にこの問題が既に発生している場合は、Azure portal に移動し、SQL Managed Instance の [Active Directory 管理者] ブレード にアクセスします。Workaround: To prevent this issue from occurring on your SQL Managed Instance before executing any update commands, or in case you have already experienced this issue after update commands, go to Azure portal, access SQL Managed Instance Active Directory admin blade. "Azure Active Directory にアクセスするには、Managed Instance にサービス プリンシパルが必要です。Verify if you can see the error message "Managed Instance needs a Service Principal to access Azure Active Directory. サービス プリンシパルを作成するには、ここをクリックします" というエラー メッセージが表示されるかどうかを確認します。Click here to create a Service Principal". このエラー メッセージが表示された場合は、それをクリックし、このエラーが解決されるまで、示されるステップ バイ ステップの手順に従います。In case you have encountered this error message, click on it, and follow the step-by-step instructions provided until this error have been resolved.

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

特定の状況で、CHECKSUM なしでマネージド インスタンス上に作成されたデータベースの手動バックアップが復元に失敗することがあります。In certain circumstances manual backup of databases that was made on a managed instance without CHECKSUM might fail to be restored. このような場合は、成功するまでバックアップの復元を再試行してください。In such cases, retry restoring the backup until you're successful.

回避策:CHECKSUM を有効にして、マネージド インスタンス上のデータベースの手動バックアップを実行します。Workaround: Take manual backups of databases on managed instances with CHECKSUM enabled.

既存のジョブを変更、無効化、または有効化するとエージェントが応答しなくなるAgent becomes unresponsive upon modifying, disabling, or enabling existing jobs

状況によっては、既存のジョブを変更したり、無効にしたり、有効にしたりすると、エージェントが応答しなくなることがあります。In certain circumstances, modifying, disabling, or enabling an existing job can cause the agent to become unresponsive. この問題は、検出されると自動的に軽減され、エージェント プロセスが再起動されます。The issue is automatically mitigated upon detection, resulting in a restart of the agent process.

リソース グループに対するアクセス許可が SQL Managed Instance に適用されないPermissions on resource group not applied to SQL Managed Instance

リソース グループ (RG) に SQL Managed Instance 共同作成者 Azure ロールが適用されている場合、SQL Managed Instance には適用されず、効果がありません。When the SQL Managed Instance Contributor Azure role is applied to a resource group (RG), it's not applied to SQL Managed Instance and has no effect.

回避策:ユーザーの SQL Managed Instance 共同作成者ロールをサブスクリプション レベルで設定します。Workaround: Set up a SQL Managed Instance Contributor role for users at the subscription level.

ポータルを使用したフェールオーバー グループに対する手動フェールオーバーの制限Limitation of manual failover via portal for failover groups

フェールオーバー グループが、異なる Azure サブスクリプションやリソース グループのインスタンスにまたがっている場合、フェールオーバー グループのプライマリ インスタンスから手動フェールオーバーを開始することはできません。If a failover group spans across instances in different Azure subscriptions or resource groups, manual failover cannot be initiated from the primary instance in the failover group.

回避策:Geo セカンダリ インスタンスからポータル経由でフェールオーバーを開始します。Workaround: Initiate failover via the portal from the geo-secondary instance.

SQL エージェント ロールには、sysadmin 以外のログインに対する明示的な EXECUTE 権限が必要ですSQL Agent roles need explicit EXECUTE permissions for non-sysadmin logins

sysadmin 以外のログインが SQL Agent の固定データベース ロールに追加されると、これらのログインを機能させるには、明示的な EXECUTE 権限を Master ストアド プロシージャに付与する必要があるという問題が存在します。If non-sysadmin logins are added to any SQL Agent fixed database roles, there exists an issue in which explicit EXECUTE permissions need to be granted to the master stored procedures for these logins to work. この問題が発生した場合は、エラー メッセージ "EXECUTE 権限がオブジェクト <object_name> で拒否されました (Microsoft SQL Server、エラー:229)" が表示されます。If this issue is encountered, the error message "The EXECUTE permission was denied on the object <object_name> (Microsoft SQL Server, Error: 229)" will be shown.

回避策:SQL Agent 固定データベース ロール (SQLAgentUserRole、SQLAgentReaderRole、または SQLAgentOperatorRole) にログインを追加した後、これらのロールに追加された各ログインに対して次の T-SQL スクリプトを実行して、一覧表示されているストアド プロシージャに明示的に EXECUTE 権限を付与します。Workaround: Once you add logins to a SQL Agent fixed database role (SQLAgentUserRole, SQLAgentReaderRole, or SQLAgentOperatorRole), for each of the logins added to these roles, execute the below T-SQL script to explicitly grant EXECUTE permissions to the stored procedures listed.

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]

エージェント プロセスを再起動すると、SQL エージェント ジョブが中断されることがあるSQL Agent jobs can be interrupted by Agent process restart

(2020 年 3 月に解決済み) SQL Agent では、ジョブが開始されるたびに新しいセッションが作成され、メモリ消費量が徐々に増加します。(Resolved in March 2020) SQL Agent creates a new session each time a job is started, gradually increasing memory consumption. 内部メモリの制限に達してスケジュールされたジョブの実行がブロックされることのないように、エージェント プロセスのメモリ使用量がしきい値に達すると、エージェント プロセスが再起動されます。To avoid hitting the internal memory limit, which would block execution of scheduled jobs, Agent process will be restarted once its memory consumption reaches threshold. これにより、再起動の時点で実行中のジョブの実行が中断される可能性があります。It may result in interrupting execution of jobs running at the moment of restart.

インメモリ OLTP のメモリ制限が適用されないIn-memory OLTP memory limits are not applied

Business Critical サービス レベルでは、メモリ最適化オブジェクトの最大メモリ制限が正しく適用されない場合があります。The Business Critical service tier will not correctly apply max memory limits for memory-optimized objects in some cases. SQL Managed Instance では、ワークロードが、インメモリ OLTP 操作に対してより多くのメモリを使用できる場合があり、これがインスタンスの可用性と安定性に影響を及ぼすことがあります。SQL Managed Instance may enable workload to use more memory for in-memory OLTP operations, which may affect availability and stability of the instance. インメモリ OLTP クエリは、制限に達しても、すぐには失敗しない可能性があります。In-memory OLTP queries that are reaching the limits might not fail immediately. この問題は、まもなく解決されます。This issue will be fixed soon. さらに多くのインメモリ OLTP メモリを使用するクエリは、制限に達するとすぐに失敗するようになります。The queries that use more in-memory OLTP memory will fail sooner if they reach the limits.

回避策:SQL Server Management Studio を使用して インメモリ OLTP ストレージの使用状況を監視し、使用可能な量を超えるメモリがワークロードによって使用されないようにします。Workaround: Monitor in-memory OLTP storage usage using SQL Server Management Studio to ensure that the workload is not using more than the available memory. 仮想コアの数に応じてメモリ制限を増やすか、ワークロードを最適化して、使用するメモリを減らします。Increase the memory limits that depend on the number of vCores, or optimize your workload to use less memory.

空ではないファイルを削除しようとしたときに誤ったエラーが返されるWrong error returned while trying to remove a file that is not empty

SQL Server と SQL Managed Instance では、ユーザーは空でないファイルを削除できませんSQL Server and SQL Managed Instance don't allow a user to drop a file that is not empty. ALTER DATABASE REMOVE FILE ステートメントを使用して空でないデータ ファイルを削除しようとすると、エラー Msg 5042 – The file '<file_name>' cannot be removed because it is not empty はすぐには返されません。If you try to remove a nonempty data file using an ALTER DATABASE REMOVE FILE statement, the error Msg 5042 – The file '<file_name>' cannot be removed because it is not empty will not be immediately returned. SQL Managed Instance では引き続きファイルの削除が試行されますが、操作は 30 分後に Internal server error で失敗します。SQL Managed Instance will keep trying to drop the file, and the operation will fail after 30 minutes with Internal server error.

回避策:DBCC SHRINKFILE (N'<file_name>', EMPTYFILE) コマンドを使用して、ファイルの内容を削除します。Workaround: Remove the contents of the file using the DBCC SHRINKFILE (N'<file_name>', EMPTYFILE) command. ファイル グループ内の唯一のファイルの場合は、ファイルを圧縮する前に、このファイル グループに関連付けられているテーブルまたはパーティションからデータを削除する必要があります。また、必要に応じて、このデータを別のテーブルまたはパーティションに読み込みます。If this is the only file in the file group you would need to delete data from the table or partition associated to this file group before you shrink the file, and optionally load this data into another table/partition.

サービス レベルの変更とインスタンスの作成操作が、進行中のデータベースの復元によってブロックされるChange service tier and create instance operations are blocked by ongoing database restore

進行中の RESTORE ステートメント、データ移行サービスの移行プロセス、組み込みのポイントインタイム リストアでは、復元プロセスが完了するまで、サービス レベルの更新や既存のインスタンスのサイズ変更、新しいインスタンスの作成がブロックされます。Ongoing RESTORE statement, Data Migration Service migration process, and built-in point-in-time restore will block updating a service tier or resize of the existing instance and creating new instances until the restore process finishes.

復元プロセスでは、復元プロセスが実行されているのと同じサブネット内のマネージド インスタンスとインスタンス プールでこれらの操作がブロックされます。The restore process will block these operations on the managed instances and instance pools in the same subnet where the restore process is running. インスタンス プール内のインスタンスは影響を受けません。The instances in instance pools are not affected. サービス レベルの作成または変更操作は失敗したり、タイムアウトになったりしません。復元プロセスが完了するかキャンセルされると、処理が続行されます。Create or change service tier operations will not fail or time out. They will proceed once the restore process is completed or canceled.

回避策:サービス レベルの作成または更新操作の優先順位が高い場合は、復元プロセスが完了するか、復元プロセスがキャンセルされるまで待機します。Workaround: Wait until the restore process finishes, or cancel the restore process if the creation or update-service-tier operation has higher priority.

Business Critical サービス レベルの Resource Governor をフェールオーバー後に再構成しなければならない場合があるResource Governor on Business Critical service tier might need to be reconfigured after failover

ユーザー ワークロードに割り当てられるリソースを制限することを可能にする Resource Governor 機能では、フェールオーバー後、またはユーザーが開始したサービス レベルの変更 (たとえば、最大仮想コア数やインスタンスの最大ストレージ サイズの変更) 後に、一部のユーザー ワークロードが誤って分類されることがあります。The Resource Governor feature that enables you to limit the resources assigned to the user workload might incorrectly classify some user workload after failover or a user-initiated change of service tier (for example, the change of max vCore or max instance storage size).

回避策:Resource Governor を使用している場合、ALTER RESOURCE GOVERNOR RECONFIGURE を定期的に、または、インスタンスの開始時に SQL タスクを実行する SQL Agent ジョブの一環として実行します。Workaround: Run ALTER RESOURCE GOVERNOR RECONFIGURE periodically or as part of a SQL Agent job that executes the SQL task when the instance starts if you are using Resource Governor.

サービス レベルのアップグレード後は、複数データベースにまたがる Service Broker のダイアログを再初期化する必要があるCross-database Service Broker dialogs must be reinitialized after service tier upgrade

サービス レベルの変更操作の後、複数データベースにまたがる Service Broker のダイアログで、他のデータベースのサービスにメッセージが配信されなくなります。Cross-database Service Broker dialogs will stop delivering the messages to the services in other databases after change service tier operation. メッセージは "失われたわけではなく"、センダーのキューに存在しています。The messages are not lost, and they can be found in the sender queue. SQL Managed Instance の仮想コア数やインスタンスのストレージ サイズを変更すると、すべてのデータベースについて、sys.databases ビューの service_broke_guid 値が変更されます。Any change of vCores or instance storage size in SQL Managed Instance will cause a service_broke_guid value in sys.databases view to be changed for all databases. BEGIN DIALOG ステートメントを使用して作成された、他のデータベースの Service Broker を参照する DIALOG から、ターゲット サービスにメッセージが配信されなくなります。Any DIALOG created using a BEGIN DIALOG statement that references Service Brokers in other database will stop delivering messages to the target service.

回避策:複数データベースにまたがる Service Broker ダイアログのメッセージ交換を使用するアクティビティはすべて、サービス レベルを更新する前に停止し、後で再初期化してください。Workaround: Stop any activity that uses cross-database Service Broker dialog conversations before updating a service tier, and reinitialize them afterward. サービス レベルの変更後、未配信のままのメッセージがあった場合は、それらのメッセージをソース キューから読み取って、ターゲット キューに再送信します。If there are remaining messages that are undelivered after a service tier change, read the messages from the source queue and resend them to the target queue.

Azure AD ログイン タイプの偽装がサポートされないImpersonation of Azure AD login types is not supported

次の Azure Active Directory (Azure AD) プリンシパルの、EXECUTE AS USER または EXECUTE AS LOGIN を使用した偽装はサポートされていません。Impersonation using EXECUTE AS USER or EXECUTE AS LOGIN of the following Azure Active Directory (Azure AD) principals is not supported:

  • 別名が付けられた Azure AD ユーザー。Aliased Azure AD users. この場合は 15517 エラーが返されます。The following error is returned in this case: 15517.
  • Azure AD アプリケーションまたはサービス プリンシパルに基づく Azure AD のログインおよびユーザー。Azure AD logins and users based on Azure AD applications or service principals. この場合は 15517 および 15406 エラーが返されます。The following errors are returned in this case: 15517 and 15406.

sp_send_db_mail の @query パラメーターはサポートされない@query parameter not supported in sp_send_db_mail

sp_send_db_mail プロシージャの @query パラメーターは機能しません。The @query parameter in the sp_send_db_mail procedure doesn't work.

geo フェールオーバー後、トランザクション レプリケーションを再構成する必要があるTransactional Replication must be reconfigured after geo-failover

自動フェールオーバー グループ内のデータベースでトランザクション レプリケーションが有効な場合、SQL Managed Instance 管理者は、別のリージョンへのフェールオーバーが発生した後で、古いプライマリ上のすべてのパブリケーションをクリーンアップしてから、新しいプライマリ上でそれらを再構成する必要があります。If Transactional Replication is enabled on a database in an auto-failover group, the SQL Managed Instance administrator must clean up all publications on the old primary and reconfigure them on the new primary after a failover to another region occurs. 詳細については、「レプリケーション」をご覧ください。For more information, see Replication.

SSDT 内で Azure AD のログインとユーザーがサポートされないAzure AD logins and users are not supported in SSDT

SQL Server Data Tools では、Azure AD のログインとユーザーが完全にはサポートされません。SQL Server Data Tools don't fully support Azure AD logins and users.

一時的なデータベースが RESTORE 操作中に使用されるTemporary database is used during RESTORE operation

SQL Managed Instance でデータベースが復元されるとき、復元サービスではまず、目的の名前で空のデータベースが作成され、インスタンス上でその名前が割り当てられます。When a database is restoring in SQL Managed Instance, the restore service will first create an empty database with the desired name to allocate the name on the instance. しばらくすると、このデータベースは削除され、実際のデータベースの復元が開始されます。After some time, this database will be dropped, and restoring of the actual database will be started.

"復元中" 状態のデータベースには、名前ではなくランダムな GUID 値が一時的に与えられます。The database that is in Restoring state will temporarily have a random GUID value instead of name. 復元プロセスが終了すると、一時的な名前は、RESTORE ステートメントで指定した目的の名前に変更されます。The temporary name will be changed to the desired name specified in the RESTORE statement once the restore process finishes.

初期フェーズでは、ユーザーは空のデータベースにアクセスしたり、さらにはこのデータベースにテーブルを作成したり、データを読み込んだりできます。In the initial phase, a user can access the empty database and even create tables or load data in this database. この一時的なデータベースは、復元サービスで 2 つ目のフェーズが開始されると削除されます。This temporary database will be dropped when the restore service starts the second phase.

回避策:復元の完了を確認するまで、復元中のデータベースにはアクセスしないでください。Workaround: Do not access the database that you are restoring until you see that restore is completed.

TEMPDB の構造と内容は再作成されるTEMPDB structure and content is re-created

tempdb は常に 12 個のデータ ファイルに分割され、ファイルの構造は変更できません。The tempdb database is always split into 12 data files, and the file structure cannot be changed. ファイルあたりの最大サイズは変更できず、tempdb に新しいファイルを追加することはできません。The maximum size per file can't be changed, and new files cannot be added to tempdb. Tempdb は、インスタンスが開始またはフェールオーバーしたときに、常に空のデータベースとして再作成され、tempdb で行われたどの変更も保持されません。Tempdb is always re-created as an empty database when the instance starts or fails over, and any changes made in tempdb will not be preserved.

小さなデータベース ファイルによる記憶域の超過Exceeding storage space with small database files

インスタンスが Azure ストレージの制限に達する可能性があるため、CREATE DATABASEALTER DATABASE ADD FILE、および RESTORE DATABASE ステートメントが失敗することがあります。CREATE DATABASE, ALTER DATABASE ADD FILE, and RESTORE DATABASE statements might fail because the instance can reach the Azure Storage limit.

SQL Managed Instance の各 General Purpose インスタンスには、Azure Premium ディスク領域用に予約された最大 35 TB のストレージがあります。Each General Purpose instance of SQL Managed Instance has up to 35 TB of storage reserved for Azure Premium Disk space. 各データベース ファイルは、個別の物理ディスクに配置されます。Each database file is placed on a separate physical disk. ディスク サイズとして、128 GB、256 GB、512 GB、1 TB、4 TB のいずれかを指定できます。Disk sizes can be 128 GB, 256 GB, 512 GB, 1 TB, or 4 TB. ディスク上の未使用領域については請求されませんが、Azure Premium ディスクのサイズ合計が 35 TB を超えることはできません。Unused space on the disk isn't charged, but the total sum of Azure Premium Disk sizes can't exceed 35 TB. 場合によっては、内部の断片化のために、合計で 8 TB を必要としない Managed Instance が、記憶域のサイズに関する 35 TB の Azure での制限を超える場合があります。In some cases, a managed instance that doesn't need 8 TB in total might exceed the 35 TB Azure limit on storage size due to internal fragmentation.

たとえば、SQL Managed Instance の General Purpose インスタンスに、4 TB のディスクに配置されているサイズが 1.2 TB の大きなファイルが 1 つあるとします。For example, a General Purpose instance of SQL Managed Instance might have one large file that's 1.2 TB in size placed on a 4-TB disk. また、個別の 128 GB のディスクに配置される、それぞれ 1 GB のファイルが 248 個あるとします。It also might have 248 files that are 1 GB each and that are placed on separate 128-GB disks. 次の点に注意してください。In this example:

  • 割り当てられるディスク ストレージの合計サイズは、1 x 4 TB + 248 x 128 GB = 35 TB となります。The total allocated disk storage size is 1 x 4 TB + 248 x 128 GB = 35 TB.
  • インスタンス上のデータベースの予約済み領域の合計は、1 x 1.2 TB + 248 x 1 GB = 1.4 TB となります。The total reserved space for databases on the instance is 1 x 1.2 TB + 248 x 1 GB = 1.4 TB.

この例は、特定の状況下では特殊なファイルの配分が原因で、SQL Managed Instance のインスタンスが、想定していないときにアタッチ済み Azure Premium ディスク用に予約されている 35 TB の制限に到達する可能性があることを示しています。This example illustrates that under certain circumstances, due to a specific distribution of files, an instance of SQL Managed Instance might reach the 35-TB limit that's reserved for an attached Azure Premium Disk when you might not expect it to.

この例では既存のデータベースは引き続き機能し、新しいファイルを追加しない限りは問題なく拡張できます。In this example, existing databases continue to work and can grow without any problem as long as new files aren't added. すべてのデータベースの合計サイズがインスタンス サイズの上限に到達しない場合でも、新しいディスク ドライブ用の十分な領域がないため、新しいデータベースの作成や復元はできません。New databases can't be created or restored because there isn't enough space for new disk drives, even if the total size of all databases doesn't reach the instance size limit. その場合に返されるエラーは明確ではありません。The error that's returned in that case isn't clear.

システム ビューを使用して、残りのファイルの数を特定できます。You can identify the number of remaining files by using system views. この制限に達した場合は、DBCC SHRINKFILE ステートメントを使用して、より小さなファイルをいくつか空にして削除してみるか、この制限のない Business Critical レベルに切り替えてください。If you reach this limit, try to empty and delete some of the smaller files by using the DBCC SHRINKFILE statement or switch to the Business Critical tier, which doesn't have this limit.

データベース名の代わりに GUID 値が表示されるGUID values shown instead of database names

複数のシステム ビュー、パフォーマンス カウンター、エラー メッセージ、XEvent、およびエラー ログ エントリで、実際のデータベース名ではなく GUID データベース識別子が表示されています。Several system views, performance counters, error messages, XEvents, and error log entries display GUID database identifiers instead of the actual database names. 将来、実際のデータベース名に置き換えられるため、これらの GUID 識別子には依存しないでください。Don't rely on these GUID identifiers because they're replaced with actual database names in the future.

回避策:sys.databases ビューを使用して、実際のデータベース名を、GUID データベース識別子の形式で指定した物理データベース名から解決します。Workaround: Use sys.databases view to resolve the actual database name from the physical database name, specified in the form of GUID database identifiers:

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

エラー ログが非永続的であるError logs aren't persisted

SQL Managed Instance で利用可能なエラー ログは永続的ではなく、このログのサイズは、最大ストレージ上限には含まれません。Error logs that are available in SQL Managed Instance aren't persisted, and their size isn't included in the maximum storage limit. フェールオーバーが発生した場合、エラー ログは自動的に消去される可能性があります。Error logs might be automatically erased if failover occurs. SQL Managed Instance が複数の仮想マシンで複数回移動されたことが原因で、エラー ログの履歴に欠落部分が生じる可能性があります。There might be gaps in the error log history because SQL Managed Instance was moved several times on several virtual machines.

同じインスタンス内にある 2 つのデータベース上でトランザクション スコープがサポートされないTransaction scope on two databases within the same instance isn't supported

(2020 年 3 月に解決済み) TransactionScope クラス (.NET) は、同じトランザクション スコープ下では、同一インスタンス内にある 2 つのデータベースに対して 2 つのクエリが送信された場合に機能しません。(Resolved in March 2020) The TransactionScope class in .NET doesn't work if two queries are sent to two databases within the same instance under the same transaction scope:

using (var scope = new TransactionScope())
{
    using (var conn1 = new SqlConnection("Server=quickstartbmi.neu15011648751ff.database.windows.net;Database=b;User ID=myuser;Password=mypassword;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=mypassword;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) を使って、接続コンテキスト内で他のデータベースを使用します。Workaround (not needed since March 2020): Use SqlConnection.ChangeDatabase(String) to use another database in a connection context instead of using two connections.

CLR モジュールとリンク サーバーでローカル IP アドレスを参照できないことがあるCLR modules and linked servers sometimes can't reference a local IP address

SQL Managed Instance 内の CLR モジュールと、現在のインスタンスを参照しているリンク サーバーまたは分散クエリでは、ローカル インスタンスの IP を解決できないことがあります。CLR modules in SQL Managed Instance and linked servers or distributed queries that reference a current instance sometimes can't resolve the IP of a local instance. このエラーは一時的な問題です。This error is a transient issue.

回避策:可能であれば、CLR モジュールでコンテキスト接続を使用します。Workaround: Use context connections in a CLR module if possible.

更新プログラムUpdates

SQL Database の更新情報や機能強化の一覧については、SQL Database サービスの更新情報を参照してください。For a list of SQL Database updates and improvements, see SQL Database service updates.

すべての Azure サービスの更新情報や機能強化については、サービスの更新情報を参照してください。For updates and improvements to all Azure services, see Service updates.

コンテンツの改善への協力Contribute to content

Azure SQL のドキュメントに投稿するには、Docs 共同作成者ガイドに関する記事をご覧ください。To contribute to the Azure SQL documentation, see the Docs contributor guide.