在备份的SAN上存储Server的SAN性能问题

Question

恐怕我对SAN不太了解，所以请原谅我缺乏细节或技术术语。

作为一名开发人员，我刚刚完成并安装了一个现有的生产系统，一个新的应用程序，但是它似乎已经提示了从SAN获取的备份的性能。据我所知，这里有一面镜子，上面的SAN通常是一直在街区级别拍摄的。然而，似乎有太多的新写到磁盘，使SAN镜像/备份进程无法再跟上。我相信我已经把范围缩小到了SQL Servers tempdb，它存在于一个导致问题最大部分的驱动器上！事实上，不管我的应用程序是什么，我认为tempdb一直在贡献最大的部分问题！

因此，我的问题是，tempdb是否应该被镜像或支持在SAN上，是否还有其他人已经经历过这种痛苦？我想知道，仅仅因为对它的任何写入都不需要保存，所以最好的做法是确保tempdb永远不会在SAN上被镜像。这也提出了一个稍微相关的问题--依赖于SQL服务器内置的数据库备份工具(在完全恢复模式下使用完全/差分和事务日志备份的DB)，还是像我们的应用程序一样，SQL服务器处于简单的恢复模式，并且自SAN被镜像和备份以来从未备份过？

非常感谢

Answer 1

您根本不需要备份/镜像tempdb，因为它是在Server重新启动时重新创建的。

另一方面，即使在镜像/ SAN复制可用的情况下，我仍然将SQL备份循环作为带带和大括号恢复点--但这通常是因为SAN备份是由其他人管理的，我喜欢一些bak文件，我可以轻松地使用这些文件来进行测试恢复等等。

Answer 2

所有这些都说明了，iff tempdb有大量的写作，您应该尝试消除它们。当它需要比可用内存更多的页面时，tempdb尝试不写磁盘。这通常是SQL拙劣的标志，就像多余的DISTINCT子句(强制将所有记录保存在tempdb中以消除双数)。不要总是这么说，但是如果你收到了很多tempdb的文章，试着找出你是否真的需要它们。

Answer 3

tempdb不应该被镜像。