恐怕我对SAN的了解不多，所以请原谅我缺乏细节或技术条款。
作为一名开发人员，我刚刚完成并将一个新的应用程序放在现有的生产系统上，但似乎已经放弃了从SAN获取备份的性能。 据我了解，SAN的镜像通常是在块级别上不断地进行的。 但是，似乎有太多新的写入磁盘，SAN镜像/备份过程不能再跟上。 我相信我已经缩小到了SQL Server tempdb，它存在于一个驱动器上，这个驱动器贡献了最大部分的问题！ 事实上，我认为无论我的应用程序，tempdb一直在贡献最大的问题！
因此，我的问题是临时数据库是否应该在SAN上进行镜像或支持，以及其他人是否已经经历过这种痛苦？ 我想知道是否确保tempdb 从不镜像在SAN上是一个最佳实践，因为任何对它的写入都不需要保存。 这也提出了一个稍微相关的问题 – 依赖于SQL Server内置的数据库备份工具（数据库处于完全恢复模式的全数据库/差异备份和事务日志备份）还是更好，或者像我们的应用程序一样，SQL服务器处于简单恢复模式，并且从未备份，因为SAN已被镜像和备份？
非常感谢
无需备份/镜像tempdb，因为无论如何都是在重新启动SQL Server时重新创build的。
另一方面，即使在镜像/ SAN复制可用的情况下，我仍然维持一个SQL备份周期作为恢复点 – 但这通常是因为SAN备份已由其他人pipe理，而我喜欢有一些bak文件，我可以轻松地进行testing恢复等工作
所有这一切，如果tempdb有很多写你应该尝试消除它们。 tempdb TRIES不写入光盘，它需要更多的页面比可用的内存。 很多时候，这是一个蹩脚的SQL的迹象，像剩余的DISTINCT子句（强制保留tempdb中的所有logging消除双打）。 不要总是说，但如果你有很多的tempdb写入，试着找出你是否真的需要它们。
tempdb不应该被镜像。