了解SQL Server数据库的大小是许多DBA的职责之一，而这个职责你可以轻松通过存储过程sp_SDS来完成。sp_SDS不仅能确定“SQL 数据库空间”，而且它还能监测数据库的增长，提醒DBA关于数据或日志文件的增长，执行事务日志备份，甚至提供详细的文件级明细表，这样DBA可以压缩文件以获取最大空余空间。

　　本文介绍了完整的sp_SDS及其算法。相比文章《存储过程sp_SOS》，本文将进一步阐述如何查询数据库对象的大小，包括SQL Server表。

　　列表1：sp_SDS的T-SQL定义。

　　现在，我将解释这个SQL Server存储过程是如何查找数据库的大小以及是如何使用它的。

　　sp_SDS大部分输入变量是相当明确的。我们需要查询大小的数据库是@TargetDatabase。@Level指的是报告详细程度，可以是数据库级或者单个数据库文件级的。它的默认值是数据库级的。它会为每一个数据库显示一个汇总。一个比特值是@UpdateUsage。它的默认值是0，表示我们并不希望在SQL Server 2005和SQL Server 2008中运行“DBCC UPDATEUSAGE”。在SQL2000中，sysindexes表中的值有时候不能及时更新。因此，为了获得准确的读取值，我们需要运行DBCC命令。@Unit参数表明报告测量单位应该是什么，即KB、MB或GB。如果没有指定，那么使用的测量单位是兆字节的。

　　图1，你可以看到列表2代码执行的屏幕截图。默认情况下，该报告是数据库级的汇总，每一行代表一个数据库。

　　列表2：Sp_SDS不需要参数的最简单的执行形式（所有输入变量都是null）。

　　图1：在测试SQL Sever 2005上运行没有输入参数的sp_SDS的结果。它生成一个数据库级的以兆字节形式报告的汇总。

　　第一列“Weight (%)”计算的是所指定的数据库所占总数据库大小的百分比。比如，AdventureWorks全部为469.94MB，除以总数的20，404.51 MB，就是0.023（即2.3%）。

　　根据报告，我们很容易可以看出DBAReports占用了大多数的数据库空间（大约是77%）。这一栏中的数据可以让DBA很容易看到数据库大概的空间使用情况。而剩下的值相关的列被安排在一个类似于公式的结构中。

　　正如我在上一篇关于sp_SOS文章中提到的，我喜欢用算术公式来表示一些看起来很费解的关系。因此，“TOTAL”列是左边和右边的相加结果。这两个等式位于不同方向的中心。一个显示被占用的空间和剩余的自由空间。另外一个显示数据库的数据和日志构成。下面就是以数学公式表示数字是如何得出的（仍然以AdventureWorks为例）：

　　值得注意的是在结果中数据库Test_snapshot的一些值是null。Test_snapshot是一个快照数据库，设计中它是不允许有日志文件的。此外，在报告的底线有一个汇总行显示了每一列的小计。