标签: sql-server-2017

我们要计算表中每一行的总“行上”存储字节数。正如我们所理解的，我们必须将每一列的 DATALENGTH() 相加，同时还要考虑 NULL 和诸如 VARCHAR(MAX) 之类的东西，它们在“行”上只有一个 24 字节的指针。我们知道每一行也有一些开销，这在下面的查询中没有考虑。

SELECT   ROW_ID,

         CASE
              WHEN COLUMNPROPERTY(OBJECT_ID('EXAMPLE_TABLE'),'COL1','PRECISION') = -1 THEN 24
              ELSE ISNULL(DATALENGTH(COL1), 1)
         END
          +
         CASE
              WHEN COLUMNPROPERTY(OBJECT_ID('EXAMPLE_TABLE'),'COL2','PRECISION') = -1 THEN 24
              ELSE ISNULL(DATALENGTH(COL2), 1)
         END
          +
         CASE
              WHEN COLUMNPROPERTY(OBJECT_ID('EXAMPLE_TABLE'),'COL3','PRECISION') = -1 THEN 24
              ELSE ISNULL(DATALENGTH(COL3), 1)
         END
          +
         ...
         ...
         AS ROW_SIZE

FROM     EXAMPLE_TABLE

ORDER BY ROW_SIZE DESC
;

多么野兽！而且这只是一个近似值。

然后我们发现

DBCC SHOWCONTIG ('EXAMPLE_TABLE') WITH TABLERESULTS

返回最大记录大小。这表明 SQL Server 中已经有一个算法可以计算行的确切大小。

我们如何直接访问该算法？

不重复：

• 交易日志很大！但是选择了简单的恢复模式！

• 当数据库处于简单模式并且没有等待事务时，为什么我的事务文件会增长

原因：我的日志不大，但是是空的。它很大，但正在使用中。

问题

我有一个小型数据库 (100 MB)，它全天都会受到大量小型事务性工作负载的影响。尽管我似乎了解如何限制它，但我已经看到事务日志继续增长。显然我错过了一些东西。

• 数据库处于简单恢复模式（我不能保证它在第一次创建时没有处于完全状态，但它从未处于完全负载状态）。

• DBCC SQLPERF(Logspace) 说：

| Log Size (MB) | Log Space Used (%) | Status
--------------------------------------------
| 927.2422      | 94.72562           | 0

• DBCC LOGINFO 说：

有39行（VLF）进行，所有这些都具有Status的2。

• DBCC opentran 说：

最旧的活动事务：
SPID：51
名称：user_transaction
开始时间：2019 年 3 月 11 日晚上 7:27

注意：鉴于我的服务器时间，此事务大约有五分钟的历史。

我不明白为什么当我的应用程序只创建 - 最多 - 大约六个短期交易时，每个 VLF 都在使用中，尽管非常频繁。

我尝试终止连接到该数据库的唯一应用程序进程，但它没有释放事务日志。

解决方法

我做了一个完整备份只是为了解决这个问题，它释放了整个日志空间......所以......我不知道。我得看看它是否会再次过度生长。

我已经计算出所有隐式转换，但我仍然在计划中看到它的提及。我已附上该计划，任何建议都会有所帮助。

select cardholder_index, sum(value) as [RxCost] 
into #rxCosts 
from RiskPredictionStatistics with (nolock) where model_name = 'prescription_cost_12_months'
 and model_set_name = 'rx_updated' and run_id in (select value from #runIds) 
 and exists (select 1 from StringContainsHelper with (nolock) where IntValue = cardholder_index and ReferenceId = @stringContainsHelperRefId)
group by cardholder_index

https://www.brentozar.com/pastetheplan/?id=SyHl9xFeS

我刚刚开始使用所有很酷的复制工具来以编程方式监控复制

早期发现之一是sp_replmonitorhelpsubscription

当我运行它时

 sp_replmonitorhelpsubscription

我得到

消息 20587，级别 16，状态 1，过程 sp_replmonitorhelpsubscription，第 77 行 [批处理开始第 16 行]

存储过程“sp_replmonitorhelpsubscription”的“@publication_type”值无效。

根据 MS 文档，它应该是有效的，默认值为空

NULL（默认）

如果我用参数运行它，它工作正常。

sp_replmonitorhelpsubscription  @publication_type = '0' 

我将它与事务复制一起使用，在单个服务器（报告副本）上我已经尝试过，并且在 SQL 2017 和 2016 上得到了相同的结果。我正在针对分发数据库运行它

不确定我是否在做一些愚蠢的事情，如果 MS 文档有误，或者什么。

为什么 sp_replmonitorhelpsubscription 在没有参数的情况下不起作用？