Has This Happened Before? Queryable Memory for Database Logs

Oracle logs can contain errors that are routine, harmless, or hard to interpret on their own. Their meaning can depend on the database version, platform, patches, settings, and topology, making investigation difficult for administrators who lack fleet history.

The system sends logs from roughly 300 databases to Elasticsearch, then processes them in an on-premises logbook. It uses deterministic steps and local models for ingestion and classification, with limited cloud research on anonymized data. A Git-backed Markdown wiki stores the findings, while a workbench helps administrators use and update them.

The wiki brings together raw logs, generated research, and an administrator journal of actions and changes. Agents classify and research errors, while administrators can add context and ask follow-up questions. The workbench lets them view incidents by database, error, or timeline, which can reveal related failures across shared infrastructure.

Because local inference has limited memory, Budáč uses Python scripts to compact and group repeated events before sending manageable context to a model. The wiki uses Markdown with metadata so people can read and query it. Research agents prioritize curated sources, and an administrator reviews proposed additions weekly.

The system can monitor whether a fixed error returns and mark it solved after eight weeks without recurrence; residual risk tracking is still experimental. Budáč identifies small local models, incident storms, and possible prompt injection through web research as concerns. A future idea is to let a remote agent request more local information, with human approval to prevent leaks.