跳到正文
其他数据库运维避坑案例整理
整理自用户提供的《新炬运维避坑指南合集》41
篇离线文章。按案例涉及的主要技术归类，归纳原文中的现象、排查处置和建议；案例措施仅代表原文环境，执行前应按当前版本、拓扑和变更流程复核。
共整理 15
个案例。期数按专辑标题编号；来源链接取自离线文章元数据。
查看或下载 Markdown 原稿
案例目录
第 29
期｜使用update global indexes索引仍会失效问题分析
- 专辑文件：
13.html，第 11 个案例
- 查看原文
- 现象： OB数据库中对于存在全局索引的分区表进行drop
分区时，使用；update global indexes；索引仍会失效。
- 处置过程：
某日对某OB数据库进行分区表例行维护时，发现某张分区表存在全局索引，于是加上了；update
global indexes；语句进行drop。
- 运维建议：
加强维护操作审核，理清传统O库运维与信创数据库运维的差别。；进一步与信创数据库厂商沟通，在信创数据库替换过程中，相关维护操作尽量减少功能性差异。
第 28
期｜datax数据库数据迁移效率大幅度降低
- 专辑文件：
14.html，第 7 个案例
- 查看原文
- 现象：
测试国产化数据库；迁移任务的时候，部分表出现了迁移速度变慢的情况，数据迁移效率大幅度降低。
- 处置过程：
复测加数据库监控的情况发现是写入速度慢；Task
waitwriterrime；795.956s
- 运维建议：
据目标数据库的特性进行针对性的优化和调整；本次测试过程中，我们深刻认识到不同数据源的写入读取组件存在显著的差异性。在国产化数据库迁移过程中，不能简单地将传统数据库迁移的经验直接套用，而需要根据目标数据库的特性进行针对性的优化和调整。；这一点在未来的迁移工作中必须引起高度重视
第 28
期｜datax数据库部分表迁移速度为零
- 专辑文件：
14.html，第 8 个案例
- 查看原文
- 现象：
测试国产化数据库；迁移任务的时候，发现有少量表；迁移速度为零，
- 处置过程：
通过writerThreadCount优化后，速度依然达不到迁移到oracle数据的时候；对比分析后，发现这些表中均有主键或者唯一约束；from
all constraints
- 运维建议：
深入了解不同；数据源内核逻辑差异；本次测试过程中遇到的问题和经验教训提醒我们，不同的数据源在写入和读取组件的内核逻辑上可能存在显著差异。因此，在进行数据库迁移或国产化替代时，我们不能简单地套用之前的经验或方案，而需要根据具体的数据源特性和需求进行针对性的优化和调整。
第
26
期｜MongoDB数据库MongoD数据库使用TTL索引，运行一段时间后，数据无法正常写入
- 专辑文件：
16.html，第 10 个案例
- 查看原文
- 现象：
当数据写入量达到一定值后，数据库开始出现OOM，监控系统显示内存、CPU和IO负载很高，会话连接不断增加且达到最大连接限制导致数据写入失败，业务无法正常运行。
- 处置过程：
通过故障排查，我们发现了几个关键问题；TTL删除延迟；在检查过程中，我们发现TTL索引未能及时清理过期数据，甚至15天前的历史数据仍然保留在数据库中。这种延迟导致数据库中积累了大量无用数据，消耗了存储空间并影响了性能。
- 运维建议：
业务方改用日表策略，即每日创建新的集合并启用分片策略，以便将数据分散到多个集合中。这种方法可以有效减少单个集合中的数据量，同时没有了TTL索引带来的IO负担。；使用脚本清理旧集合和创建新集合；在每天凌晨1点，执行定时脚本，自动删除两天前的旧集合并创建新集合和索引。
第 22
期｜万里数据库集群节点1状态异常
- 专辑文件：
20.html，第 10 个案例
- 查看原文
- 现象：
万里数据库集群节点1状态异常，业务切换到其他正常节点，通过重启节点1，无法加入集群，复制同步异常，怀疑触发mgrbug，晚上23点对集群全停全起后，3个节点状态恢复正常、同步恢复正常。
- 处置过程：
停掉所有节点的计算节点实例；启动所有节点的计算节点实例；重启sqlnode集群组复制，连接至任一sqlnode，调用以下函数即可
- 运维建议：
应急操作手册的重要性；在分布式数据库集群中，节点状态异常或复制同步问题可能会影响业务的连续性和数据一致性。；为了提高集群的可靠性，加强集群状态的实时监控，并配置自动化管理工具，帮助在节点状态异常时快速检测并采取相应措施。
第 21
期｜mongodb孤儿文档导致数据库迁移失败
- 专辑文件：
21.html，第 8 个案例
- 查看原文
- 现象： 使用mongoshake工具迁移mongodb
3.4分片集群数据到5.0，迁移过程中在目标端大量提示主键冲突。
- 处置过程：
验证数据，使用Objectid作为在源端分片集群的多个分片均能查到大量的相同数据，判定是存在孤儿文档。；采用mongoshake工具提供的方案修改参数文件mongo_connect_mode
= primary，问题依旧。；采用官方给的清理孤儿文档的方案
- 运维建议：
深入理解版本间差异与兼容性；加强版本知识；在进行数据库迁移之前，必须深入理解源数据库和目标数据库之间的版本差异和兼容性问题。MongoDB
3.4与5.0之间存在显著的差异，包括但不限于分片管理、数据清理策略、性能优化等方面。
第 20 期｜SQL运行超时问题
- 专辑文件：
22.html，第 4 个案例
- 查看原文
- 现象： 业务侧反馈SQL运行超时。；4.2
处；查看等待会话及等待事件
- 处置过程： 在中，观察到大量“direct path read
temp”和“direct path write
temp”等待事件，这通常是由于临时表空间与数据表空间共享同一磁盘资源导致的IO争用。通过将临时表空间建立在不同于数据表空间的磁盘组上，可以有效分散IO负载，提高数据库的整体性能。此外，合理的磁盘布局和配置也是确保数据库高效运行的关键因素。；存储资源评估与规划；在进行数据库设计时，应充分考虑存储资源的评估与规划。根据业务需求和性能要求，合理规划数据表空间、临时表空间、REDO
LOG等关键存储组件的布局和配置，以确保系统的高性能和可扩展性。
- 运维建议： 优化日志管理；增大REDO
LOG的容量；在处理SQL运行超时的问题时，发现大量“log file switch
checkpoint incomplete”事件是导致性能瓶颈的重要因素。这表明当前REDO
LOG的容量不足以应对高频率的日志切换。通过增大REDO
LOG的容量，可以有效减少日志切换的频率，从而避免因此类等待事件导致的性能下降。此外，合理配置REDO
LOG组的大小和数量，可以进一步提高数据库的健壮性和恢复能力。
第 20
期｜一体机计算节点扩容失败
- 专辑文件：
22.html，第 5 个案例
- 查看原文
- 现象： 一体机计算节点扩容失败。
- 处置过程：
新增节点前期环境配置（交换机端口、域名解析、用户属组、互信等）；；检查数据库备份；；拷贝GI软件；
- 运维建议：
深入了解版本限制与兼容性；在进行任何系统扩容或升级之前，深入理解当前系统版本的功能限制和兼容性至关重要；本案例中，由于未充分了解Oracle
RAC 19.5版本的节点数限制
第 20 期｜批量任务执行缓慢
- 专辑文件：
22.html，第 6 个案例
- 查看原文
- 处置过程：
业务反馈某批量任务近期相比之前延迟结束，需DBA分析根本原因，并给出。；收集统计信息，详细步骤如下；检查之前SQL的索引使用情况；
- 运维建议：
深入理解索引优化与选择；在处理类似批量任务延迟结束的问题时，首要关注的是SQL查询的效率。索引作为数据库优化查询速度的关键工具，其选择和使用直接决定了查询的性能。；当表拥有多个索引时，数据库优化器会根据统计信息和查询条件来选择最合适的索引。然而，如果统计信息过时或索引设计不合理，优化器可能会选择低效的索引，导致查询性能下降。
第 16 期｜dml执行报错问题分析
- 专辑文件：
26.html，第 2 个案例
- 查看原文
- 现象：
业务进行ddl后，马上dml报错。；SQL执行错误，当前SQL；insert into xxx
select
- 处置过程：
OB3版本schema刷新方式为异步；是DDL执行快，性能好；；是有可能获取到旧版本schema。
- 运维建议：
业务进行重跑即可，业务DDL和DML同一对象时，中间间隔最少秒级别时间，等待数据库进行DDL状态同步。；数据库版本进行升级至4.x版本。；业务在进行DDL操作后，可以设定一个固定的延时
第 16
期｜慢sql导致cpu使用率增长分析
- 专辑文件：
26.html，第 10 个案例
- 查看原文
- 现象： 数据导入过程中，CPU激增。
- 处置过程：
查看数据库活跃会话，发现活跃连接达到1000+。；查询sql连接，发现其中一条查询sql占用900+个活跃连接。；排查该sql查询慢的原因，发现查询的表没有索引，所以触发了900+次全表扫描，从而导致业务查询过程中cpu攀升。
- 运维建议：
对于被频繁查询的列添加适当的索引，尤其是查询条件中涉及的列。确保索引策略与查询模式相匹配，以最大限度减少全表扫描。；SQL重写；分析并重写效率低下的SQL查询，使用更高效的查询逻辑和结构。例如，避免不必要的子查询，使用更有效的连接
第 8
期｜PG数据库节点不可用处置
- 专辑文件：
34.html，第 3 个案例
- 查看原文
- 现象：
patroni数据库集群主节点正常，从节点丢失（并未丢失数据）。；集群主节点所有写操作都阻塞了。；数据库集群不可用。
- 处置过程：
经过分析etcd日志，明显的看到集群时间出错，用date查看集群时间发现ntp时间同步失败，导致集群节点时间不一致，最终导致集群崩溃，从而对外界造成集群的不可用。；修复时间服务器，并配置时间同步，保证时间同步一致。
- 运维建议：
严格按照官方集成进行集成，确保各节点时间一致。
第 6
期｜某系统数据库表误操作删除恢复
- 专辑文件：
36.html，第 5 个案例
- 查看原文
- 现象： 某系统数据库表被误操作删除。
- 处置过程：
业务告知不小心将一张业务表误删除了一些数据；；查看数据库日志，并没有找到相关的delete语句；；查看表的数据量，并不是很大；
- 运维建议：
对业务的用户权限应该进行更加细粒度的管理，规避业务出现的一些误操作。；在重要的系统安装WalMiner工具，减少恢复的时间。；备份很重要！
第 1 期｜Timesten连接风暴处置
- 专辑文件：
41.html，第 3 个案例
- 查看原文
- 现象：
切换完成后，备库为主库，观察数据库状态为IDLE状态(异常)，手动将库设置为active状态，但瞬间大量的应用连接导致连接风暴，导致数据库无法登陆，因未冻结HACS服务导致再次发生主备库切换，又因第一次主备库切换后当时的主库（现备库）已宕库，从而无法进行接管，；导致主备库都挂起
- 处置过程：
TT库连接数爆满(2000)，在这些连接中发现有大量清理table_xxxx表所致的latch等待。；操作引起应用进程弹性扩展导致TT
库连接数爆满，HACS因连接数爆满无法连接到TT库，以为TT库异常进而触发主备切换，第一次切换成功后，又出现短时间内应用连接风暴触发HACS进行第二次切换，导致TT库挂起。
- 运维建议：
约束业务侧清理操作时均放到晚上或者版本期间执行，并且减少单次提交数量(<1000)。；运维人员完善主备操作流程，在TT库发生主备切换后，检查数据库，HA服务状态观察正常之后冻结HA，防止HA软件自主判断导致数据库发生二次切换
，再恢复完成备库后在解冻HA服务。
第 1
期｜DB2数据库碎片过高导致数据库运行缓慢处置
- 专辑文件：
41.html，第 10 个案例
- 查看原文
- 现象：
收到数据库库会话数异常以及sql执行慢告警。；通过部署的db2pd-d库名-latch自动任务收集日志，发现问题发生时间点有大量的Latch；；通过部署的psmon工具报告，分析psmon报告发现有insertinto一张表次数多且等latch时间长；对表做runstats收集最新的统计信息后，发现此表的碎片非常严重；
- 处置过程：
针对当前问题以及现有条件，；目前最严重的问题；为insertinto时寻找空快导致latch过高，因此对表开append属性，每次insert直接到高水位线处即可解决insert的问题；
- 运维建议：
增加DB2碎片监控，并利用数据治理定期进行碎片整理。