我们正在将大型数据库从本地服务器(MSSQL 2000)迁移到托管在Amazon Web Services上的SQL 2012 Server。
我在新服务器上从头创建了一个新数据库,运行了一个脚本来创建表,导入了所有数据,然后运行SQL比较来构建所有存储过程和视图等。
在本地服务器上运行的存储过程花了2分钟,但现在在SQL 2012上运行它超过30分钟并超时。
我重建了所有索引并更新了统计信息以及在服务器上运行存储过程而不是远程但没有区别。
有什么建议吗?
感谢您的回复
[Old Server] AMD Quad Codde 2376 2.29Ghz with 4GB Ram running Windows 2003 + SQL 2000
[New AWS Instance] Intel Xeon E5-2670 2.50Ghz with 30.5 GB Ram running Windows 2012 + SQL 2012
wait_type wait_time_s pct running_pct
DIRTY_PAGE_POLL 23132.77 28.47 28.47
HADR_FILESTREAM_IOMGR_IOCOMPLETION 23131.66 28.47 56.95
SP_SERVER_DIAGNOSTICS_SLEEP 23100.10 28.43 85.38
LATCH_EX 4784.63 5.89 91.27
SOS_SCHEDULER_YIELD 1548.42 1.91 93.18
LCK_M_U 1438.27 1.77 94.95
WRITELOG 753.34 0.93 95.87
答案 0 :(得分:0)
你必须从某个地方开始,分析服务器。当您声称自己更新了统计数据/索引时,接下来就是要查看它受到的伤害。使用这个广泛使用的脚本来查找等待统计数据,以便您可以更好地吸入这种情况。
WITH [Waits] AS
(SELECT
[wait_type],
[wait_time_ms] / 1000.0 AS [WaitS],
([wait_time_ms] - [signal_wait_time_ms]) / 1000.0 AS [ResourceS],
[signal_wait_time_ms] / 1000.0 AS [SignalS],
[waiting_tasks_count] AS [WaitCount],
100.0 * [wait_time_ms] / SUM ([wait_time_ms]) OVER() AS [Percentage],
ROW_NUMBER() OVER(ORDER BY [wait_time_ms] DESC) AS [RowNum]
FROM sys.dm_os_wait_stats
WHERE [wait_type] NOT IN (
N'CLR_SEMAPHORE', N'LAZYWRITER_SLEEP',
N'RESOURCE_QUEUE', N'SQLTRACE_BUFFER_FLUSH',
N'SLEEP_TASK', N'SLEEP_SYSTEMTASK',
N'WAITFOR', N'HADR_FILESTREAM_IOMGR_IOCOMPLETION',
N'CHECKPOINT_QUEUE', N'REQUEST_FOR_DEADLOCK_SEARCH',
N'XE_TIMER_EVENT', N'XE_DISPATCHER_JOIN',
N'LOGMGR_QUEUE', N'FT_IFTS_SCHEDULER_IDLE_WAIT',
N'BROKER_TASK_STOP', N'CLR_MANUAL_EVENT',
N'CLR_AUTO_EVENT', N'DISPATCHER_QUEUE_SEMAPHORE',
N'TRACEWRITE', N'XE_DISPATCHER_WAIT',
N'BROKER_TO_FLUSH', N'BROKER_EVENTHANDLER',
N'FT_IFTSHC_MUTEX', N'SQLTRACE_INCREMENTAL_FLUSH_SLEEP',
N'DIRTY_PAGE_POLL', N'SP_SERVER_DIAGNOSTICS_SLEEP')
)
SELECT
[W1].[wait_type] AS [WaitType],
CAST ([W1].[WaitS] AS DECIMAL(14, 2)) AS [Wait_S],
CAST ([W1].[ResourceS] AS DECIMAL(14, 2)) AS [Resource_S],
CAST ([W1].[SignalS] AS DECIMAL(14, 2)) AS [Signal_S],
[W1].[WaitCount] AS [WaitCount],
CAST ([W1].[Percentage] AS DECIMAL(4, 2)) AS [Percentage],
CAST (([W1].[WaitS] / [W1].[WaitCount]) AS DECIMAL (14, 4)) AS [AvgWait_S],
CAST (([W1].[ResourceS] / [W1].[WaitCount]) AS DECIMAL (14, 4)) AS [AvgRes_S],
CAST (([W1].[SignalS] / [W1].[WaitCount]) AS DECIMAL (14, 4)) AS [AvgSig_S]
FROM [Waits] AS [W1]
INNER JOIN [Waits] AS [W2]
ON [W2].[RowNum] <= [W1].[RowNum]
GROUP BY [W1].[RowNum], [W1].[wait_type], [W1].[WaitS],
[W1].[ResourceS], [W1].[SignalS], [W1].[WaitCount], [W1].[Percentage]
HAVING SUM ([W2].[Percentage]) - [W1].[Percentage] < 95; -- percentage threshold
GO
我假设这个选项名为“TARGET_RECOVERY_TIME”并使用ALTER DATABASE命令设置。有关详细信息,请参阅http://msdn.microsoft.com/en-us/library/hh403416(v=sql.110).aspx处的BOL。 通过将TARGET_RECOVERY_TIME设置为不同于0的值,您实际上启用了更有效并带来优化的间接检查点。例如,将其设置为60秒,并观察系统的行为。