我只是一名低级开发人员，因此对我们的虚拟服务器基础设施并没有太多了解，所以我想在这里问一个问题。
我们的 IT 经理刚刚告诉我，忽略基于 Windows Server 2003 64 位的 SQL Server 上某个驱动器的“可用磁盘空间”数字，并表示“重要的是服务器跨越的磁盘阵列上的可用空间”。
据我所知，服务器是在 VMWare 上虚拟的（我认为是 ESX），并且我们有一个 SAN。为什么要设置服务器上报告的磁盘大小与实际物理可用的磁盘大小不同？这不会造成麻烦吗？
请指教。我很想知道这将如何工作/设置...
答案1
他可能谈论的是精简配置。
精简配置是一种适用于大型集中式计算机磁盘存储系统、SAN 和存储虚拟化系统的机制。精简配置允许在刚好足够和及时的基础上轻松地将空间分配给服务器。（维基百科）
本质上，你让可用空间看起来比实际空间多，然后按实际使用情况提供空间。这样可以大大降低存储容量开销。
如果超出物理可用存储量，则会导致写入失败/权限被拒绝。对于 MS-SQL 服务器来说，这确实意味着很多麻烦 :)
答案2
Roy 关于精简配置的评论可能是正确的，但如果是这样，那么您遇到的情况是，服务器认为卷中存在 X 量的存储，但实际上只有 X 的一部分实际被物理分配。当服务器消耗可用空间时，SAN\Storage 子系统会分配实际存储块。这允许系统管理员为系统配置其预期使用寿命内所需的总容量，而不必立即配置完全相同数量的物理磁盘。操作系统认为它拥有所有可用空间，如果需要，它就会拥有这些空间，但这种“按需分配”功能使存储管理员能够经济高效地规划分阶段存储购买，而不是预先购买大量将在其大部分使用寿命中闲置的存储。这也意味着服务器管理员不必离线任何服务来扩展卷，也不必随着时间的推移而费心扩展卷（前提是长期规划从一开始就很好）。
考虑到你提出问题的方式，我认为你服务器上的某些存储更有可能是通过以下方式安装的：NTFS 卷安装点。这个概念对于 Unix 用户来说非常基础，但在 Windows 环境中仍然相对不常见。如果卷上有正在使用的挂载点，则可用的总可用空间量将超过驱动器根目录中显示的空间量 - 每个挂载点下的可用空间取决于它指向的存储卷，并且不会反映在驱动器上层的元数据中。这是一种为几乎所有应用程序提供存储的完全透明的方式，但如果使用挂载点，则备份过程需要避免根据磁盘级摘要数据对卷中的数据量做出简单的假设。
答案3
这听起来好像服务器正在使用的物理磁盘上还有更多空间，他会扩大卷以在某个时候消耗更多的空间。