问题[sql-server](dba)

我遇到一个问题，无法更改之前没有给我们带来任何问题的 CDC 表。

我们在 cdc 表上运行 alter 语句来向表中添加一列，现在我们开始面临与此相关的错误。

我们尝试运行的查询是

ALTER TABLE cdc.dbo_TABLE_NAME_CT 
    ADD processed BIT DEFAULT 0 NULL

现在返回以下错误

消息 2104，级别 16，状态 13，行 34
无法更改错误：8277，严重性：-1，状态：0。（参数：）。由于格式化过程中出现错误，因此以简洁模式打印错误。跳过跟踪、ETW、通知等。'dbo_TABLE_NAME'，因为您没有权限。

我正在使用 SQL Server 2016（v13.0.7045.2）。

在 13.0.7029 SQL 服务器上，我们能够运行 alter 命令，因此感觉好像某些内容已作为补丁的一部分发生更改。

该问题与此处的问题类似https://stackoverflow.com/questions/79075830/error-while-trying-to-alter-cdc-table-on-sql-server

这种情况已经突然在多个环境中发生，以前运行正常，我不确定是否作为新补丁的一部分发生了某些变化导致了这种情况。

我知道不建议更改 cdc 表，但这之前没有给我们带来任何问题。

我想知道是否有人对此有任何想法，因为我有点不确定该怎么办。

我不确定这是预期的行为还是错误——Microsoft 服务包中没有提到他们已采取某些措施来禁用向表中添加列的功能。

更重要的是，如果事情确实是这样发展的话，我们需要做出相应的调整，但现在我不知道为什么这个功能突然停止工作了。

假设我有以下两个数据库

USE [master]
CREATE DATABASE Jack
GO

CREATE DATABASE Jill
GO

USE Jack
GO
CREATE TABLE JacksTable
(
    Id INT
)
INSERT INTO JacksTable VALUES (1)

如果我在 Jack 数据库上下文中创建以下临时存储过程：

USE Jack
GO

CREATE PROC #Temp
AS
    SELECT  *
    FROM    JacksTable
GO

然后在Jack数据库中执行：

USE Jack
GO
EXEC #Temp

我得到了结果1

如果我在 Jill 数据库上下文中运行：

USE Jill
GO
EXEC #Temp

我明白了1

现在，如果我放弃这个程序

DROP PROC #Temp

并在 Jill 数据库上下文中再次创建该过程：

USE Jill
GO

CREATE PROC #Temp
AS
    SELECT  *
    FROM    JacksTable 
GO

然后运行它

USE Jill
GO    
EXEC #Temp

我收到错误

Msg 208, Level 16, State 1, Procedure #Temp, Line 4 [Batch Start Line 74]
Invalid object name 'JacksTable'.

如果我尝试从 Jack 数据库执行它：

USE Jack
GO
EXEC #Temp

我明白了

Msg 208, Level 16, State 1, Procedure #Temp, Line 4 [Batch Start Line 74]
Invalid object name 'JacksTable'.

如果我放弃这个程序

DROP PROC #Temp

再次在 Jill 数据库上下文中重新创建

USE Jill
GO

CREATE PROC #Temp
AS
    SELECT  *
    FROM    JacksTable 
GO

这次从 Jack 数据库运行

USE Jack
GO
EXEC #Temp

我得到了同样的绑定错误

Msg 208, Level 16, State 1, Procedure #Temp, Line 4 [Batch Start Line 74]
Invalid object name 'JacksTable'.

这告诉我 SQL Server 尝试将临时过程中的对象绑定到创建临时存储过程时的上下文中的数据库。

这篇文章建议

首次执行存储过程时，查询处理器从 sys.sql_modules 目录视图中读取存储过程的文本，并检查该过程使用的对象名称是否存在。

这项检查针对哪个数据库执行？我认为是 tempdb，因为临时存储过程定义保存在该数据库中？如果是这样，那么该解决方案在所有情况下都会失败（除非我们在 tempdb 中创建了表），因此不可能是那样。

根据我上面看到的内容，它似乎是在创建临时存储过程时处于范围内的数据库（而不是对象定义持久化的数据库 - tempdb）。但是，如果确实如此，SQL Server 如何知道它是哪个数据库以及它存储在哪里？我检查了sys.sql_expression_dependencies、和sys.sql_modules，但似乎没有一个有这些信息sys.objectssys.procedures

我正在创建一个名为 TestArticles 的分区表，根据发布年份 (publishDate) 指定多个文件组。此代码（不包括注释部分）执行正确。我的任务是向“哈希”字段添加唯一索引。当我尝试在表创建代码中执行此操作时，我收到以下错误：

“列‘publishDate’是索引‘UQ_Articles_hash’的分区列。唯一索引的分区列必须是索引键的子集。”

我可以从（id、publishDate、hash）创建一个复合主键 - 但这不是我的要求。

有没有办法将哈希指定为每个创建的文件组的唯一索引，或者在初始化整个表时将其指定为唯一索引？

USE Articles;
GO

ALTER DATABASE Articles
ADD FILEGROUP Articles2024;

ALTER DATABASE Articles
ADD FILEGROUP Articles2025;

ALTER DATABASE Articles
ADD FILEGROUP Articles2026;

ALTER DATABASE Articles
ADD FILEGROUP Articles2027;


CREATE PARTITION FUNCTION PF_Articles_PublishDate (DATETIME)
AS RANGE RIGHT FOR VALUES 
(
'2024-01-01', 
'2025-01-01',
'2026-01-01'
);

CREATE PARTITION SCHEME PS_Articles_PublishDate
AS PARTITION PF_Articles_PublishDate
TO 
(
Articles2024,
Articles2025,
Articles2026,
Articles2027
);

CREATE TABLE TestArticles (
    id INT NOT NULL,
    path VARCHAR(200) NULL,
    description VARCHAR(100) NOT NULL,
    publishDate DATETIME NOT NULL,
    hash BIGINT NOT NULL,
    authorId INT NOT NULL,
    CONSTRAINT PK_Articles PRIMARY KEY CLUSTERED (id, publishDate),
    CONSTRAINT FK_Articles_Authors FOREIGN KEY (authorId) REFERENCES dbo.Authors(id)
    --,CONSTRAINT UQ_Articles_hash UNIQUE NONCLUSTERED (hash)
) ON PS_Articles_PublishDate (publishDate);

数据库：MS SQL Server 2022 版本：16.0.1000.6 错误详情：消息 1908；级别 16；状态 1。

这篇文章延续了表分区设计的建议。

我尝试过截断旧分区并合并它。但我收到错误“为表‘dbo.STYTOTAL_RAW’指定的分区号 8 无效，分区号范围为 1 到 6。”看起来一旦合并，while 循环对于最大分区号就变得无效。

为了测试我使用了 3 天，但最初的要求是删除超过 90 天的分区。

按照@DanGuzman 的说法，也添加了 PF。完整脚本可用。在我的第一个帖子中。我也已将其链接到此帖子的顶部。

--Create function, copy from your script
CREATE PARTITION FUNCTION PF_myDateRange ( [datetime2](7))
AS RANGE RIGHT FOR VALUES 
(
'2024-06-01 23:59:59.9999999',
'2024-07-01 23:59:59.9999999',
'2024-08-01 23:59:59.9999999',
'2024-09-01 23:59:59.9999999',
'2024-10-01 23:59:59.9999999',
'2024-10-21 23:59:59.9999999' -- take the max day and round with 12 AM ex: 2024-10-21 00:00:00.0000000
)
GO
use DB_Partition

--Invalid partition number 8 specified for table 'dbo.STYTOTAL_RAW', partition number can range from 1 to 6.

-- We can loop through the partition number directly from the table
--TRUNCATE TABLE [STYTOTAL_RAW] WITH (PARTITIONS (4));

declare @cmd_1 nvarchar(max)
declare @cmd_2 nvarchar(max)
DECLARE @partition_no bigint
DECLARE @PartitionFunction_name nvarchar(128)
DECLARE @PartitionFunction_Upper_value datetime2(7)
DECLARE @minrow int
DECLARE @maxrow int


select  @minrow = MIN(p.partition_number), @maxrow  = MAX(p.partition_number)
    from sys.indexes i  
    join sys.partitions p ON i.object_id=p.object_id AND i.index_id=p.index_id  
    join sys.partition_schemes ps on ps.data_space_id = i.data_space_id  
    join sys.partition_functions pf on pf.function_id = ps.function_id  
    left join sys.partition_range_values rv on rv.function_id = pf.function_id AND rv.boundary_id = p.partition_number
    join sys.allocation_units au  ON au.container_id = p.hobt_id   
    join sys.filegroups fg  ON fg.data_space_id = au.data_space_id  
    where i.object_id = object_id('STYTOTAL_RAW') 
    and rv.value < DATEADD(DAY, -3, SYSDATETIME()) 
    

select @minrow,@maxrow


while (@minrow <=@maxrow)
 begin

select  @partition_no=partition_number,@PartitionFunction_name=pf.name,@PartitionFunction_Upper_value=cast(rv.value as datetime2(7))
    from sys.indexes i  
    join sys.partitions p ON i.object_id=p.object_id AND i.index_id=p.index_id  
    join sys.partition_schemes ps on ps.data_space_id = i.data_space_id  
    join sys.partition_functions pf on pf.function_id = ps.function_id  
    left join sys.partition_range_values rv on rv.function_id = pf.function_id AND rv.boundary_id = p.partition_number
    join sys.allocation_units au  ON au.container_id = p.hobt_id   
    join sys.filegroups fg  ON fg.data_space_id = au.data_space_id  
    where i.object_id = object_id('STYTOTAL_RAW') 
    and rv.value < DATEADD(DAY, -3, SYSDATETIME()) 
    and p.partition_number = @minrow



SET @cmd_1 = N'TRUNCATE TABLE dbo.STYTOTAL_RAW WITH (PARTITIONS (' + convert(NVARCHAR(128),@partition_no) + N'));'
print @cmd_1
--EXEC sys.sp_executesql @cmd_1
SET @cmd_2 = N'ALTER PARTITION FUNCTION ['+ @PartitionFunction_name+ '] () merge range ('''+convert (NVARCHAR(128), @PartitionFunction_Upper_value) +''');'


print @cmd_2
--EXEC sys.sp_executesql @cmd_2

set @minrow =@minrow +1 
end

请提出任何建议。感谢您的帮助。

安装 SQL Server 2019 时，也会同时安装 ODBC 驱动程序，而 MSSQL 似乎对其有很强的依赖性。是否可以重新配置 MSSQL 以使用较新版本的 ODBC 驱动程序并删除旧版本？我们的第三方漏洞管理扫描程序正在标记较旧版本的 ODBC 驱动程序，但似乎没有办法彻底修复这些发现。

截至本文撰写时的详细信息：

• 我正在使用的服务器正在运行 SQL Server 2019 开发人员版本
• 它在 Windows Server 2019 标准版 VM 上运行
• 此 SQL 服务器的版本为 15.0.4405.4 (CU29)
• 在安装 CU29 之前，此服务器位于 CU27
• 安装的 ODBC 版本是 17.10.6.1
• 所有组件都是 x64，而不是 x86

故障排除/分析：

• 从 CU27 更新到 CU29 并未更新 ODBC 驱动程序的版本
• 我可以手动安装较新版本的 ODBC 驱动程序（18.4.1.1），它将与 17.10.6.1 和平共处，但不会清除漏洞
• 如果我删除 17.10.6.1 来清除漏洞，SQL Server Agent 将无法启动（事件查看器：服务未及时响应启动或控制请求）
• 重新安装 ODBC 17.10.6.1 可以解决问题并允许代理启动 - 但漏洞再次出现
• 在安装 v18.x 驱动程序后修复 SQL Server 只会将 ODBC 驱动程序重新安装到较早的主要版本 (17.xxx)，这同样不合规，并且仍然会触发我们的漏洞扫描结果
• 目前似乎还没有 ODBC 17 的新版本，因为 MS 似乎没有同时开发和发布 17.x 和 18.x 的新版本。他们似乎在催促我们使用 v18，但它与 SQL 2019 Agent 配合得并不好。

要点：

• 看来 MSSQL 2019 对 SQL 2019 的 ODBC 驱动程序版本 17 有硬依赖性
• CU 似乎尚未更新这些驱动程序 - 如果有的话
• 似乎没有办法通过 SSMS/UI 重新配置/调整 MSSQL 2019 以使用较新的 ODBC 驱动程序主要版本（例如 18.x）
• 我尚未调查过 Windows 系统注册表编辑
• 无论我在实例构建时安装了哪些组件，这些驱动程序都会被安装，因此最小化我的表面积似乎没有帮助（我将此实例与执行了最小安装的另一个 2019 实例进行了比较 - 它们都有相同的 ODBC 驱动程序。）

问题：

• 这里有没有人遇到过同样的问题？我可以采取什么步骤让 MSSQL 看到/使用较新的 ODBC 驱动程序？
• ODBC 驱动程序更新会随 CU 一起推送吗，还是我需要通过官方 MS 下载手动更新它们？

任何建议/指导都值得赞赏。谢谢。

我知道 Liberatii 软件，它是一种网关，允许您在后台使用 PostgreSQL（甚至其他引擎），而无需重写为 Oracle 编写的应用程序。你们当中有人知道是否有像 Liberatii 一样在后台用 PostgreSQL 模拟 SQL Server 的软件吗？我们尝试找到性能问题的解决方案，其中一种可能性是切换到 Oracle 或 Postgres 引擎，但应用程序模块包含大量需要重写的自定义代码，我评估了所有可能的解决方案。

SQL Server 2017 对显示计划进行了非常有用的增强，可以查看哪些统计数据用于生成计划：https://learn.microsoft.com/en-nz/archive/blogs/sql_server_team/sql-server-2017-showplan-enhancements

但是，我在执行计划中找不到它。我在 StackOverflow 数据库上有以下查询：

Use StackOverflow2010;

DROP TABLE IF EXISTS #tempPosts;
CREATE TABLE #tempPosts(
    Id int
)

INSERT INTO #tempPosts
SELECT ID FROM dbo.Posts
WHERE OwnerUserId = 26837

SELECT Title, u.DisplayName, pt.Type FROM dbo.Posts p
INNER JOIN #tempPosts temp
ON p.Id = temp.Id
INNER JOIN dbo.Users u
ON p.OwnerUserId = u.Id
INNER JOIN dbo.PostTypes pt
ON p.PostTypeId = pt.Id
OPTION(RECOMPILE)

我打开了Include Actual Execution Plan捕获计划但无法OptimizerStatsUsage在计划中找到字段：

什么原因导致OptimizerStatsUsage我的执行计划中没有显示？是否需要任何其他配置或步骤才能看到此属性？

感谢您的任何见解！

我有以下执行计划：

如您所见，Clustered Index ScanandIndex Seek运算符的行估计是准确的。然而，嵌套循环连接存在显著差异：实际行数为 6,420，而估计行数只有 72。

我的问题是：

1. 如何估算 SQL Server 中嵌套循环连接的行数？
2. 在这种情况下，哪些因素可能导致行估计如此不准确？
3. 我能做些什么来改善或修正这个估计吗？

感谢您的任何见解！

使用事务复制，加密数据库（TDE 加密）是否可以毫无问题地复制到未加密目标？

看来我对查询计划的理解不正确。如果我第一次运行此查询并检查查询计划缓存。我会看到一个缓存的计划。

declare @codes varchar(max)='BHVD7,BHVDE,BHVDF'
SELECT OFST010020 AS [OFST010020], OFST730010 AS [OFST730010], Identifier AS [Identifier]   FROM STATIC_FUNDSHARECLASSUNIT_NEXT as f WITH(NOLOCK)  Inner join STATIC_FUNDSHARECLASSUNITEXTENSION_NEXT as fex WITH(NOLOCK) on fex.Identifier2 = f.Identifier    WHERE OFST900174 in (select value from string_split(@codes,','))

如果我只是更改代码参数并在同一个 SSMS 窗口中再次运行查询，例如

declare @codes varchar(max)='BHVD7,BHVDF'
SELECT OFST010020 AS [OFST010020], OFST730010 AS [OFST730010], Identifier AS [Identifier]   FROM STATIC_FUNDSHARECLASSUNIT_NEXT as f WITH(NOLOCK)  Inner join STATIC_FUNDSHARECLASSUNITEXTENSION_NEXT as fex WITH(NOLOCK) on fex.Identifier2 = f.Identifier    WHERE OFST900174 in (select value from string_split(@codes,',')) 

我以为查询计划会有 1 行，useCount 为 2。但在查询计划缓存中，我实际上看到了两个计划。每个计划的 sql 文本实际上是全文（以声明 @codes 开头）。我做错了什么吗？还是 ad hoc 查询实际上并没有重用计划，即使涉及参数？