Sta*_*ser 5 sql-server sql-server-2008-r2 standard-edition
我们使用的是 SQL Server 2008 R2 标准版。一些表高度分散。我想看看碎片整理是否会提高性能,是否值得在此过程中锁定表/索引。因此,我想在测试环境中恢复完整备份并模拟实时环境。
遵循的最佳方式是什么?我怎样才能捕捉到某个时间段内在现场环境中发生的事件?有哪些工具可用于此目的?
谢谢
你有几个选择。有一些第三方工具可以帮助模拟数据库的负载。有一些开放的简单实用程序,例如SQL Query Stress,它可以以您希望的任何频率运行您提供的任何查询。
还有运行服务器端跟踪和重放这些跟踪的组合。这可以像从跟踪中收集脚本一样简单(正如 Dan 在上面正确指出的那样,不要使用 Profiler GUI 来捕获事件,而是使用服务器端跟踪将跟踪捕获到文件中),然后如果您更关心的话,可以重播工作负载如果您更关心单个查询性能而不是并发性,则可以了解单个查询性能。
如果您需要深入研究并发性并从多个角度实时查看工作负载 - 您可能需要考虑使用分布式重播功能。这允许您将任何版本的 SQL Server 中的跟踪指向 SQL Server 2005,并针对任何版本的 SQL Server 运行它,也可以返回 SQL Server 2005。 Jonathan Kehayias 逐步介绍了如何设置分布式重播。这将允许您从分配负载的多个客户端配置重播 - 单个探查器重播永远不会允许您进行扩展。(请注意 - 您会看到该工具是 SQL Server 2012 工具。不要让这个吓到您,该工具当时就出来了,但可以处理您的 SQL Server 2008 R2 环境)
综上所述,无论哪种方式都很复杂。进行重放跟踪有一些要求和步骤。重播它还需要采取一些步骤来确保您从相同的起点开始等。这种复杂性值得理解,它可以帮助执行升级准备测试,帮助了解整个应用程序的硬件更改等。您可以使用RML 实用程序还可以分析之前和之后的痕迹,这可以帮助您显示之后情况如何改善或没有改善。
如果您只想查看重建索引是否发生任何更改,您也可以进行更简单的测试。您可以采用大型可重复插入并仅在之前和之后运行。您可以进行一些高扫描的查询和一些高搜索的查询,并在之前和之后运行它们。不过,我会确保您仍然以任何方式重建统计信息,因为重建索引确实会重建索引级别统计信息,有时比重建索引带来更多好处,并且人们将好处归因于索引重建而不是获得的索引统计信息重建。我往往倾向于“重建”阵营,但 IO 性能、工作负载模式等方面的硬件变化都使得这对我来说不一定是一个硬性规定。
归档时间: |
|
查看次数: |
1966 次 |
最近记录: |