如果把时间往前推几年DBA 的技术栈其实相对稳定。Oracle DBA 主要围绕 SQL、执行计划、AWR、ASH、RAC、Data Guard、RMAN、ASMMySQL DBA 则会关注复制、InnoDB、慢 SQL、锁、Buffer Pool、备份恢复。再往外扩一点无非是 Linux、Shell、Python、监控和自动化。这些东西当然还在而且以后也不会突然消失。但这两年一个新的变量已经很明显地进入 DBA 的工作AI。现在遇到一条陌生 SQL很多人已经习惯先扔给大模型看看Oracle 报了一个不熟悉的 ORA 错误也会顺手把错误堆栈贴进去问一下写 Shell、Python、Ansible甚至整理故障报告和巡检结果都开始大量使用 AI。我自己越来越明显的感受是AI 对 DBA 的影响可能不会表现为“突然有一天不需要 DBA 了”而是先从大量具体工作里一点点渗透进来。以前需要 30 分钟完成的事情现在可能 10 分钟就能做完以前需要自己查半天资料的问题现在 AI 可以先帮我们把排查范围缩小以前不太愿意写的 Python 和前端代码现在也敢直接动手了。这种变化看起来没有那么戏剧化但长期累积下来对工作方式的影响可能比想象中更大。DBA 其实非常适合使用 AI仔细看一下 DBA 平时在做什么会发现很多工作都有一个共同特点信息很多而且非常分散。一条 SQL 为什么突然变慢我们可能要看 SQL Text、Execution Plan、Bind、Statistics、Index、ASH、AWR还要和昨天的执行情况做比较。一次 Oracle 故障为什么发生可能要翻 Alert Log、Trace、操作系统日志、监控指标再去 MOS 找相关文档同时回忆以前有没有碰到过类似问题。Data Guard 延迟了也不能看到 Apply Lag 就直接下结论。到底是日志传输慢、MRP 应用慢、Archive Gap、网络问题还是备库 IO 出现瓶颈需要继续收集证据。DBA 真正做的事情很多时候并不是“执行一条命令”而是在大量零散信息中建立关系然后判断什么才是最可能的原因。这一点恰好和今天大语言模型擅长的方向有不少重合。它很擅长处理文本、整理上下文、归纳信息、解释代码也可以通过 Tool Calling 获取外部数据。再加上 RAG它还能查询企业自己的历史资料。这意味着 AI 和 DBA 的结合点其实很多并不只是“帮我写一条 SQL”。先看一个最现实的 SQL 性能问题假设业务突然反馈生产数据库今天很慢。传统排查并没有问题。DBA 登录数据库先看当前负载和 Active Session再看 Top Wait Events。如果发现某条 SQL 占用了大量 DB Time就继续获取 SQL Text、执行计划和运行统计检查表和索引再和历史执行计划比较。如果发现昨天还是 Plan Hash Value A今天突然变成 Plan Hash Value B接下来还要继续判断为什么变了是统计信息、Bind、数据分布还是其他因素导致。这个过程里真正体现 DBA 水平的是最后的分析和判断。但前面有大量工作其实很机械。查 SQL 要执行一组 SQL查执行计划又是一组查 Index、Statistics、AWR、ASH 还是固定动作。拿到结果以后还要复制、整理再把这些信息拼起来。如果把这些能力封装成工具AI 完全可以先完成第一轮数据收集。DBA 只需要给出一个 SQL_ID系统自动获取 SQL Text、Execution Plan、运行统计、相关索引、对象统计信息和历史执行计划再把关键 AWR、ASH 数据一起组织起来。AI 根据这些证据生成第一版分析DBA 再判断它的结论是否成立。如果把两种工作方式放在一起比较差异其实很明显。传统模式下DBA 不仅负责最终判断还要亲自完成大量信息收集和整理引入 AI Agent 后这部分机械工作可以逐渐交给系统DBA 把更多精力放在证据判断、方案选择和风险控制上。这也是我认为 AI 对 DBA 最现实的价值之一。它首先替代的不是 DBA 的判断而是判断之前那些重复的数据搬运工作。故障处理可能更适合 AI再看另外一个 DBA 经常遇到的场景。假设凌晨收到ORA-01555: snapshot too old有经验的 DBA 看到这个错误大概已经知道应该往 UNDO 和长时间一致性读的方向检查。但真正处理时仍然要看现场。SQL 到底跑了多久UNDO 表空间多大UNDO_RETENTION是多少V$UNDOSTAT怎么样有没有大量并发 DML是不是某个报表 SQL 运行时间突然从几十分钟增加到了几个小时除此之外我们可能还需要去内部知识库找以前的处理记录。问题是很多企业的历史故障资料非常分散。一部分在 Wiki一部分在 Word一部分在共享盘还有一些可能只存在某个 DBA 的个人笔记里。最尴尬的情况就是我明明记得两年前处理过一次几乎一样的问题但那份文档到底放哪了这时候 RAG 的价值就出来了。AI 不仅可以查询当前数据库状态还可以从内部知识库里找到过去的 ORA-01555 案例、UNDO 运维规范和相关 SOP再把实时数据与历史经验放在一起分析。如果系统发现当前问题和某次历史事故高度相似还可以直接把那次事故的根因、处理方法和验证结果一起提供给 DBA。这已经和普通的“问 ChatGPT 一个 Oracle 问题”完全不同了。前者依赖通用模型已有的知识后者开始使用企业自己的数据库经验。而企业真正有价值的 DBA AI我认为迟早会走到这一步。AWR 也是一个很典型的例子AWR 是 Oracle DBA 非常熟悉的东西。一份 AWR 报告可能几十页甚至上百页里面包含 Load Profile、Top Timed Events、SQL ordered by Elapsed Time、SQL ordered by CPU Time、IO、Memory、Segments、RAC 等大量信息。有经验的 DBA 不会从第一页开始逐行阅读。通常会先建立整体判断DB Time 是否异常AAS 多大DB CPU 占比怎么样主要等待事件是什么负载与历史相比有没有明显变化然后再继续定位 Top SQL 和具体资源瓶颈。这里其实很适合 AI。但真正合理的做法并不是简单把整份 AWR 扔给大模型然后问一句“帮我分析”。更好的方式是先把 AWR 结构化解析提取关键指标再让系统根据当前问题决定还需要查看哪些章节。如果发现某条 SQL 占了 60% 的 DB Time就进一步获取它的执行计划、运行统计和对象信息。最后 AI 输出的也不应该只是一段“数据库负载较高建议关注 Top SQL”这样的套话而应该给出能够被 DBA 验证的证据。比如本时段 DB Time 相比正常基线增加了多少主要增长来自哪个 Wait Event哪几条 SQL 贡献最大这些 SQL 的执行计划有没有发生变化。做到这一步AI 才开始真正帮助 DBA 分析 AWR而不是简单帮我们总结一个 HTML 文件。AI 对 DBA 最大的价值可能不是“知道得更多”现在的大模型确实知道很多 Oracle、MySQL 和 Linux 知识。但如果只是比谁记得更多我并不觉得这就是 AI 对 DBA 最大的价值。真正让我觉得有意思的是它有机会把以前彼此独立的信息连接起来。数据库实时状态是一块Prometheus 监控是一块AWR 是一块SQL 和执行计划是一块Alert Log 是一块内部故障案例又是另外一块。过去这些信息往往需要 DBA 自己来回切换工具然后在脑子里建立关系。如果以后有一个 DBA Agent 能够同时访问这些数据源工作方式就会发生明显变化。比如业务反馈“数据库慢”Agent 可以先读取监控确认问题发生的准确时间再查看对应时间段的数据库负载和等待事件。如果定位到某条 SQL就继续获取执行计划和历史表现同时检索内部知识库看看以前有没有出现过相似情况。最后交给 DBA 的不再是几十张监控图、几份报告和几千行日志而是一条已经整理好的证据链。发生了什么哪些数据支持这个判断最可能的原因是什么还有哪些地方需要进一步确认。DBA 再基于这些证据做最终判断。这比单纯让 AI“懂 Oracle”有价值得多。AI 会不会替代 DBA这是讨论 AI 时绕不开的问题。但我觉得把它简单回答成“会”或者“不会”意义都不大。如果把 DBA 的工作拆开来看趋势其实已经比较清楚。查表空间、查 Session、检查备份、整理 AWR 指标、生成巡检报告这些标准化程度比较高的工作本来就一直在被自动化。以前我们写 Shell、Python 和 SQL 脚本解决这些问题。AI 出现以后只是让自动化可以继续往分析层走。举个最简单的例子。传统监控发现DATA 表空间使用率达到 96%。脚本的任务基本完成了。它按照预先定义好的阈值触发告警然后通知 DBA。但 DBA 真正想知道的往往还有很多这个表空间为什么突然增长最近 30 天增长速度怎么样按照当前趋势还能用多久数据文件是否开启 Autoextend距离 Maxsize 还有多少底层文件系统或 ASM Diskgroup 是否还有空间这些问题以前需要 DBA 收到告警后继续查询。以后完全可以让 Agent 自动完成第一轮检查再把结果交给 DBA。所以 AI 最先改变的很可能不是那些需要复杂经验的工作而是判断之前的大量准备工作。如果每天有两个小时花在收集数据、整理日志和生成报告上而 AI 能把它压缩到二十分钟那么一年下来产生的变化已经很大。真正容易被替代的是机械操作很多 DBA 会担心 AI 越来越强以后岗位会不会消失。我反而觉得可以换一个角度看。如果一项工作能够完整写成固定步骤而且每一步都没有多少判断空间那么即使没有 AI它迟早也会被传统自动化替代。例如每天早上登录 20 套数据库执行同样的 SQL检查表空间、备份、DG 延迟然后把结果复制到 Excel。这种工作真正的问题并不是 AI。它本来就应该自动化。AI 带来的变化是一些过去不容易通过IF/ELSE写死的分析工作现在也开始具备自动化的可能。比如两条告警是否来自同一个根因一份 AWR 中哪些指标值得优先关注一条慢 SQL 应该继续检查统计信息还是先检查锁等待。这些工作仍然需要专业知识但 AI 可以承担越来越多的第一轮判断。DBA 的精力也会逐渐从“执行固定步骤”转向“审核证据和处理复杂问题”。但 DBA 使用 AI 有一个很大的坑AI 最大的问题之一是它可以非常自信地说错话。这件事在普通场景里可能没那么严重到了数据库生产环境风险会被明显放大。它可能告诉你一个不存在的 Oracle 参数也可能给出不适用于当前版本的命令甚至可能把一条高风险操作描述得非常合理。假设模型告诉你这个问题可以通过修改某个隐藏参数解决。回答写得很专业参数解释、修改命令、注意事项都有。但那个参数实际上是模型编出来的。如果只是写文章最多闹个笑话。如果 DBA 直接拿去生产执行问题就完全不同了。所以我并不认同“有了 AI以后数据库知识不用学那么深了”这种说法。我的判断恰好相反。AI 越强使用它的人越需要具备判断能力。以前不会的东西我们知道自己不会所以会去查 Oracle 官方文档、MOS 或者做测试。AI 的迷惑性在于它有能力把错误答案写得非常像正确答案。这也是为什么后面做 DBA Agent 时我们会一直强调证据来源、权限控制和人工确认。能从数据库真实查询的数据就尽量不要让模型猜能从企业知识库检索的内容就尽量提供来源涉及生产变更时不应该因为 Agent 判断“应该执行”就自动执行。AI 可以帮我们缩小排查范围但最终的生产责任不会因为接入了一个大模型就消失。AI 不应该直接拿到 SYSDBA如果以后真的开始做 DBA Agent我觉得第一条原则就应该是先做只读再谈自动执行。比如给 Agent 提供这些能力查询数据库状态查看表空间查看 ASM查询 Active Session查询 Blocking Session获取 Top SQL获取执行计划检查 RMAN检查 Data Guard这些已经足够做很多事情。而且工具背后的 SQL 最好由 DBA 提前定义并审核Agent 只负责决定什么时候调用而不是允许它自由生成任意 SQL 然后直接在生产执行。这和我们设计数据库权限其实是同一个思路。一个应用只需要查询几张表就没必要给 DBA 权限一个 Agent 只需要检查数据库状态也没必要给 SYSDBA。最小权限原则到了 AI 时代并没有失效反而更重要。DBA 到底应该把 AI 学到什么程度如果目标是转算法工程师那当然需要深入数学、模型训练和算法。但如果目标是 AI DBA我认为学习重点可以分得很清楚。前面的基础原理需要懂。Model、Training、Inference、Token、Embedding、Transformer 这些概念至少要知道大概在做什么。我们不需要自己推所有公式但不能完全不知道模型下面发生了什么。到了 AI 应用层就要开始真正动手。Prompt、Context、RAG、Vector Search、Agent、Tool Calling、MCP这些东西和企业 AI 落地关系很大值得 DBA 花更多时间。最后才是最重要的 DBA 实战。怎么把 SQL、AWR、数据库监控、故障案例、SOP 和数据库只读工具接进来让 AI 不只是会解释 Oracle而是真的能够使用我们自己的数据库数据。这也是整个《DBA 学 AI》系列后面的主线。我最期待的不是 AI 帮我写 SQL如果只是让 AI 帮忙生成几条 SQL我觉得这件事情很快就会变得普通。我真正期待的是另一个场景。凌晨收到数据库性能告警。在 DBA 打开电脑之前系统已经把异常时间段的监控指标、数据库负载、Top Wait、Top SQL、执行计划变化和历史故障案例收集好了。打开页面以后看到的不是几十张监控图和几千行日志而是一份已经整理好的分析。什么时候开始异常和正常基线相比发生了什么变化主要等待集中在哪里哪些 SQL 最值得关注历史上有没有出现过类似问题当前有哪些结论已经有证据支持还有哪些地方需要 DBA 进一步确认。DBA 根据这些证据做最终判断。如果能做到这个程度AI 对 DBA 的意义就不只是“提高一点写 SQL 的效率”。它开始真正改变数据库运维的工作方式。当然要走到这一步只会调用一个大模型 API 显然不够。我们还需要理解模型、Token、Embedding、Transformer、RAG、Vector Database、Agent、Tool Calling 和 MCP。所以接下来的 25 篇我们就把这些东西一个一个拆开。下一篇《DBA 学 AI02AI、机器学习、深度学习、大模型到底是什么关系》 DBA 为什么现在必须学一点 AI？
如果把时间往前推几年DBA 的技术栈其实相对稳定。Oracle DBA 主要围绕 SQL、执行计划、AWR、ASH、RAC、Data Guard、RMAN、ASMMySQL DBA 则会关注复制、InnoDB、慢 SQL、锁、Buffer Pool、备份恢复。再往外扩一点无非是 Linux、Shell、Python、监控和自动化。这些东西当然还在而且以后也不会突然消失。但这两年一个新的变量已经很明显地进入 DBA 的工作AI。现在遇到一条陌生 SQL很多人已经习惯先扔给大模型看看Oracle 报了一个不熟悉的 ORA 错误也会顺手把错误堆栈贴进去问一下写 Shell、Python、Ansible甚至整理故障报告和巡检结果都开始大量使用 AI。我自己越来越明显的感受是AI 对 DBA 的影响可能不会表现为“突然有一天不需要 DBA 了”而是先从大量具体工作里一点点渗透进来。以前需要 30 分钟完成的事情现在可能 10 分钟就能做完以前需要自己查半天资料的问题现在 AI 可以先帮我们把排查范围缩小以前不太愿意写的 Python 和前端代码现在也敢直接动手了。这种变化看起来没有那么戏剧化但长期累积下来对工作方式的影响可能比想象中更大。DBA 其实非常适合使用 AI仔细看一下 DBA 平时在做什么会发现很多工作都有一个共同特点信息很多而且非常分散。一条 SQL 为什么突然变慢我们可能要看 SQL Text、Execution Plan、Bind、Statistics、Index、ASH、AWR还要和昨天的执行情况做比较。一次 Oracle 故障为什么发生可能要翻 Alert Log、Trace、操作系统日志、监控指标再去 MOS 找相关文档同时回忆以前有没有碰到过类似问题。Data Guard 延迟了也不能看到 Apply Lag 就直接下结论。到底是日志传输慢、MRP 应用慢、Archive Gap、网络问题还是备库 IO 出现瓶颈需要继续收集证据。DBA 真正做的事情很多时候并不是“执行一条命令”而是在大量零散信息中建立关系然后判断什么才是最可能的原因。这一点恰好和今天大语言模型擅长的方向有不少重合。它很擅长处理文本、整理上下文、归纳信息、解释代码也可以通过 Tool Calling 获取外部数据。再加上 RAG它还能查询企业自己的历史资料。这意味着 AI 和 DBA 的结合点其实很多并不只是“帮我写一条 SQL”。先看一个最现实的 SQL 性能问题假设业务突然反馈生产数据库今天很慢。传统排查并没有问题。DBA 登录数据库先看当前负载和 Active Session再看 Top Wait Events。如果发现某条 SQL 占用了大量 DB Time就继续获取 SQL Text、执行计划和运行统计检查表和索引再和历史执行计划比较。如果发现昨天还是 Plan Hash Value A今天突然变成 Plan Hash Value B接下来还要继续判断为什么变了是统计信息、Bind、数据分布还是其他因素导致。这个过程里真正体现 DBA 水平的是最后的分析和判断。但前面有大量工作其实很机械。查 SQL 要执行一组 SQL查执行计划又是一组查 Index、Statistics、AWR、ASH 还是固定动作。拿到结果以后还要复制、整理再把这些信息拼起来。如果把这些能力封装成工具AI 完全可以先完成第一轮数据收集。DBA 只需要给出一个 SQL_ID系统自动获取 SQL Text、Execution Plan、运行统计、相关索引、对象统计信息和历史执行计划再把关键 AWR、ASH 数据一起组织起来。AI 根据这些证据生成第一版分析DBA 再判断它的结论是否成立。如果把两种工作方式放在一起比较差异其实很明显。传统模式下DBA 不仅负责最终判断还要亲自完成大量信息收集和整理引入 AI Agent 后这部分机械工作可以逐渐交给系统DBA 把更多精力放在证据判断、方案选择和风险控制上。这也是我认为 AI 对 DBA 最现实的价值之一。它首先替代的不是 DBA 的判断而是判断之前那些重复的数据搬运工作。故障处理可能更适合 AI再看另外一个 DBA 经常遇到的场景。假设凌晨收到ORA-01555: snapshot too old有经验的 DBA 看到这个错误大概已经知道应该往 UNDO 和长时间一致性读的方向检查。但真正处理时仍然要看现场。SQL 到底跑了多久UNDO 表空间多大UNDO_RETENTION是多少V$UNDOSTAT怎么样有没有大量并发 DML是不是某个报表 SQL 运行时间突然从几十分钟增加到了几个小时除此之外我们可能还需要去内部知识库找以前的处理记录。问题是很多企业的历史故障资料非常分散。一部分在 Wiki一部分在 Word一部分在共享盘还有一些可能只存在某个 DBA 的个人笔记里。最尴尬的情况就是我明明记得两年前处理过一次几乎一样的问题但那份文档到底放哪了这时候 RAG 的价值就出来了。AI 不仅可以查询当前数据库状态还可以从内部知识库里找到过去的 ORA-01555 案例、UNDO 运维规范和相关 SOP再把实时数据与历史经验放在一起分析。如果系统发现当前问题和某次历史事故高度相似还可以直接把那次事故的根因、处理方法和验证结果一起提供给 DBA。这已经和普通的“问 ChatGPT 一个 Oracle 问题”完全不同了。前者依赖通用模型已有的知识后者开始使用企业自己的数据库经验。而企业真正有价值的 DBA AI我认为迟早会走到这一步。AWR 也是一个很典型的例子AWR 是 Oracle DBA 非常熟悉的东西。一份 AWR 报告可能几十页甚至上百页里面包含 Load Profile、Top Timed Events、SQL ordered by Elapsed Time、SQL ordered by CPU Time、IO、Memory、Segments、RAC 等大量信息。有经验的 DBA 不会从第一页开始逐行阅读。通常会先建立整体判断DB Time 是否异常AAS 多大DB CPU 占比怎么样主要等待事件是什么负载与历史相比有没有明显变化然后再继续定位 Top SQL 和具体资源瓶颈。这里其实很适合 AI。但真正合理的做法并不是简单把整份 AWR 扔给大模型然后问一句“帮我分析”。更好的方式是先把 AWR 结构化解析提取关键指标再让系统根据当前问题决定还需要查看哪些章节。如果发现某条 SQL 占了 60% 的 DB Time就进一步获取它的执行计划、运行统计和对象信息。最后 AI 输出的也不应该只是一段“数据库负载较高建议关注 Top SQL”这样的套话而应该给出能够被 DBA 验证的证据。比如本时段 DB Time 相比正常基线增加了多少主要增长来自哪个 Wait Event哪几条 SQL 贡献最大这些 SQL 的执行计划有没有发生变化。做到这一步AI 才开始真正帮助 DBA 分析 AWR而不是简单帮我们总结一个 HTML 文件。AI 对 DBA 最大的价值可能不是“知道得更多”现在的大模型确实知道很多 Oracle、MySQL 和 Linux 知识。但如果只是比谁记得更多我并不觉得这就是 AI 对 DBA 最大的价值。真正让我觉得有意思的是它有机会把以前彼此独立的信息连接起来。数据库实时状态是一块Prometheus 监控是一块AWR 是一块SQL 和执行计划是一块Alert Log 是一块内部故障案例又是另外一块。过去这些信息往往需要 DBA 自己来回切换工具然后在脑子里建立关系。如果以后有一个 DBA Agent 能够同时访问这些数据源工作方式就会发生明显变化。比如业务反馈“数据库慢”Agent 可以先读取监控确认问题发生的准确时间再查看对应时间段的数据库负载和等待事件。如果定位到某条 SQL就继续获取执行计划和历史表现同时检索内部知识库看看以前有没有出现过相似情况。最后交给 DBA 的不再是几十张监控图、几份报告和几千行日志而是一条已经整理好的证据链。发生了什么哪些数据支持这个判断最可能的原因是什么还有哪些地方需要进一步确认。DBA 再基于这些证据做最终判断。这比单纯让 AI“懂 Oracle”有价值得多。AI 会不会替代 DBA这是讨论 AI 时绕不开的问题。但我觉得把它简单回答成“会”或者“不会”意义都不大。如果把 DBA 的工作拆开来看趋势其实已经比较清楚。查表空间、查 Session、检查备份、整理 AWR 指标、生成巡检报告这些标准化程度比较高的工作本来就一直在被自动化。以前我们写 Shell、Python 和 SQL 脚本解决这些问题。AI 出现以后只是让自动化可以继续往分析层走。举个最简单的例子。传统监控发现DATA 表空间使用率达到 96%。脚本的任务基本完成了。它按照预先定义好的阈值触发告警然后通知 DBA。但 DBA 真正想知道的往往还有很多这个表空间为什么突然增长最近 30 天增长速度怎么样按照当前趋势还能用多久数据文件是否开启 Autoextend距离 Maxsize 还有多少底层文件系统或 ASM Diskgroup 是否还有空间这些问题以前需要 DBA 收到告警后继续查询。以后完全可以让 Agent 自动完成第一轮检查再把结果交给 DBA。所以 AI 最先改变的很可能不是那些需要复杂经验的工作而是判断之前的大量准备工作。如果每天有两个小时花在收集数据、整理日志和生成报告上而 AI 能把它压缩到二十分钟那么一年下来产生的变化已经很大。真正容易被替代的是机械操作很多 DBA 会担心 AI 越来越强以后岗位会不会消失。我反而觉得可以换一个角度看。如果一项工作能够完整写成固定步骤而且每一步都没有多少判断空间那么即使没有 AI它迟早也会被传统自动化替代。例如每天早上登录 20 套数据库执行同样的 SQL检查表空间、备份、DG 延迟然后把结果复制到 Excel。这种工作真正的问题并不是 AI。它本来就应该自动化。AI 带来的变化是一些过去不容易通过IF/ELSE写死的分析工作现在也开始具备自动化的可能。比如两条告警是否来自同一个根因一份 AWR 中哪些指标值得优先关注一条慢 SQL 应该继续检查统计信息还是先检查锁等待。这些工作仍然需要专业知识但 AI 可以承担越来越多的第一轮判断。DBA 的精力也会逐渐从“执行固定步骤”转向“审核证据和处理复杂问题”。但 DBA 使用 AI 有一个很大的坑AI 最大的问题之一是它可以非常自信地说错话。这件事在普通场景里可能没那么严重到了数据库生产环境风险会被明显放大。它可能告诉你一个不存在的 Oracle 参数也可能给出不适用于当前版本的命令甚至可能把一条高风险操作描述得非常合理。假设模型告诉你这个问题可以通过修改某个隐藏参数解决。回答写得很专业参数解释、修改命令、注意事项都有。但那个参数实际上是模型编出来的。如果只是写文章最多闹个笑话。如果 DBA 直接拿去生产执行问题就完全不同了。所以我并不认同“有了 AI以后数据库知识不用学那么深了”这种说法。我的判断恰好相反。AI 越强使用它的人越需要具备判断能力。以前不会的东西我们知道自己不会所以会去查 Oracle 官方文档、MOS 或者做测试。AI 的迷惑性在于它有能力把错误答案写得非常像正确答案。这也是为什么后面做 DBA Agent 时我们会一直强调证据来源、权限控制和人工确认。能从数据库真实查询的数据就尽量不要让模型猜能从企业知识库检索的内容就尽量提供来源涉及生产变更时不应该因为 Agent 判断“应该执行”就自动执行。AI 可以帮我们缩小排查范围但最终的生产责任不会因为接入了一个大模型就消失。AI 不应该直接拿到 SYSDBA如果以后真的开始做 DBA Agent我觉得第一条原则就应该是先做只读再谈自动执行。比如给 Agent 提供这些能力查询数据库状态查看表空间查看 ASM查询 Active Session查询 Blocking Session获取 Top SQL获取执行计划检查 RMAN检查 Data Guard这些已经足够做很多事情。而且工具背后的 SQL 最好由 DBA 提前定义并审核Agent 只负责决定什么时候调用而不是允许它自由生成任意 SQL 然后直接在生产执行。这和我们设计数据库权限其实是同一个思路。一个应用只需要查询几张表就没必要给 DBA 权限一个 Agent 只需要检查数据库状态也没必要给 SYSDBA。最小权限原则到了 AI 时代并没有失效反而更重要。DBA 到底应该把 AI 学到什么程度如果目标是转算法工程师那当然需要深入数学、模型训练和算法。但如果目标是 AI DBA我认为学习重点可以分得很清楚。前面的基础原理需要懂。Model、Training、Inference、Token、Embedding、Transformer 这些概念至少要知道大概在做什么。我们不需要自己推所有公式但不能完全不知道模型下面发生了什么。到了 AI 应用层就要开始真正动手。Prompt、Context、RAG、Vector Search、Agent、Tool Calling、MCP这些东西和企业 AI 落地关系很大值得 DBA 花更多时间。最后才是最重要的 DBA 实战。怎么把 SQL、AWR、数据库监控、故障案例、SOP 和数据库只读工具接进来让 AI 不只是会解释 Oracle而是真的能够使用我们自己的数据库数据。这也是整个《DBA 学 AI》系列后面的主线。我最期待的不是 AI 帮我写 SQL如果只是让 AI 帮忙生成几条 SQL我觉得这件事情很快就会变得普通。我真正期待的是另一个场景。凌晨收到数据库性能告警。在 DBA 打开电脑之前系统已经把异常时间段的监控指标、数据库负载、Top Wait、Top SQL、执行计划变化和历史故障案例收集好了。打开页面以后看到的不是几十张监控图和几千行日志而是一份已经整理好的分析。什么时候开始异常和正常基线相比发生了什么变化主要等待集中在哪里哪些 SQL 最值得关注历史上有没有出现过类似问题当前有哪些结论已经有证据支持还有哪些地方需要 DBA 进一步确认。DBA 根据这些证据做最终判断。如果能做到这个程度AI 对 DBA 的意义就不只是“提高一点写 SQL 的效率”。它开始真正改变数据库运维的工作方式。当然要走到这一步只会调用一个大模型 API 显然不够。我们还需要理解模型、Token、Embedding、Transformer、RAG、Vector Database、Agent、Tool Calling 和 MCP。所以接下来的 25 篇我们就把这些东西一个一个拆开。下一篇《DBA 学 AI02AI、机器学习、深度学习、大模型到底是什么关系》