Azure SQL 数据库和 SQL 托管实例中的新增功能有哪些?What's new in Azure SQL Database & SQL Managed Instance?

适用于:是 Azure SQL 数据库 是Azure SQL 托管实例 APPLIES TO: yesAzure SQL Database yesAzure SQL Managed Instance

本文列出了当前以公共预览版形式提供的 Azure SQL 数据库和 Azure SQL 托管实例的功能。This article lists Azure SQL Database and Azure SQL Managed Instance features that are currently in public preview.

新增功能What's new?

Azure SQL 数据库和 Azure SQL 托管实例的相关文档已拆分为单独的部分。Documentation for Azure SQL Database and Azure SQL Managed Instance has been split into separate sections. 我们还将托管实例的指代方式从“Azure SQL 数据库托管实例”更新为“Azure SQL 托管实例” 。We've also updated how we refer to a managed instance from Azure SQL Database managed instance to Azure SQL Managed Instance.

这样做是因为单一数据库与托管实例之间的某些特性和功能存在极大的出入,并且越来越难以在同时介绍二者的单个文章中解释清楚 Azure SQL 数据库和 Azure SQL 托管实例之间的细微差别。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 数据库中的单个托管数据库、Azure SQL 托管实例中托管多个数据库的功能完善的托管实例还是托管在 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. 例如,有关 Transact-SQL (T-SQL) 语句、存储过程以及 Azure SQL 数据库与 Azure 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 托管实例Azure SQL Managed Instance Azure SQL 数据库托管实例Azure SQL Database managed instance Azure SQL 托管实例是 Azure SQL 的系列产品之一,而不只是 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 数据库Azure SQL Database Azure SQL 数据库单一数据库Azure SQL Database single database 除非另有明确说明,否则产品名称 Azure SQL 数据库的含义将同时涵盖单一数据库和部署到弹性池的数据库。Unless explicitly specified otherwise, the product name Azure SQL Database includes both single databases and databases deployed to an elastic pool.
Azure SQL 数据库Azure SQL Database Azure SQL 数据库弹性池Azure SQL Database elastic pool 除非另有明确说明,否则产品名称 Azure SQL 数据库的含义将同时涵盖单一数据库和部署到弹性池的数据库。Unless explicitly specified otherwise, the product name Azure SQL Database includes both single databases and databases deployed to an elastic pool.
Azure SQL 数据库Azure 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 VM 上的 Azure SQL 数据库、Azure SQL 托管实例和 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
通过单一数据库和弹性池加速的数据库恢复Accelerated database recovery with single databases and elastic pools 有关信息,请参阅加速的数据库恢复For information, see Accelerated Database Recovery.
数据发现和分类Data discovery & classification 有关详细信息,请参阅 Azure SQL 数据库和 Azure Synapse Analytics 数据发现和分类For information, see Azure SQL Database and Azure Synapse Analytics data discovery & classification.
弹性数据库作业(预览版)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 门户中的查询编辑器Query editor in the Azure portal 有关信息,请参阅使用 Azure 门户的 SQL 查询编辑器进行连接并查询数据For information, see Use the Azure portal's SQL query editor to connect and query data.
 

SQL 托管实例新增功能和已知问题SQL Managed Instance new features and known issues

SQL 托管实例 H2 2019 更新SQL Managed Instance H2 2019 updates

SQL 托管实例 H1 2019 更新SQL Managed Instance H1 2019 updates

在 H1 2019 的 SQL 托管实例部署模型中启用了以下功能:The following features are enabled in the SQL Managed Instance deployment model in H1 2019:

已知问题Known issues

问题Issue 发现日期Date discovered 状态Status 解决日期Date resolved
服务主体无法访问 Azure AD 和 AKVService 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 托管实例Permissions on resource group not applied to SQL Managed Instance 2020 年 2 月Feb 2020 具有解决方法Has Workaround
通过门户对故障转移组进行手动故障转移的限制Limitation of manual failover via portal for failover groups 2020 年 1 月Jan 2020 具有解决方法Has Workaround
SQL 代理角色需要拥有对非 sysadmin 登录名的显式 EXECUTE 权限SQL Agent roles need explicit EXECUTE permissions for non-sysadmin logins 2019 年 12 月Dec 2019 具有解决方法Has Workaround
重启代理进程可能会中断 SQL 代理作业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
升级服务层级后必须重新初始化跨数据库 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 无解决方法No Workaround
异地故障转移之后,必须重新配置事务复制Transactional Replication must be reconfigured after geo-failover 2019 年 3 月Mar 2019 无解决方法No Workaround
在还原操作过程中使用临时数据库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
跨同一实例中的两个数据库的事务范围不受支持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 存储还原数据库后未使用 DBCC CHECKDB 验证数据库一致性。Database consistency not verified using DBCC CHECKDB after restore database from Azure Blob Storage. 已解决Resolved 2019 年 11 月Nov 2019
如果源数据库包含内存中 OLTP 对象,则从“业务关键”层级到“常规用途”层级的时间点数据库还原将不会成功。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 托管实例不支持包含的数据库Contained databases not supported in SQL Managed Instance 已解决Resolved 2019 年 8 月Aug 2019

服务主体无法访问 Azure AD 和 AKVService 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. 此问题最终会对使用 Azure AD 身份验证和 SQL 托管实例的透明数据库加密 (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 托管实例上使用客户托管密钥设置 TDE 也可能不起作用。Setting up TDE with customer-managed key on a new Azure SQL Managed Instance might also not work in some circumstances.

解决方法:为了防止在执行任何更新命令之前 SQL 托管实例出现此问题,或者你已在更新命令后遇到此问题,请转到 Azure 门户,访问 SQL 托管实例“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。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 托管实例Permissions on resource group not applied to SQL Managed Instance

将 SQL 托管实例参与者 Azure 角色应用于资源组 (RG) 时,该角色不应用于 SQL 托管实例,因此不起作用。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 托管实例参与者”角色。Workaround: Set up a SQL Managed Instance Contributor role for users at the subscription level.

通过门户对故障转移组进行手动故障转移的限制Limitation of manual failover via portal for failover groups

如果故障转移组跨不同资源组中的实例,则无法从故障转移组中的主实例启动手动故障转移。If a failover group spans across instances in different resource groups, manual failover cannot be initiated from the primary instance in the failover group.

解决方法:通过门户从异地辅助实例启动故障转移。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 代理固定数据库角色,则会出现以下问题:需要向主存储过程授予显式 EXECUTE 权限才能使这些登录名正常工作。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. 如果遇到此问题,将显示错误消息“在对象 <object_name> 中拒绝了 EXECUTE 权限(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 代理固定数据库角色(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 代理在每次启动作业时都会新建一个会话,从而逐渐增加内存消耗。(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

在某些情况下,业务关键服务无法正确应用内存优化对象的最大内存限制The Business Critical service tier will not correctly apply max memory limits for memory-optimized objects in some cases. SQL 托管实例可以让工作负荷使用更多的内存进行内存中 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. 提高基于 vCore 数的内存限制,或者优化工作负荷,让其使用较少的内存。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 托管实例不允许用户删除不为空的文件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 托管实例会继续尝试删除该文件,操作会在 30 分钟后失败并显示 Internal server errorSQL 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.

升级服务层级后必须重新初始化跨数据库 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 托管实例中对 vCore 或实例存储大小进行任何更改都会导致 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 USEREXECUTE 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. 在这种情况下,将返回以下错误:15517The 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. 在这种情况下,将返回以下错误:1551715406The 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.

异地故障转移之后,必须重新配置事务复制Transactional Replication must be reconfigured after geo-failover

如果对自动故障转移组中的数据库启用了事务复制,则 SQL 托管实例管理员必须清理旧的主节点上的所有发布内容,然后在故障转移到另一个区域后,在新的主节点上重新配置这些发布内容。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.

在还原操作过程中使用临时数据库Temporary database is used during RESTORE operation

在 SQL 托管实例上还原某个数据库时,还原服务首先会使用所需的名称创建一个空数据库,以便在实例上分配该名称。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. 当还原服务启动第二个阶段时,将删除此临时数据库。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. 无法更改每个文件的最大大小,并且无法将新文件添加到 tempdbThe 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

CREATE DATABASEALTER DATABASE ADD FILERESTORE DATABASE 语句可能会失败,因为实例可能会达到 Azure 存储限制。CREATE DATABASE, ALTER DATABASE ADD FILE, and RESTORE DATABASE statements might fail because the instance can reach the Azure Storage limit.

每个 SQL 托管实例的常规用途实例都为 Azure 高级磁盘空间保留了最多 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 高级磁盘大小总计不能超过 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 的托管实例可能会超过 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 托管实例的常规用途实例可将一个大小为 1.2 TB 的大文件放在 4 TB 的磁盘上。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. 它还可以将 248 个文件(每个大小为 1 GB)放在单独的 128 GB 磁盘上。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 托管实例的实例可能会出乎意料地达到为附加的 Azure 高级磁盘预留的 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 语句来清空并删除一些较小的文件,或切换到没有此限制的业务关键层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 托管实例中可用的错误日志不会持久保留,并且它们的大小不包括在最大存储限制中。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 托管实例在多个虚拟机上转移了多次。There might be gaps in the error log history because SQL Managed Instance was moved several times on several virtual machines.

跨同一实例中的两个数据库的事务范围不受支持Transaction scope on two databases within the same instance isn't supported

(2020 年 3 月已解决)如果两个查询被发送到同一事务范围下相同实例内的两个数据库,那么 .Net 中的 TransactionScope 类就无法正常运行:(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.chinacloudapi.cn;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.chinacloudapi.cn;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 月起不再需要) :使用 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 托管实例中的 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.

参与内容制作Contribute to content

若要参与 Azure SQL 文档制作,请参阅文档参与者指南To contribute to the Azure SQL documentation, see the Docs contributor guide.