当一个数据库完全包含时,它的所有对象都在数据库边界内。它也在数据库级别管理连接。包含的数据库
我有几个问题:
如果我在 Azure SQL Single DB 中托管包含的数据库,那么 Azure SQL 单一数据库和包含的数据库作为 Azure SQL 单一数据库有什么区别?
为什么我们有一个单独的产品作为 Azure SQL Single Db,当包含的数据库也类似于它时?
将数据库作为包含数据库是否有助于更轻松地迁移到 Azure SQL 单一数据库?
当一个数据库完全包含时,它的所有对象都在数据库边界内。它也在数据库级别管理连接。包含的数据库
我有几个问题:
如果我在 Azure SQL Single DB 中托管包含的数据库,那么 Azure SQL 单一数据库和包含的数据库作为 Azure SQL 单一数据库有什么区别?
为什么我们有一个单独的产品作为 Azure SQL Single Db,当包含的数据库也类似于它时?
将数据库作为包含数据库是否有助于更轻松地迁移到 Azure SQL 单一数据库?
在 Azure 中,“单一”是一种部署选项,可将 Azure SQL 数据库与托管池和弹性池区分开来。从包容的角度来看确实没有区别,因为 Single 和 Azure SQL 数据库是一回事。
Azure SQL 数据库固有地提供了包含功能,例如数据库级用户身份验证。对于本地 SQL Server 数据库,必须选择加入CONTAINMENT=PARTIAL
以允许数据库级身份验证。
将数据库作为包含数据库是否有助于更轻松地迁移到 Azure SQL 单一数据库?
CONTAINMENT=PARTIAL
允许在本地版本中进行数据库级身份验证,从而促进数据库安全主体的迁移。只要用户数据库实体保持在数据库边界内并且不需要包含数据库(例如 CDC)中不可用的功能,迁移通常很容易。
但是,需要考虑的是,部分包含的数据库隐式使用目录排序规则Latin1_General_100_CI_AS_KS_WS_SC
,而 Azure SQL 数据库目录排序规则必须是所选DATABASE_DEFAULT
排序规则或SQL_Latin1_General_CP1_CI_AS
. 这通常只有在需要对象/变量名称区分大小写时才会成为问题。
可以通过查询来识别现有的未包含引用sys.dm_db_uncontained_entities
:
SELECT * FROM sys.dm_db_uncontained_entities;
上述查询还将识别需要手动检查的动态 SQL 引用。