相关疑难解决方法(0)

我想知道如何识别实际填充 TEMPDB 数据库事务日志的确切查询或存储过程。

众所周知，DMV 不保存有关页数和行数的准确信息。但是，当您更新统计数据时，我不明白为什么他们不会。

我正在开发一个监控工具，想知道每个索引和数据的磁盘大小等。最终我想找到合适的填充因子，以及其他一些东西。

The space used by my function and the old sp_spaceused differs a little bit on the space usage, but not on record count.

Can you see if there is anything missing in my select?

this is the sp_spaceused (then I convert the numbers in MB):

sp_spaceused 'tblBOrderRelationship'
go

select 318008/1024.00 AS reserved,
140208/1024.00  AS data,
177048/1024.00 AS index_size,
752/1024.00    AS unused

But when I run my select, code below\picture below, I get slightly different figures.

SET TRANSACTION …

我们最近在多次接近中断后停用了一个实施得相当糟糕的服务代理设置，但是在我早上检查时，我注意到有 2 个服务代理内部 SPID (<50) 仍然持有约 75% 的 TempDB空间。

现在，我知道这些是服务代理任务，因为 SysProcesses 上的 CMD 列显示“BRKR EVENT HNDLR”和“BRKR TASK”，而最后的等待类型分别是“BROKER_EVENTHANDLER”和“SLEEP_TASK”。两者都将“背景”作为状态，0 开放交易和一个多月前的最后一批时间。

目前服务代理实现已完全禁用（从代码角度），队列已禁用（is_activation_enabled 和 is_receive_enabled = 0），transmission_queue、conversation_endpoints 或实际队列中没有任何内容，但有问题的数据库仍然有 is_broker_enabled = 1（与 TempDB 和 MSDB 一样）。

服务器当前正在运行带有安全修复程序 (11.0.5343.0) 的 SP2，即使在集群故障转移之后，TempDB 的使用似乎仍然存在。我们没有尝试重新启动，因为这是一个生产系统，但我认为故障转移会产生相同的效果。

以前有没有人遇到过这个问题，如果有，你是怎么解决的？

谢谢，

我希望能够回顾并查看给定时间段内事务日志中的已用空间。对增长或文件大小不感兴趣，因为它们不会告诉我实际使用了多少空间。

我正在从简单模型切换到完整恢复模型，需要了解事务日志的大小。