本文转自墨天轮：https://www.modb.pro/db/1858459514144567296

大家好，我是 JiekeXu,江湖人称“强哥”，荣获 Oracle ACE Pro 称号，墨天轮 MVP，墨天轮年度“墨力之星”，拥有 Oracle OCP/OCM 认证,MySQL 5.7/8.0 OCP 认证以及 PCA、PCTA、OBCA、OGCA、KCP 等众多国产数据库认证证书,今天和大家一起来看看经验教训和常见误区是你所不知道的,欢迎点击最上方蓝字“JiekeXu DBA之路”关注我的微信公众号，然后点击右上方三个点“设为星标”置顶，更多干货文章才能第一时间推送，谢谢！

在数字化时代，数据库对企业至关重要，而 DBA 的工作并非一蹴而就，它是一项需要长期积累的专业性工作。在长期实践中，DBA 往往会面临复杂的运维挑战及各种各样的优化问题，从而积累专业经验，其中不乏一些具有代表性的失误和误区。

本期【专家有话说】系列专栏则邀请了四位具有多年 DBA 实战经验的专家 ：陈举超、JiekeXu、芬达和刘鹏程，为大家分享他们的深刻总结，希望能为广大的 DBA 同行们提供一面镜子，以此回顾和反思并从中获得启示，从而进一步优化自己的工作方法，避免重蹈覆辙。

编者按：本次邀约专家主要围绕以下两个问题展开分享，其中不乏惊心动魄的场景再现，更有痛定思痛的经验总结，希望能对大家有帮助：
1、在您的 DBA 生涯中，您遇到过最难忘的一次故障事件是什么？有什么经验教训？
2、在您看来，DBA 在日常工作中常见的操作误区有哪些？是否存在典型的错误思维方式？

🎙️陈举超

1、最难忘的一次故障事件及教训

最难忘的一次故障时间是刚参加工作时，做数据库管理员工作还没几天遇到的第一个生产变更。生产库是 Oracle 9i，要求清理核心交易分区表历史数据，备份出 3 年前的数据，然后删除，在这次变更中连续犯了 3 次错误：

第一，为了能早点下班，没到变更窗口时，就自做主张的开始了历史数据的备份操作，不出意外地很快就出现了意外，领导发现系统变慢、交易超时，然后就发现了我的操作，我立即终止了备份，系统也马上恢复了正常。

第二，本以为是虚惊一场，很快又遇到了第二个问题，终于等到变更时间，在执行表分区卸载操作时，发现语句执行失败，报语法错误？之前明明已经在测试库测试了很多遍？不对，测试库是 11g 版本，生产库是 9i 版本，测试和生产版本不一致！这可能是一个很严重的问题，因为有两种可能，一是 9i 和 11g 中同一个操作的语法不同，二是 9i 没有这一功能，如果是第二种情况，意味着今晚的变更方案要大改甚至无法执行。不过还好，是第一种情况。

第三，发现报语法错误后，马上在网上寻求答案，当时还不知道官方文档为何物，很快我搜到了一大堆驴唇不对马嘴的文章（这也是后面开始自己写技术文章的一个原因），都解决不了我的问题，而领导已经第二次催我进度了，只能硬着头皮尝试修改 SQL 。在生产库上尝试调整 SQL 的几个关键字后，居然执行成功了，验证也没什么问题，但这个操作在后面想起来还是有些后怕，在生产库执行不熟悉的命令，很可能会产生不可预期的结果，如果不小心删多了数据，可能就要换行业了！

那么通过这次变更，我得到了哪些教训呢？

• 第一，上学时经常做化学实验，记忆深刻的是“单一变量原则”，为了观察某个变量的影响，要尽量控制其他变量保持不变，而在这次数据库变更中，我却忽略了最大的一个因素：数据库版本！这也让我意识到测试环境准确性的重要性。

• 第二，不要轻易在生产环境执行不熟悉的命令，更不要轻易相信网络上的技术文章，没经过自己实际测试验证过的，一切都应该保持怀疑态度。

• 第三，对数据库要有敬畏之心，尊重每一个变更规定，这些规定都是从各种生产事件教训中总结出来的，不要再跳进去了。

2、常见操作误区与典型错误思维

不要过度优化！！！

可能有些朋友看见 Top SQL 就想优化、看到全表扫描就如临大敌，想着自己大显身手的时候到了，然后统计信息、直方图、执行计划 …一顿操作花费了几个小时，结果收效甚微（还可能产生其他影响），最后和业务沟通后才发现这个 SQL 原来是因为某个产品 bug 生成的，在修复了 bug 、取消 SQL 执行后效果立竿见影。

实际上，我想说的是处理问题的顺序问题，是看见业务慢 SQL 就马上闷头去优化；还是先联系应用或开发人员分析慢 SQL 来源、执行频率、影响范围、业务场景等，最后再考虑是否需要 SQL 优化、优化操作的影响、何时优化、怎么优化，我想后者更为合理。

🎙️芬达

1、最难忘的一次故障事件及教训

在数据库管理领域，精确性不仅是一种要求，更是一种责任。回想职业生涯的早期，大约在 2010 年，那时我主要从事 Linux 系统运维工作，并初步接触了一些关系型数据库，如 MySQL、PostgreSQL、SQL Server 等。到了 2017 年，我全职转型成为一名 MySQL DBA。然而，就在第一年，我犯了一个严重的错误——误删了数据库。当然，我并没有跑路。

从这次事件中，我深刻认识到，在多人协作的环境中，工作交接时必须仔细检查和核对，避免因交接疏漏导致的错误。这有点像 AI 的思维链：如果第一步的正确性是 95%，第二步也是 95%，那么到了第十步，正确性可能只有 60% 了。在生产环境中，这是无法接受的。为了确保每一步都是 100% 正确，交接工作时必须认真检查上一位同事的内容。

2、常见操作误区与典型错误思维

在 DBA 的日常工作中，一个常见的误区是将故障现象当作故障原因，这完全是本末倒置。举个例子，有些 DBA 看到 thread_running（并发运行线程数）很高，就会告诉开发人员是高并发导致了 CPU 负载过高，进而引发业务故障。但实际上，可能是因为 CPU 负载先升高，导致没有足够的 CPU 时间片分配给连接线程，造成线程阻塞，进而导致 thread_running 数值升高。

此外，一些 DBA（当然也不止是 DBA）过于依赖搜索引擎上的信息，特别是百度。然而，我甚至见过百度上 90% 的答案都是错误的案例。比如，搜索“xtrabackup 和 innobackupex 的区别”时，仍能看到许多文章声称 innobackupex 是封装了 xtrabackup 的 Perl 脚本。但实际上，从 2016 年开始，innobackupex 和 xtrabackup 就是同一个东西，是同一个用 C 语言编写的程序，innobackupex 只是 xtrabackup 的一个软链接。学习一门新技术的最佳方法是看官方文档。

🎙️JiekeXu

1、最难忘的一次故障事件及教训

记得在刚毕业的两年时间里，刚跳槽去新公司不久，被分配了一批十几套的 Oracle RAC 打补丁，虽是第一次干，但庆幸有现成的文档可以参考，直接按照文档操作就可以。当时已经打了好多套的补丁，Linux、UNIX、AIX 都打过了，心想应该没啥问题，但是还是出现意外了。一套核心的 AIX 系统上的 11204 RAC 在打补丁时由于根目录空间不足补丁执行失败，GI 无法启动，就连集群管理命令都全部失效了，补丁更无法回退，也没有任何备份，而且这套系统当时是有 80 多 TB 的数据，而且没有开归档没有备库，那就更没有备份。这下变的好慌呀，因为业务还在另一节点跑着，如果当晚搞不定，白天业务上来一个节点撑不住那么问题就大了。打补丁把系统打崩了，任何集群命令都用不了，asmcmd 也用不了，着实废了，当时网上连打补丁的文档都没几个，更别说处理这种故障了，搜寻 MOS 也是无果，幸好有 ACS 原厂高服支持。当时协调来了一个 O 记年纪较大的人晚上七八点到达现场，我们一起排查处理，折腾了好几个小时，从 SCP 节点一的软件到节点二，做relink all等等，尝试了各种办法均没有解决。在 SCP 的过程中由于文件系统中 audit 目录下的审计文件数数量巨大，整个 SCP 操作也花费了很多时间。最后在凌晨三四点左右，由于实在困得不行休息了半个小时左右，放空了下大脑，最后通过清理环境添加节点的方式成功恢复了故障节点，做完这一切大概也快到上班时间了，等到上班时间同事来了简单交接后才回家补觉。

这一次故障给我的深刻教训有以下几点：

1）对于打补丁来说，一定要看靠谱的文档，不能随便百度一下，更要结合补丁 readme 来进行操作。

2）打补丁之前的备份很重要，这里不仅指数据库备份，更是指的 OS 级别的软件和配置文件备份。

3）打补丁之前的检查更重要，比如补丁冲突检测，磁盘使用率检查等，当然这些检查项后来 O 记都已经更新到后面版本的 readme 文档里了。

4）对于本次事件来说，细心也很重要，在 SCP 过程中没有想到去看输出，等了好长时间才记起来 audit 审计目录中存在巨大的小文件影响 SCP 的传输，更没有提前排查与清理。

5）最后一个则是大脑超负荷运转，凌晨三四点的时候非常困了，没有良好的休息就没有高效的工作，要是早点休息好，可能会想到更多的解决方案。

2、常见操作误区与典型错误思维

我认为在 DBA 的日常工作中，有几个常见的操作误区：

1）对于生产环境和测试环境区分不清楚，可能会错误的以为登录的环境是测试库进行相关的变更操作，实际是生产环境带来不可估量的损失。

2）没有备份或备份策略不合理，导致数据丢失后难以恢复，带来不可估量的损失。

3）使用默认参数配置安装生产库，导致性能低下，资源浪费。

4）使用软件基础版本安装数据库，缺少补丁更新，带来安全隐患。

典型的错误思维方式有：

1）忽视团队合作与沟通，DBA 的工作往往需要与其他开发人员、IT管理人员紧密协作，如果忽视这一点，可能会导致项目进展受阻或解决方案实施效果不佳。

2）对新技术过分保守或过分激进，过于保守，不愿意尝试可能有助于提升性能的新技术和方法；或者相反，过于激进地采用未经充分测试的新技术，可能导致稳定性问题。

3）性能调优只关注单个方面，忽略整体，只关注数据库层面的优化，忽略了操作系统、存储、网络、应用程序代码等因素对整体性能的影响。

🎙️刘鹏程

1、最难忘的一次故障事件&经验教训

聊到 DBA 生涯中最难忘的经历，还真有一件。依稀记得，那会儿刚入行，假期帮客户做一个数据归档，由于沟通不充分，需求临时变更，加上对命令不熟悉，导致生产数据被覆盖了部分，熬了两个通宵，废了九牛二虎之力才把数据恢复回来。

这次事件让我痛定思痛，总结了以下经验教训：

• 工作留痕：需求沟通一定要仔细，过程留痕，确认需求尽量使用邮件；

• 量力而行：计划或者能力之外的事情，轻易不要做；

• 三思后行：生产操作需要再三确认，命令需要理解透彻，先测试再正式；

这次经历之后，我取了个网名：Lucifer三思而后行，开始记录和分享工作中的一些实战经验以及技巧。

2、常见操作误区&典型错误思维

在多年数据库运维中，我还发现不少 DBA 存在一些典型误区和错误思维：

• 灾备恢复：认为备份万无一失，但没有定期验证备份的可用性。事实上，备份的有效性和恢复速度是数据安全的关键。

• 盲目操作：通过百度搜索或者前辈留下的操作步骤，未经充分验证就直接在生产环境中操作。没有充分理解命令就执行，容易导致数据丢失或系统故障。

• 权限控制：为图方便，给用户直接分配 DBA 权限，会增加误操作和被攻击的风险。

• 监控告警：未能及时配置告警机制，忽略日常监控，导致在问题恶化到严重程度之前未能及时响应。

• 过度自信：对自己的技术能力过于自信，认为不会犯错，从而在关键操作前不进行充分验证或测试。

• 轻视沟通：忽略与业务团队的沟通，认为数据库问题只是技术问题。但业务需求往往影响数据库的设计和操作，忽视沟通容易导致需求偏差。

• 短期应急：习惯采用临时解决方案应对突发问题，而不追求长期改进，导致问题反复发生，增加维护成本。

以上仅为个人经验，与君共勉，愿永不宕机！

希望这篇文章能为各位 DBA 朋友提供参考和帮助，让我们一起在守护数据库的道路上，以敬畏之心对待每一个操作，以严谨之态应对每一个问题。DBA 们，加油前进吧！

全文完，希望可以帮到正在阅读的你，如果觉得有帮助，可以分享给你身边的朋友，同事，你关心谁就分享给谁，一起学习共同进步~~~

分享几个数据库备份脚本

一文搞懂 Oracle 统计信息

我的 Oracle ACE 心路历程
MOP 系列|MOP 三种主流数据库索引简介
Oracle 主流版本不同架构下的静默安装指南
关机重启导致 ASM 磁盘丢失数据库无法启动
Oracle SQL 性能分析(SPA)原理与实战演练

Oracle 11g 升级到 19c 需要关注的几个问题
Windows 10 环境下 MySQL 8.0.33 安装指南
SQL 大全（四）|数据库迁移升级时常用 SQL 语句
OGG|使用 OGG19c 迁移 Oracle11g 到 19C(第二版)
Oracle 大数据量导出工具——sqluldr2 的安装与使用
Oracle ACE 视角下的国产数据库现状与选型及应对策略
从国产数据库调研报告中你都能了解哪些信息及我的总结建议
使用数据泵利用 rowid 分片导出导入 lob 大表及最佳实践
在归档模式下直接 rm dbf 数据文件并重启数据库还有救吗？