查找数据库中所有表的未压缩大小
在Dynamics AX中，存在一种缓存机制，可以将表配置为加载到内存中并进行缓存。此高速缓存限制为一定数量的KB，以防止出现内存问题。我正在谈论的设置被调用，entiretablecache并在请求单个记录时立即将整个表加载到内存中。 直到最近，我们还是依靠一些脚本来验证具有此设置的表的大小，以查看表大小是否超过此限制。 现在，压缩开始发挥作用，像sp_spaceused或sys.allocation_units之类的东西似乎报告了压缩数据实际使用的空间。 显然，应用程序服务器正在处理未压缩的数据，因此SQL Server中磁盘上的数据大小无关紧要。我需要未压缩数据的实际大小。 我知道sp_estimate_data_compression_savings，但是顾名思义，这只是一个估计。 我希望尺寸尽可能正确。 我能想到的唯一方法是一些复杂的动态SQL创建与压缩表具有相同结构的未压缩表，将压缩数据插入该影子表中，然后检查该影子表的大小。 不用说，这有点乏味，并且需要花费一些时间才能在数百GB的数据库上运行。 Powershell可能是一个选项，但是我不想遍历所有表以select *对它们执行操作以检查脚本中的大小，因为那样只会淹没缓存，并且可能还需要很长时间。 简而言之，如果可能的话，我需要一种获取每个表大小的方法，因为一旦将其解压缩，就可以将碎片从呈现给应用程序的方程式中分离出来。我对各种方法持开放态度，首选使用T-SQL，但我不反对Powershell或其他创造性方法。 假设应用程序中的缓冲区是数据的大小。bigint始终是bigint的大小，并且字符数据类型为每个字符2个字节（unicode）。BLOB数据也占用数据的大小，枚举基本上是int，数字数据是numeric（38,12），datetime是datetime的大小。另外，没有NULL值，它们要么存储为空字符串，要么存储1900-01-01为零。 没有有关如何实现此方法的文档，但是这些假设是基于一些测试以及PFE和支持团队使用的脚本（显然，它们也忽略了压缩，因为检查是在应用程序中构建的，而应用程序无法分辨（如果基础数据已压缩），这还将检查表大小。例如，此链接指出： 避免对大型表使用EntireTable缓存（在AX 2009中超过128 KB或16页，在AX 2012中超过“整个表缓存大小”应用程序设置[默认值：32KB或4页]）–改为记录缓存。