我想知道为什么 SQL Server 在如此简单的情况下会做出错误的估计。有一个场景。
CREATE PARTITION FUNCTION PF_Test (int) AS RANGE RIGHT
FOR VALUES (20140801, 20140802, 20140803)
CREATE PARTITION SCHEME PS_Test AS PARTITION PF_Test ALL TO ([Primary])
CREATE TABLE A
(
DateKey int not null,
Type int not null,
constraint PK_A primary key (DateKey, Type) on PS_Test(DateKey)
)
INSERT INTO A (DateKey, Type)
SELECT
DateKey = N1.n + 20140801,
Type = N2.n + 1
FROM dbo.Numbers N1
cross join dbo.Numbers N2
WHERE N1.n BETWEEN 0 AND 2
and N2.n BETWEEN …用户数据库上的 DBCC CHECKDB 返回此错误
Msg 8992, Level 16, State 1, Line 1
Check Catalog Msg 3851, State 1: An invalid row (class=128,depid=65536,depsubid=0) was found in the system table sys.syssingleobjrefs (class=128).
此错误出现在用户数据库中，而不是出现在master! 当人们尝试检查在不同服务器上恢复的主数据库时，互联网上充满了专门讨论此错误的文章。事实并非如此。
我尝试了所有常用的魔法，但没有成功。
DBCC CHECKDB WITH ALL_ERRORMSGS, NO_INFOMSGS
--error
ALTER DATABASE DBCopy SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DBCC CHECKDB (DBCopy, REPAIR_ALLOW_DATA_LOSS)
--output reports the same error
DBCC CHECKDB WITH ALL_ERRORMSGS, NO_INFOMSGS
--error
--no hope but just in case
ALTER DATABASE DBCopy SET EMERGENCY
DBCC CHECKDB (DBCopy, REPAIR_ALLOW_DATA_LOSS)
--the …这是一个奇怪的场景。事务日志已满。它等待AG。AG一切都好。无延迟，最后提交/硬化时间在所有节点上几乎都是实时的。预计恢复时间为零。我也从主节点和辅助节点检查了这一点（以防仪表板未更新）。此页面仅列出了此错误的两个原因：传递延迟和重做延迟。没有任何内容适用于我的系统。如何进一步解决这个问题？
编辑 1。我们对环境所做的唯一更改是添加了两个 SQL Server 2019 节点以准备迁移。但它不应该出现这样的问题。
编辑2。我发现的唯一解决方法是将数据库重新添加到AG。