How Do LLMs Tackle Oracle Bad Block Errors? A Hands‑On Evaluation

First Round – Knowledge Test

We evaluated several LLMs (Mistral‑Small 24B, Deepseek‑r1 32B, Llama 3.3 70B, ChatGPT‑4‑go) on a classic Oracle bad‑block error (ORA‑600 [kdsgrp1] … file# 12 block# 734119). The official Oracle fix is to set an event trace or run DBMS_REPAIR.SKIP_CORRUPT_BLOCKS, or recreate the table.

SQL> alter session set events '10231 trace name context forever, level 10';
SQL> create table as select * from ...;
SQL> execute dbms_repair.skip_corrupt_blocks('', '');

Each model was asked three questions: basic answer, RAG‑based answer using documentation, and reasoning answer using logs.

2nd Round – RAG Test

We uploaded the Oracle 23ai documentation, split it into 500‑token chunks, embedded them, and loaded into the Oracle vector store. Queries were then run against the vector index.

Vector search returned results in less than 0.1 s; total rerank under 0.5 s.

Model performances (scores): Mistral‑Small 61, Deepseek 66, Llama 3.3 69, ChatGPT 70.

Final Round – Log + Knowledge + Reasoning Test

We provided a real Oracle error log and asked the models to extract the file# and block# and generate a command to dump the corrupt block or skip it.

*** 2019-03-30 21:00:06.323
... file# 12 block# 734119 ...

ChatGPT correctly inserted the extracted parameters into an executable command and even suggested a function call (score 90). Deepseek performed similarly with a score of 90. Llama 3.3 produced correct but verbose output (score 78). Mistral failed to provide a usable answer.

Overall Findings

Deepseek 32B consistently outperformed larger closed‑source models, achieving high scores in both RAG and reasoning tasks. Oracle’s vector database demonstrated fast query performance and strong enterprise features such as stability, security, and seamless integration with other Oracle products. The tests show that LLMs are approaching practical DBA assistance, though human oversight remains necessary for reliability.