恐怕我对 SAN 了解不多，所以请原谅我缺乏细节或技术术语。
作为一名开发人员，我刚刚完成并在现有生产系统上安装了一个新的应用程序，但它似乎已经改变了从 SAN 进行的备份的性能。据我所知，SAN 的镜像通常以块级持续进行。但是，似乎有太多新的写入到磁盘，SAN 镜像/备份过程无法跟上。我相信我已经将问题缩小到 SQL Servers tempdb，它存在于导致问题最大部分的驱动器上！事实上，我认为无论我的应用程序是什么，tempdb 一直是导致问题最大部分的原因！
因此，我的问题是，是否应该在 SAN 上镜像或备份 tempdb，以及是否有其他人已经经历过这种痛苦？我想知道确保 tempdb 是最佳做法吗？绝不在 SAN 上镜像，只是因为对它的任何写入都不需要保存。这也提出了一个稍微相关的问题 - 是依靠 SQL Server 内置数据库备份工具（数据库处于完整恢复模式，具有完整/差异和事务日志备份）更好，还是像我们的应用程序一样，SQL Server 处于简单恢复模式，并且从不备份，因为 SAN 是镜像和备份的？
非常感谢
答案1
您根本不需要备份/镜像 tempdb，因为它会在重新启动 SQL Server 时重新创建。
另一方面，即使在我可以使用镜像/SAN 复制的情况下，我仍然会维护 SQL 备份周期作为万全之策的恢复点 - 但这通常是因为 SAN 备份已由其他人管理，而我喜欢有一些可以轻松用于测试恢复等的 bak 文件。
答案2
综上所述，如果 tempdb 有大量写入，则应尝试消除它们。tempdb 尝试不写入磁盘，只有在需要的页面多于可用内存时才会这样做。这通常是糟糕的 SQL 的标志，例如多余的 DISTINCT 子句（强制将所有记录保留在 tempdb 中以消除重复）。不是说总是这样，但是如果您有很多 tempdb 写入，请尝试找出您是否真的需要它们。
答案3
tempdb 不应被镜像。