我有 3 个 SQL Server 2008 实例，每个实例位于不同的机器上，每个实例上都有多个数据库。我的 SAN 上有 2 个单独的 LUN，用于 MDF 和 LDF 文件。NDX 和 TempDB 文件在每台机器的本地驱动器上运行。3 个实例可以为数据文件共享同一个卷，为日志文件共享另一个卷吗？
我在 SAN 上没有精简配置，所以我不想限制创建多个卷的磁盘空间，因为有人建议我应该为每个实例创建一个卷（驱动器号），如果不是为每个数据库创建一个卷（驱动器号）。我知道我至少应该拆分我的日志和数据文件。没有实例会共享实际的数据库文件，只是驱动器上的空间。
任何帮助都将不胜感激。
答案当然是：“视情况而定”。但是，我可以尝试给您一些提示，说明它取决于什么。
SQL Server 实例“假定”它对其资源具有独占访问权。因此，默认情况下它会填满所有可用的 RAM，它将使用所有 CPU，并且会尝试使 I/O 通道饱和以获得最佳性能。这就是为什么一般建议不要让您的实例同时访问相同的磁盘。
另一件事是 SQL Server“知道”顺序 I/O 访问比随机 I/O 提供更高的吞吐量，因此有很多机制在起作用（如日志文件组织、预读、惰性写入器等）尽可能避免随机 I/O。
现在，如果三个 SQL Server 实例同时在单个卷上执行顺序 I/O 请求，那么从卷的角度来看，您将再次收到随机 I/O 请求，这会损害您的性能。
话虽如此，只有当您的 I/O 子系统是一个重大瓶颈时，它才是一个问题。如果您的日志文件卷足够快，以至于来自实例的混合顺序写入不会产生问题，那么请继续。如果您在实例上有足够的 RAM，大多数时候可以从缓冲区缓存中满足数据读取，那么您的 I/O 子系统不需要太多的读取性能。
在每种情况下，您应该避免在日志或数据文件上执行多个增长步骤。如果一个文件系统上的多个文件正在增长，您将获得碎片，并且碎片可以将顺序读取或写入请求甚至从单个源再次转换为随机 I/O。
如果您使用 SSD 作为磁盘，整个情况会再次发生变化。这些具有完全不同的要求和行为，但是由于您没有提及 SSD，我将假设您使用“常规”基于磁盘的阵列或 RAID 配置。
简短摘要：如果情况合适，您可能会侥幸成功，但是如果不从 SAN 和 SQL 的角度了解更多关于您的系统的信息，就很难进行评估。