如果您有复制/高可用性解决scheme，那么使用它来避免停机是明显的select，一台服务器升级而另一台服务器正在运行，然后切换并升级下一台服务器。

如果你没有这样的结构，你可以在同一台服务器上做一个微型复制设置，在这台服务器上有两个数据库副本，一个在另一个工作时升级，然后同步旧的数据库。 这仍然需要一些停机时间，但不到4小时。

避免保持两个数据库同步的第三个选项是获取数据库的副本，而在维护一个数据库时，副本和使用它的应用程序处于只读模式。 完成后，只需将应用程序切换到升级的数据库，然后再开始写入数据库。

这最后一个选项当然需要应用程序支持，并且有意义（有只读模式没有意义的应用程序）。

如果您使用的是SQL Server，那么您始终可以从SQL Server 2000起在线执行索引碎片删除。 命令DBCC INDEXDEFRAG总是执行联机重组。 我专门写了一个DBCC DBREINDEX的在线替代scheme。

在SQL Server 2005以后，ALTER INDEX … REORGANIZE命令replaceDBCC INDEXDEFRAG，并始终在线。 同样在2005年以后，使用Enterprise Edition，您可以使用ALTER INDEX … REBUILD … WITH（ONLINE = ON）进行在线索引重build。 在操作的开始和结束时都需要一些非常短的表锁，所以它不像REORGANIZE那样在线（大部分在线索引重build不是一个很好的营销术语:-)。 您甚至可以使用CREATE INDEX … WITH DROP_EXISTING并指定ONLINE = ON将索引移动到新文件组。

谢谢

一般维护任务

如果您有数据库复制，大部分维护任务都可以在不使网站或应用程序脱机的情况下完成。 您将从副本集中删除一个数据库，应用您所需的数据，然后再将其连接到您的副本集。 当它closures时，其他数据库将保持解决scheme运行。

更改数据库模式

当您需要更新数据库模式时 ， 如果更改打破旧版本，您将被迫将解决schemeclosures几分钟（或只读状态）。 如果新的模式只是创build表或字段，它不会影响旧版本¹ ，所以这种模式更改可以在线²完成，并使用蓝绿部署为您的应用程序实现高可用性。

如果您的新架构重命名现有字段或将其删除，要达到100％的正常运行时间，则需要执行以下步骤：

重命名一个字段

1. 如果您需要从A重命名为B，请应用架构更改，以添加新的字段B并复制A内容。 另外，保持完好。
2. 部署使用字段B的新应用程序，不要使用字段A.
3. 应用删除A的模式更改

删除一个字段

1. 不要应用任何模式更改。
2. 部署一个不使用将被删除的字段的新应用程序。
3. 应用删除该字段的模式更改。

注1 ：一些ORM工具（如.NETentity framework）将每个模式更改与迁移ID相关联。 因此，当您部署新的模式版本时，旧的应用程序将立即中断。 如果您禁用此检查也是可以避免的。

注2 ：如果你的新模式添加了一个唯一的约束，检查或外键，如果你有一千行的话，alter table命令可能需要一些重要的时间。 当alter table正在处理时，即使对于select，该表也将被locking，这可能会导致某些查询超时，具体取决于数据的大小。

可用的选项很大程度上取决于您正在使用的数据库引擎。 您将首先采取必要的措施启用数据库的联机备份，最好在备份进行时允许写入。 这通常需要线性logging事务，这也使您能够通过事务日志向前滚动来将数据库恢复到特定时间点。

表和索引reorgs可能有点棘手，但希望您的数据库引擎允许在重新组织时对对象进行只读访问。 否则，您可能需要为您的应用程序提供一种临时使用表的只读克隆的方法。 如果你的DBMS提供的在线维护方式很less，你将不得不在应用层进行折衷，以便将其redirect到部分或完整的数据副本。

无论成本如何，数据库复制几乎总是一个复杂的function来pipe理。 更糟糕的是双向复制，即使在主数据库停机维护时，理论上也会使您的应用程序更改辅助数据库上的数据。 复制并不是不可能的，但是为了在生产中可靠地运行，需要进行大量的计划和testing。