选一个比较经典的bad block问题处理吧，原厂解决方案如下：

ORA-600 [kdsgrp1] *** 2007-04-26 19:53:57.671 *** SERVICE NAME:(HARTLEY) 2007-04-26 19:53:57.671 *** SESSION ID:(304.20) 2007-04-26 19:53:57.671            row 0826817f.ffffffff continuation at            file#block#slotnot found文档中的核心处理办法SQL> alter session set events '10231 trace name context forever, level 10'; SQL> create tableas select *  from;或者跳过坏块SQL> execute dbms_repair.skip_corrupt_blocks('','');

我们测试大模型的：

• 1>基本能力 - 直接回答问题

• 2>RAG能力 - 基于专业文档回答问题

• 3>推理能力 - 基于专业文档和日志回答问题，给出解决方案

下面开始测试：

Mistral Small 3，全称为Mistral-Small-24B-Instruct-2501，是Mistral AI在2025年1月31日正式发布的一款新型AI模型。该模型以240亿参数的规模，在自然语言处理领域，特别是在多语言推理和集成应用方面，展现了出色的性能，为本地部署大语言模型开启了新的篇章。

mistral-nemo是去年我们创建AI Agent时本地支柱模型，llama-70b跑不起，8b又太拉胯，当时12b的nemo就是我们唯一的苦海明灯。mistral small则是今年最新模型。

测试开始：（手机点击放大图）

结果：请看日志，看状态，重启大法，找Oracle售后。

这类问题，因为该类文档一般在公共网络无法爬到，所以大模型不知道，也很正常。总体来说，条理清楚，没啥用处。

下面入场近期国产之光Deepseek，首先，它先啰嗦了一段心路历程

在这段中，可以看出，它能够识别kdsgrp1是内存问题，同时也提到了DBMS_INVALIDATION来进行校验，但它错误的认为是shared pool相关。不过没关系，它的DBA知识强于Mistral。

Deepseek的解决方案：看日志，重启大法，检查shared pool，优化配置，校验，找Oracle售后。

llama3.3 70b ，facebook的开源模型，70b的参数这里对deepseek和mistral有所不公平。

它也知道是内存损坏相关，其它建议和前面几个类似。不过多了一个无用的dump  session的建议。评分69

chatgpt看到同样的回应，相当干脆，“不知道，找售后”。所以从评测中可以看到，大模型不具备该专业知识。

咱们的国产deepseek V3 API由于压力太大，不开放充值，所以本次没法测试，希望能尽快用到最强大的国产模型。

下面我们打开RAG功能试试，我们演示一下过程。

首先打开文档拆分向量化工具，把文档拖动到上传栏，进行拆分，embeding，再加载到向量库。这个时候，我们在23ai的向量表，就可以查询到该文档。

流程：首先对PDF进行大模型去噪和格式化，转换为MD格式，然后采用保留字拆分，以500个tokens为界限，然后采用embeding模型进行向量化，最后insert到Oracle 23ai的向量表（其实就是一个向量字段）

从PDF文档，

变成一个一个片段，

TIP：太长的文档影响向量搜索的精度，所以需要拆分为片段。另外对于某些针对强的小问题问题，它只存在于文档的一个小章节，那么只提取文档的片段更容易让大模型理解并回答，而不是让大模型读整个文档，因为我测试的本地大模型本身上下文长度有限，并且理解能力因为算力而受限。

现在我们，打开RAG开关，选择 性能优化知识库。再次依次测试各模型

首先在向量搜索阶段，Oracle 23ai向量库的查询是非常迅速，本地虚拟机，没有创建向量索引，大约1000+文档，文档搜索小于0.1秒，+整体rerank不超过0.5秒消耗在数据库的查询阶段。商业级的AI数据库在这个赛道一旦开始，就会迅速领先，23ai已经在vector评测中处于lead级。

商业向量数据库与开源向量数据库相比，通常有以下几个优势：

• 企业级稳定性和性能

Oracle的数据库系统具有长期的企业级使用经验，通常能够提供高可用性、灾难恢复、备份和恢复等功能，这对要求高可用和可靠性的应用至关重要。

由于Oracle数据库具有强大的查询优化器和内存管理，它在处理大规模数据时能保持优异的性能。

• 安全性

Oracle的数据库提供强大的安全功能，如加密、细粒度访问控制、审计等，可以帮助企业保护数据免受未授权访问。对于一些敏感数据，Oracle的安全性通常会比许多开源系统更强大。

• 集成能力

Oracle向量数据库能够与Oracle的其他产品（如Oracle Cloud、Oracle Autonomous Database等）无缝集成，这为需要综合解决方案的企业提供了额外的优势。

它还可以与传统的关系型数据库、OLAP系统、机器学习工具等结合使用，方便用户构建综合的AI应用。

• 技术支持与服务

作为商业产品，Oracle提供了全天候的技术支持、培训、文档和服务，确保企业可以高效地解决任何问题。

这种企业级支持对于那些缺乏内部技术团队或需要保障服务水平的组织尤为重要。

• 易于管理

Oracle的向量数据库系统通常配备有管理工具，帮助用户方便地监控、调优和管理数据库。Oracle的管理界面和自动化管理功能通常比许多开源数据库更加完善。

• 扩展性和兼容性

Oracle的数据库支持分布式和横向扩展，可以处理大规模的向量数据，同时能够与现有的IT基础设施兼容。它通常能应对更高的数据吞吐量需求，并且支持更大的数据集。

在后台日志显示向量库查询返回该文档：

同时抛弃了几个评估打分较低的文档，reranking

但是mistral的结果垮了。。。

整个回复如果刚刚入职的新手，它明显看了一遍文档，但又好像看不懂，只能非常粗糙的进行了总结，内容基本不能用。主要的原因，参数太少24b，无法理解专业的文档。

心路历程：

资源消耗

16个逻辑cores的CPU 80%，用了接近40G内存，16G显存耗尽，GPU利用率6%。看起来算力还不是关键，主要是显存，内存，CPU。4090大约比4060快1.5倍。

结果如下：

非常好！准确，完整的覆盖了文档中所有的要点。而且还提醒我进行备份！唯一的美中不足，就是如果把BUG号也告诉我就完美了。

其它，速度慢，心路历程太啰嗦。但这个不怪它~

总体内容正确，但不完整，漏掉了设置event，格式不好看。

可以看出开源模型deepseek 32b不仅秒杀mistral 24b，同样打压了llama3.3 70b !

chatgpt-4go，作为No.1，能够很好准确地返回结果。商业级的模型参数，可能在几百B甚至上千b，能得出这样的结果也是预期。

KIMI（国产推荐API）

KIMI和chatgpt的结果差不多，

总结2nd 测试：这里让人惊讶的是，deepseek 32b，居然和闭源大模型API的效果类似，而且仅仅是32b！当然，在用户体验上闭源模型会更好。

最后就加入少量日志，进行推理测试，大模型能够进化到这步，才能正在的接入生成运行，否则只能是一个DBA助手。

这里的简单地在prompt中加入，实际的日志。让大模型根据日志能否给出命令。

prompt

我的oracle数据库发生了错误，日志如下，请告诉我如何dump出坏块的内容，请在日志中找出file#和block#。另外如何跳过表的坏块进行查询。

请给出具体的命令，带有日志中的参数，返回给可执行命令我。

日志如下：

*** 2019-03-30 21:00:06.323  *** SESSION ID:(1802.759) 2019-03-30 21:00:06.323  *** CLIENT ID:() 2019-03-30 22:00:06.323  *** SERVICE NAME:(ysnc) 2019-03-30 21:00:06.323  *** MOULE NAME:(java) 2019-03-30 21:00:06.323  *** ACTION NAME:() 2019-03-30 21:00:06.323  ***SCHEMA:CRM ***TABLE NAME:CUSTOMER_TABLE * kdsgrp1-1: *************************************************              row 0x030b33a7.0 continuation at              0x030b33a7.0  file# 12 block# 734119   slot 0 not found  KDSTABN_GET: 0 ..... ntab: 0  curSlot: 0 ..... nrows: 0  kdsgrp - dump CR block dba=0x030b33a7  Block header dump:  0x030b33a7   Object id on Block? Y   seg/obj: 0x29761  csc: 0x00.53475f8c  itc: 2  flg: E  typ: 1 - DATA       brn: 0  bdba: 0x30b3300 ver: 0x01 opc: 0       inc: 0  exflg: 0 

在之前测试就不理想的mistral，就直接淘汰了。

首先chatgpt，

可以看出，chatgpt把日志中的内容作为参数，放到了命令之中，这样就生成了真正可以执行的命令。

并可以生成function call

也就是AI可以直接接入运维系统的KEY！

也到达了类似效果，略有瑕疵。评分88

llama3.3 70b也完成了基本的任务，但是它给出了很多额外但并没有意义的输出。在商业化应用，我们要求的是准，而不是多。

它首先完成了从日志中到信息的任务

如何根据日志组合成了命令，而且贴心的给出了conn / as sysdba

很惊叹，区区32b的模型，居然能达到类似闭源模型的效果。

测试结果：

• mistral 61

• deepseek 66

• llama3.3  69

• chatgpt 70

• mistral 不及格

• deepseek 90

• llama3.3  80

• chatgpt 95

• KIMI 91

• deepseek 90

• llama3.3  78

• chatgpt 90

• KIMI 88

Deepseek优秀基础来来源于蒸馏技术和思维链技术，尤其是思维链：思维链的核心原理是 “分而治之” 策略。当面对复杂难题时，模型摒弃直接生成答案的简单做法，而是有条不紊地通过一系列中间步骤进行逻辑推导。以数学问题为例，模型会首先梳理已知条件，随后依序推导出未知量，最终得出准确答案。

去年，我都一直认为AI走入生产运维还早，因为除非各大传统软硬件公司自己训练end2end的模型，否则现有大模型根本无法提供运维端商业落地能力。但大模型的进展真是3个月一个质变，看来通过推理链解决复杂场景的思考问题，通过RAG解决，专业知识到导入问题，让AI迈进了一大步。当然目前还是需要人工编程干预，但是解锁本地AI 自动化运维的日期开始临近。

今年AI DBA们，可以在23 Ai向量库使用，推理模型使用，AI Agent研发上，可以找到新的战场了！