我在 MSSQL 2019 Enterprise CU1 之上安装了全新的 SQL Server Reporting Services 2019。除了应使用的服务帐户外，SSRS 已使用默认设置进行安装和配置。AD 和 MSSQL 实例都仅以最低权限配置（或接近此状态）。当我访问 Web 门户时，我收到一条错误消息，提示“请稍后再试”，这没有多大帮助。我发现许多类似的帖子就同一问题寻求帮助，但想在这里看到答案。
今天我尝试对 50M+ 行执行更新操作，例如：
UPDATE [table] SET [Column] += 1;
等待 30 分钟后，我看到日志已开始自行填充，再过 30 分钟后，由于日志已满，整个事务回滚。DB 处于简单恢复模式，但这毫无意义，因为这是作为单个事务完成的。SQL Server 本身无法预测它会使用整个日志大小（可以说它为此被锁定了大小），但是我向您提问，亲爱的有经验的 DBA - 您能预测这个大小吗？有没有办法计算这样的估计？
更新：
是的，我了解这个过程，我知道我可以批量处理，我也知道如何让它表现良好。我真正的问题是日志大小将有多大？您将如何计算简单表的更新，例如：
CREATE TABLE [TABL] ([ID] int identity(1,1) PRIMARY KEY CLUSTERED, [X] int not null);
INSERT INTO [TABL] VALUES(1)
GO 1000
UPDATE [TABL]
SET [X] = 2;
在我的测试盒上，操作的更新部分是 6 页大 = 48KB。当我对 10k 行重复相同的操作时，我收到了 144 页的事务日志。对于 100k 行，它是 1314 页，对于 1M，它是 13970 页。这表明我们可以将其视为线性函数（因为我们有额外的页面，无论如何都必须存在，无论我们是否更新任何内容 --> 2-3 页）。
回到开始，我知道我可以在总操作的 5% 上运行一个批处理，检查页面 chenge 内容（如Paul Randal 的博客）：
DECLARE @Extent_ID INT;
DECLARE @Size_Total …