数据库管理299期 2025-03-06

• 数据库管理-第299期 数据库是否需要定期重启（20250306）
• 1 商业数据库
• 2 必须重启数据库的场景
• 3 数据库重启带来的风险
• 4 最佳实践
• 总结

数据库管理-第299期 数据库是否需要定期重启（20250306）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Pro: Database
PostgreSQL ACE Partner

10年数据库行业经验
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP，ITPUB认证专家
圈内拥有“总监”称号，非著名社恐（社交恐怖分子）

公众号：胖头鱼的鱼缸
CSDN：胖头鱼的鱼缸（尹海文）
墨天轮：胖头鱼的鱼缸
ITPUB：yhw1809。
除授权转载并标明出处外，均为“非法”抄袭

在我的数据库维护生涯中，除了打补丁过程中的“被迫重启”以外，其实很少主动去通过重启数据库解决问题。但在一些特定的场景下又不得不通过重启（甚至是强制重启）来解决特定的问题。最近了解到，数据库的定期重启是一些地方日常操作，理由主要是长时间运行肯定会累积问题，我认为这是不大合理的。本期从两个维度来看待数据库是否需要重启：一是重启数据库的必要性和场景；二是重启数据库是否该成为一个定期的常态化维护操作。

1 商业数据库

首先对于以Oracle为例的商业数据库通常是不需要定期重启的，其设计的目标之一就是支持7×24的长期稳定运行，下面以Oracle为例说明没有必要定期重启数据库的原因：

1. 高稳定性设计
   Oracle通过后台进程（如PMON清理异常会话、SMON处理实例恢复）和自动内存/存储管理，有效避免了资源泄漏和性能退化。
2. 在线维护能力
   • 自动维护任务：通过自动维护任务自动完成统计信息，并进行空间和调优建议，减少手动干预需求
   • 存储扩展：表空间、数据文件可在线扩展或迁移
   • 补丁应用：部分补丁可以实现无需停机的在线应用
   • 维护操作：可通过手动方式处理大多数异常
3. 高可用
   • RAC可以避免单点故障对整个数据库的影响，但是节点异常/重启仍可能导致服务切换
   • DG可以提供数据的异地容灾和切换能力，ADG增加了读写分离能力
4. 资源管理
   • 内存管理：ASMM（自动共享内存管理）根据数据库使用动态调整SGA各组件内存分配
   • CPU/IO：可以通过Resource Manager实现资源的静态/动态管理与隔离，避免资源异常消耗的出现影响整个数据库

其实很多以替换Oracle为目标诞生的数据库和一些优秀的开源数据库也是具备上面这些特性的。

2 必须重启数据库的场景

文章一开始也说过，一些特定场景下是必须重启数据库的，下面进行一个简单的归纳：

1. 关键补丁或升级
   某些内核级补丁（如CPU补丁）或大版本升级可能要求重启数据库实例。
2. 严重故障恢复
   例如：内存泄漏、关键后台进程异常（如LGWR挂起）且无法通过SQL或操作系统命令等常规操作修复。
3. 操作系统/硬件维护
   如服务器非热插拔硬件更换、操作系统升级等底层维护需停机。
4. 其他
   在当前情况下出现无法通过重启以外方式解决特定问题的情况。

3 数据库重启带来的风险

首先必须说明一点，即便是使用高可用集群的数据库，节点（也就是实例级）的正常/非正常重启也是可能带来影响的。

1. 连接重载
   以Oracle为例从客户端发起请求到与数据库完成连接是一个非常耗时和系统资源的过程，重启实例后需要在短时间内重新建立大量连接，这期间可能触发连接风暴影响整个节点的稳定性
   
2. 内存重载
   以Oracle为例，重启数据库的过程会清理SGA中最重要的Buffer Cache和Shared Pool。重启后需要耗费大量的IO资源重新缓存数据；也需要一段时间的运行或网络IO来重建Plan Cache，期间性能会产生波动/下降。
   
3. 集群波动
   对于大多数集群来说，重启节点会触发集群级别的重配置操作，这一操作主要是为了确保集群的一致性和完整性，避免出现脑裂和数据错误。
4. 应用影响
   重启数据库实例势必造成应用至数据库的部分连接中断，应用需要完成重连重试的操作，并可能影响后续的线性操作，带来应用前台感知的影响。同时一些重要或实时同步的业务，需要考量数据库重启带来的影响。
5. 其他
   • 一些特定的环境，数据库关闭可能带来无法启动的问题的
   • 某些数据库的部分参数配置仅在内存中生效，重启后需要重新配置

4 最佳实践

• 避免计划外重启：优先通过日志分析（数据库日志、性能报告等）定位问题，采用在线修复手段。
• 制定维护窗口：如存在必须通过重启解决的问题，应在业务低峰期进行，并提前进行相关测试，通知业务侧做好监控与准备，即使处理数据库重启中遇到的问题，降低影响。重启的目的是为了避免再次出现计划内/外的重启。
• 监控长期性能：使用工具监控性能趋势并使用在线操作的方式进行优化，而非依赖重启作为优化手段

总结

数据库的架构设计使其无需定期重启即可保持稳定性。重启应视为“最后手段”，仅在特定维护或故障场景下执行。常规运维应依赖其内置的自动化机制和在线管理功能，以确保高可用性和业务连续性。
老规矩，知道写了些啥。