上个周末我们把生产数据库移到了新的服务器上。 这是一个Windows Server 2008 R2 Datacenter。 在这是一个全新的SQL Server 2008企业版64位安装。 星期天，这个举动结束后，一切都看起来很正常。 但是，一旦用户周一早上开始使用这个应用程序，事情就会放缓，并且一直缓慢。
我想我已经将问题隔离到了tempdb，因为几乎所有在我检查时运行的活动进程都被插入临时表中。 这个查询：
SELECT '1' AS Number,GETDATE() AS Date INTO #Temp Go INSERT INTO #Temp VALUES ('1', GETDATE()) GO 1000 在新的2008服务器上需要20秒，而在使用SQL 2005的旧服务器上只需要2-3秒。
新的服务器有128 GB的内存，在任何时候，所有进程只能使用总计35 GB的内存。 在旧的生产服务器上，ram的使用率在任何时候都至less达到50％，即使几乎没有人使用它，而我们的开发环境约为80％，这是正常的。 我不知道为什么我们在新服务器上的SQL Server 2008只使用可用内存的一小部分。
我们将tempdb重新configuration为使用10个相同大小的数据文件，在旧的服务器上以8：1的核心/文件比率为1。 我们在这个新的服务器上有48个核心，所以核心/文件比率是48:10。 其中一个更加先生 DBA在这里为tempdb和另外5个日志文件创build了10个辅助数据文件，但是这似乎没有任何帮助。
我已经检查了perfmon的总内存，它看起来像是扁平化。 我没有configuration内存的任何限制，所以它应该使用的一切可用，对不对？
我试着用Googlesearch关于tempdb和内存使用的问题的答案，所有的build议似乎适应于2003年的早期服务器或34位系统。 我无法find任何有助于Windows Server 2008 R2数据中心和SQL Server 2008实例的相关信息。
networking人员也尝试致电微软，迄今为止他们一直无法提供帮助。
请帮我一下 我真的相信这是一个内存/ tempdb的问题，但我似乎无法让SQL使用它可用的所有内存。
你的高级DBA不知道他在做什么。 不幸的是，添加多个日志文件并不能提高性能。 他不知道日志文件是如何工作的，这真是一个耻辱。 日志文件是按顺序使用的，如果你再添加5个日志文件，它们将不会被使用，除非第一个被完全使用。 在正常的日常操作中不会发生。
在将多个数据文件添加到tempdb时，MSFT和行业专家之间会有一些冲突。 MSFT播放很好，并build议1：1核心：文件，但在所有情况下，这是没有必要的。 行业专家说，只有1：1到1：1：1/2就足够了，但是你需要注意2：1：1（页面空间，即PFS瓶颈）和2：1：3（SGAM瓶颈），并调整必要的文件数量。 在一些极端的情况下，你可能不得不添加更多的文件，而不是核心的数量，但它是一个大的“它取决于”。
来到内存问题，你有没有检查％PageFile的使用率，页面预期寿命，缓冲区caching命中率。 如果这些数字看起来不错，那么这可能是新的服务器没有足够的重视。
在更改tempdb中的文件之前，您需要查看等待统计信息。 如果24个文件为你工作，那么它的好处，但看看等待统计数据，并找出tempdb是否是瓶颈。 请注意，tempdb有两种常见的瓶颈types（IO +分配瓶颈）。 如果是分配瓶颈，那么你可能也想使用TF 1118。
-- Isolate top waits for server instance since last restart or statistics clear WITH Waits AS (SELECT wait_type, wait_time_ms / 1000. AS wait_time_s, 100. * wait_time_ms / SUM(wait_time_ms) OVER() AS pct, ROW_NUMBER() OVER(ORDER BY wait_time_ms DESC) AS rn FROM sys.dm_os_wait_stats WHERE wait_type NOT IN ('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE','SLEEP_TASK' ,'SLEEP_SYSTEMTASK','SQLTRACE_BUFFER_FLUSH','WAITFOR', 'LOGMGR_QUEUE','CHECKPOINT_QUEUE' ,'REQUEST_FOR_DEADLOCK_SEARCH','XE_TIMER_EVENT','BROKER_TO_FLUSH','BROKER_TASK_STOP','CLR_MANUAL_EVENT' ,'CLR_AUTO_EVENT','DISPATCHER_QUEUE_SEMAPHORE', 'FT_IFTS_SCHEDULER_IDLE_WAIT' ,'XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN', 'SQLTRACE_INCREMENTAL_FLUSH_SLEEP')) SELECT W1.wait_type, CAST(W1.wait_time_s AS DECIMAL(12, 2)) AS wait_time_s, CAST(W1.pct AS DECIMAL(12, 2)) AS pct, CAST(SUM(W2.pct) AS DECIMAL(12, 2)) AS running_pct FROM Waits AS W1 INNER JOIN Waits AS W2 ON W2.rn <= W1.rn GROUP BY W1.rn, W1.wait_type, W1.wait_time_s, W1.pct HAVING SUM(W2.pct) - W1.pct < 99 OPTION (RECOMPILE); -- percentage threshold
除了@Sankar解释之外，还有一个在运行Windows 2008 R2的服务器上运行省电模式（默认情况下）运行的SQL Server的升级后的已知问题，它会影响查询性能，特别是如果您的服务器没有处于巨大压力（CPU可能会以一半的速度运行以节省电力）。 看看这个和这个博客的细节。
嘿家伙，感谢所有有用的build议和链接。 我已经把很多这些信息传递给了我们的系统pipe理员，因为我实际上没有这个服务器的pipe理权限，只有SQL。 星期五之后，我们将tempdb文件重新组织为24个数据文件，摆脱了辅助数据文件和额外的日志文件，这似乎有很大的帮助。 周五下午或周末我们没有太多的负担，所以很难说这是否能解决问题。
直到昨天，我还没有意识到周末还有更多的工作要做。 他们在服务器和几个服务包上安装了SQL Server 2005。 （我想他们想要有一个备份实例可用，我不知道其中的原因）当2005实例处于活动状态时，RAM使用率达到正常水平。 SQL Server 2005实例被移除了，2008年实例的RAM使用率仍然很高，这很好 – 我们希望2008年开始使用所有可用的RAM。 所以我不知道这是2005年推出的东西，还是其中一个服务包（虽然它们都是旧的，在这一点上不应该是必须的），但现在RAM已经到了我们想要的地方太。
对不起，如果我没有回到每个人的具体统计。 我只是一个中等水平的数据库pipe理员，在这类事情上真的没有任何业务，这可能是我偶然发现的一个奇迹，发现tempdb核心：文件比率问题。
我假设tempdb主文件结构是关键。 所以，我希望至less这可以帮助那些有同样问题的人popup来。