Definite's questions

我正在使用 SSDT 创建一个包含 CLR 用户定义聚合的数据库。

聚合旨在位于不同的模式中。如果不使用部署后脚本在部署后移动对象，SSDT 中的 CLR 对象就不可能做到这一点。

我正在尝试做的是：

• 使用“默认模式”选项在单个模式（“CLR”模式）中创建 CLR 聚合
• 在所需架构中使用 CREATE AGGREGATE 包装器来调用 CLR 聚合

例如，我有一个 CLR 聚合，例如：

[Serializable]
[Microsoft.SqlServer.Server.SqlUserDefinedAggregate(Format.UserDefined, MaxByteSize = -1)]
public struct StatsEntropy : IBinarySerialize
{
 ... etc
}

这被编译并成为数据库中的 CLR.StatsEntropy。该数据库称为 AnalysisFunctions，因此它有一个也称为 AnalysisFunctions 的程序集。这没有问题。

然后我在 Stats 模式中创建一个包装器，如下所示：

CREATE AGGREGATE [Stats].[Entropy]
(
    @Values FLOAT
)
RETURNS FLOAT
EXTERNAL NAME AnalysisFunctions.StatsEntropy

当我通过调试构建时，这可以正常工作。我将调试连接设置为 SQL Server 的命名实例。如果我按 F5，它将毫无问题地编译和部署。该代码现在可以在服务器上使用，包括包装器。

但是，如果我尝试使用 Publish 发布到服务器，它就不起作用。相反，它失败了：

对目标数据库建模时发生错误。部署无法继续。

数据工具操作面板或错误列表中没有更多错误消息。ssdttrace 没有显示有用的信息：

这只发生在数据库已经存在于服务器上时。如果我删除数据库，它可以成功部署。即使数据库已经存在，我也可以通过调试成功部署，只有通过发布才会出现问题。直到我添加了聚合包装器，我才开始遇到这个问题。

以前我也收到错误，表明由于使用外部名称，程序集 AnalysisFunctions 有一个未解析的引用 - 再次通过调试工作，而不是通过发布工作。但现在这个错误已经神秘地消失了。

我正在使用 Visual Studio 2017 15.9.21 和 SSDT 15.1.62002.01090，部署到 SQL Server 2019。

有谁知道这个错误可能是什么，或者我如何调试它？

我正在尝试将内存优化文件组添加到 SSDT 中的 SQL 服务器数据库项目。这适用于使用 Visual Studio 2017 的 SQL Server 2017。

但是编译项目（按 F5 构建）会导致错误。部署时不会发生此错误（通过部署）。

文件组正常创建（使用 SSDT 编写的 SQLCMD 变量）：

ALTER DATABASE [$(DatabaseName)]
ADD FILEGROUP [MemoryOptimizedFilegroup] CONTAINS MEMORY_OPTIMIZED_DATA

但是，这会导致错误：

具有 MEMORY_OPTIMIZED_DATA 文件组的数据库不支持操作“AUTO_CLOSE”。

但是，数据库设置显示确实禁用了自动关闭：

SSDT 出于某种原因生成的部署脚本正在创建数据库，创建文件组，然后仅将 AUTO_CLOSE 设置为关闭。这可能会导致错误：

CREATE DATABASE [$(DatabaseName)]
ON 
PRIMARY(NAME = [$(DatabaseName)], FILENAME = N'$(DefaultDataPath)$(DefaultFilePrefix)_Primary.mdf')
LOG ON (NAME = [$(DatabaseName)_log], FILENAME = N'$(DefaultLogPath)$(DefaultFilePrefix)_Primary.ldf') COLLATE SQL_Latin1_General_CP1_CI_AS
GO
PRINT N'Creating [MemoryOptimizedFilegroup]...';

GO
ALTER DATABASE [$(DatabaseName)]
    ADD FILEGROUP [MemoryOptimizedFilegroup] CONTAINS MEMORY_OPTIMIZED_DATA;

GO
ALTER DATABASE [$(DatabaseName)]
    ADD FILE (NAME = [MemoryOptimizedFilegroup_69323650], FILENAME = N'$(DefaultDataPath)$(DefaultFilePrefix)_MemoryOptimizedFilegroup_69323650.mdf') TO FILEGROUP [MemoryOptimizedFilegroup];

GO
USE [$(DatabaseName)];

GO
IF EXISTS (SELECT 1
    FROM   [master].[dbo].[sysdatabases]
    WHERE  [name] = N'$(DatabaseName)')
BEGIN
    ALTER DATABASE [$(DatabaseName)]
        SET ANSI_NULLS ON,
            ANSI_PADDING ON,
            ANSI_WARNINGS ON,
            ARITHABORT ON,
            CONCAT_NULL_YIELDS_NULL ON,
            NUMERIC_ROUNDABORT OFF,
            QUOTED_IDENTIFIER ON,
            ANSI_NULL_DEFAULT ON,
            CURSOR_DEFAULT LOCAL,
            CURSOR_CLOSE_ON_COMMIT OFF,
            AUTO_CREATE_STATISTICS ON,
            AUTO_SHRINK OFF,
            AUTO_UPDATE_STATISTICS ON,
            RECURSIVE_TRIGGERS OFF 
        WITH ROLLBACK IMMEDIATE;
    ALTER DATABASE [$(DatabaseName)]
        SET AUTO_CLOSE OFF 
        WITH ROLLBACK IMMEDIATE;
END

我不确定在 CREATE DATABASE 之后是默认启用还是禁用 AUTO_CLOSE。如果默认为 ON，则 SSDT 似乎以错误的顺序生成部署脚本。如果默认关闭，那么我不明白为什么会出现错误。

有没有人在 SSDT 项目中成功创建内存优化文件组？

我收到错误 666：

超出了系统为重复组生成的最大唯一值。

我在 Azure SQL 托管实例上遇到过这种情况。

但是，我不应该收到此错误。有问题的索引是bigint identity列上的聚集主键。所以没有重复项，也不应该是唯一化符。

该表开始为空，当前标识为零。我试图插入 29 亿条记录，让 SQL Server 分配标识键。收到错误666后，当前ident为2147483648。

这对我来说毫无意义，因为 uniquifier 应该只用于包含重复值的非唯一聚集索引。我的桌子不符合这些条件。

有人有什么想法吗？

使用INSERT INTO SELECT FROM ORDER BY查询插入记录。除标识列本身外，所有列均已指定。我绝对确定标识列的数据类型是BIGINT.

源表是一个没有标识或聚簇索引的堆表，因此bigint那里不存在相关列。bigint identity除了添加列/聚集主键外，目标表与源表具有重复定义。

我将所有记录从源表插入到目标表，在列列表/选择列表中指定源表中的所有列以进行插入。该bigint列未在插入中指定，因为它只是目标端的标识列。

我有一个想法，首先用一个唯一的 id 列（如行号）预填充我的源堆表，identity_insert在目标表上启用并尝试一次 100m 的批量插入。那行得通吗？

每次此查询失败都需要 15 个小时才能回滚。

在所需的插入顺序中，堆表上有一个 NCI，但它不包括所有列，因此会发生书签查找。如果我在加载期间对目标表进行未提交的读取，我可以看到标识不断增加的记录。

我看到的最后一个执行计划是表扫描，然后是排序。