sql-server-2008 – SQL Server 2008表现不佳 – 迁移到新服务器

上周末,我们将生产数据库移至新服务器.它是 Windows Server 2008 R2数据中心.它是一个全新的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 RAM,并且在任何给定时间它仅对所有进程使用35 GB.在旧的生产服务器上,任何给定点的RAM使用率至少为50％,即使几乎没有人使用它,我们的开发环境大约80％,这是好的和正常的.我不知道为什么新服务器上的SQL Server 2008只使用了可用内存的一小部分.

我们重新配置了我们的tempdb以使用相同大小的10个数据文件,它在我们的旧服务器之前是1,核心/文件比率为8：1.我们在这台新服务器上有48个核心,因此核心/文件比率为48:10.其中一个更sr.这里的DBA为tempdb和另外5个日志文件创建了10个辅助数据文件,但这似乎没有任何帮助.

我检查了perfmon的总内存,它看起来像是扁平化的.我对配置的内存没有任何限制,所以应该使用所有可用的内容,对吗？

我已经尝试使用谷歌搜索有关tempdb和内存使用的问题的答案,所有建议似乎都适用于早期的2003服务器或34位系统.我找不到任何有助于Windows Server 2008 R2数据中心和SQL Server 2008实例的相关信息.

网络人员也尝试打电话给微软,到目前为止他们一直无法提供帮助.

请帮帮我.我确信它是一个内存/ tempdb问题,但我似乎无法让SQL使用它可用的所有内存.

解决方法

根据向tempdb添加多个数据文件,MSFT和行业专家之间存在一些冲突. MSFT很好用,建议核心：文件1：1,但在所有情况下都不是必需的.业内专家表示只有1：1/4到1：1/2就足够了,但你需要注意2：1：1(Page Free Space即PFS瓶颈)和2：1：3(SGAM瓶颈)并调整必要时的文件数量.在某些极端情况下,您可能必须添加比核心数量更多的文件,但它的大部分“它取决于”.

出现内存问题,您是否检查了PageFile的％使用率,页面预期寿命,缓冲区缓存命中率.如果这些数字看起来不错,那么这个新服务器可能不够强调.

在更改tempdb中的文件数之前,您需要查看等待统计信息.如果24个文件适合你,那么它很好,但看看等待统计数据并找出tempdb是否是瓶颈.请注意,tempdb有两种常见的瓶颈类型(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

（编辑：衡阳站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!