我是一名软件开发人员，兼职担任 DBA 一职。我负责 SQL Server 2008 上一个小型、高容量、全天候运行的数据库的应用程序后端。
虽然数据库中还有其他内容，但关键部分是一个 50GB、7.5M 行表，在高峰负载期间每秒处理 100K 个请求，而在“夜间”处理大约一半的请求。这是 99% 以上的读取流量，但写入是持续的，并且是必需的。
我需要能够在没有维护窗口的情况下执行定期维护。比如索引重建、清除旧数据、Windows 更新或硬件升级。我看到的大多数建议都是“设置维护窗口”。虽然我理解这种想法，但我希望还有其他方法。如果它能解决这个问题，我确实有能力购买新硬件或修改数据库、客户端（一组 Web 服务服务器）和大部分应用程序代码（ADO.NET + ASP.NET）。
我一直在考虑使用热备用服务器（或第三台服务器）进行维护，然后将其“交换”到生产中。1
通过恢复备份（包括当前事务日志）同步备用服务器。2
执行维护任务。3 重新配置客户端以连接到备用服务器。现有连接在一分钟左右内完成。4 备用服务器现在是生产服务器。
剩下的问题是，无论维护需要多长时间，新的生产服务器现在都已经过时了。有没有办法让原始生产服务器排队更改并在步骤 2 和步骤 3 之间将它们合并到备用服务器？还有其他想法吗？
答案1
您需要了解 SQL 2008 提供的高可用性功能。请参阅这里白皮书中没有涵盖太多场景。
[爬上肥皂盒]
不过，您确实需要维护时段。这并不意味着每周或每月，但有时您需要停机进行改进。很少有系统可以在很长一段时间内（数年）100% 运行，或者需要如此。维护时段的目的是尽量减少停机时间并使其可预测，以便企业能够应对。我建议不要完全忽略维护时段。如果您确实通过迁移到集群或类似方式更改配置，那么在过渡期间您肯定会有一些停机时间，无论时间多短。[爬回下坡]
一些选项：
- 镜像
- 聚类
- 日志传送
- 在线索引操作
- 使用在线索引操作和分区表进行归档
- 点对点复制
我的看法。
答案2
我赞同镜像并指出如果你真的需要 24/7 的服务，公司应该增加预算来聘请 DBA 或顾问来帮助解决这个问题。
多次镜像可以“足够好”地解决全天候需求，而且除了第二台服务器之外，成本极低。
答案3
由于该数据库是基础设施的重要组成部分，因此无论如何都建议使用热备份。这也将使您能够进行维护。