执行之后,你会看到如下信息:
Local directory 'D:\tempdbdata\tempdb.mdf'is used for tempdb in a clustered server. This directory must exist on each cluster node and SQL Server service has read/write permission on it. The file "tempdev" has been modified in the system catalog. The new path will be used the next time the database is started.
Local directory 'E:\tempdblogs\templog.ldf' is used for tempdb in a clustered server. This directory must exist on each cluster node and SQL Server service has read/write permission on it. The file "templog" has been modified in the system catalog. The new path will be used the next time the database is started.
如此而已。你需要记住的是,所有群集节点上都要有相同的可用的路径,服务账号需要有读写权限,以便故障转移之后tempdb能够启动。
为何本地tempdb有利?把tempdb从共享磁盘移到本地磁盘有两方面的原因,且两个原因都与性能有关。第一个原因是成本效益,超快的固态存储能够在承受繁重tempdb使用的服务器上实现显著的性能提升。第二个原因是,I/O请求脱离共享磁盘可以改善共享存储的性能。 Tempdb初始化大小和自动增长(Autogrowth)
SQL Server的默认安装会创建一个tempdb数据库,数据文件8MB,事务日志文件1MB。对于很多SQL Server安装,这些文件大小不够,但配置了必要时自动增长10%。你可以在属性窗口看到tempdb的初始化大小:
虽然自动增长功能让我们在维护SQL Server安装时不必插手,但是未必是我们期望的,与因为在它们自动增长时,文件不能被使用,这会导致硬盘上文件的碎片,从而导致差劲的性能。下图显示了tempdb的大小,你可以看到,SQL Server实例重启后,tempdb的大小恢复为初始设置的大小。
tempdb应该设置多大?首先,除非是SQL Server Express,设置tempdb比默认的更大;其次,如果tempdb在自己的磁盘上,那么配置它为几乎填充磁盘的大小。这没有性能损失,你也不必再担心自动增长。
自动增长应该设置多大?如果tempdb在自己的磁盘并且配置几乎填充该磁盘,那么你不需要启用自动增长。对于任何数据库,最佳的办法是,为数据库设置合适的大小,以至于它们不需要自动增长,但是你仍然要配置它,以防万一需要。对于自动增长,使用固定增长量通常是一个更好的办法,因为这使得自动增长更加可预测。例如,自动增长10GB事务日志10%,会花费较长时间,并会影响数据库的可用性。Windows Server 2003及后来版本的Instant File Initialization (IFI)功能使数据文件的自动增长更加容易,但对于日志文件无效。如果服务账号是本地管理员或有Manage Volume Maintenance Tasks advanced user权限,SQL Server就会自动使用IFI。要给服务账号必要的权限,你可以运行gpedit.msc使用Local Group Policy Editor,如下图所示:
一旦IFI工作了,你可以把数据文件的自动增长设置为很大的固定量。根据数据库的大小,50MB或500MB都是不错的值,但设置任何大小几乎都是立即创建的,因此避免了停机。如果配置多个数据文件,想允许自动增长,可以考虑启用追踪标记1117,它会强制所有数据文件均匀地增长,因此不会打破文件之间的负载均衡。
然而,对于事务日志文件,你需要更加保守,使用的配置要能够平衡自动增长所花费的时间和额外空间的有用性。例如,以1MB自动增长是快速的,但需要频繁地做,这会变成瓶颈。对于事务日志,至少10MB的自动增长是个好的开始,但是你或许需要更高,来提供足够的空间,避免再次快速地自动增长。最佳选项是首先通过恰当地设置文件大小来避免自动增长。 配置多个Tempdb数据文件
多个数据文件有助于减少tempdb分配竞争问题,另外它可以增加tempdb的I/O吞吐量,特别是当它运行在非常快的存储上时。创建多个数据文件,它们都会在primary文件组,SQL Server使用一个成比例的填充算法(proportional fill algorithm)来确定使用哪个文件,来为每个请求创建对象。如果所有文件的大小完全一样,那么SQL Server会循环使用这些文件,把负载均等地分摊给各个文件。当然,这恰好是你想要的情况。
微软推荐文件和逻辑CPU的数量达到1:1,因为在巨大工作负载测试时,发现有利于性能,即使有成百数千个数据文件。然而,一个更加务实的办法是,文件和CPU 1:1的映射变成1:8,如果还能看到分配竞争或看到推入I/O子系统更难,那么就添加文件。