NovusLogger — PL/SQL Instrumentation Framework
DB Realm Inc. (Open Source)
Challenge
OraOpenSource Logger has been the default PL/SQL instrumentation framework for a decade, and its last release was 2016. It predates native JSON columns, interval partitioning, OpenTelemetry, and everything Oracle has added since 21c — so every installation pays for that age in CLOB parsing, unbounded log tables and manual purge jobs. But thousands of packages call its API, and no team will accept a rewrite that forces them to touch every logging call they have.
Solution
Rewrote the framework from the ground up for Oracle 19c through 26ai while preserving every public API signature, so existing calls compile unchanged on day one and new capabilities layer in incrementally. Modern internals replace the 2016 assumptions: native JSON instead of CLOB parsing, interval partitioning with partition-drop purge instead of row deletes, asynchronous writes, and OpenTelemetry trace correlation. Released under Apache 2.0 with a utPLSQL test suite in CI.
Results
- ✓ 100% backward-compatible public API
- ✓ Spans Oracle 19c through 26ai from one codebase
- ✓ Partition-drop purge replaces row-by-row deletes
- ✓ utPLSQL compatibility suite in CI
Replacing widely-adopted infrastructure has one hard requirement: existing callers must not have to change. NovusLogger keeps every public signature from Logger v3.1.1, so adoption is an install rather than a migration project. What changes is everything underneath.
What the rewrite buys
| Area | Before | Now |
|---|---|---|
| Structured data | CLOB parsing | Native JSON column (21c+) |
| Purge | Row deletes on a growing table | Interval monthly partitioning with partition drop |
| Writes | Synchronous, in the caller’s transaction | Async via DBMS_PIPE, or TxEventQ on 26ai |
| Tracing | None | OpenTelemetry spans with W3C TraceContext IDs |
| Alerting | None | Teams, Slack, PagerDuty, n8n, OCI Notifications |
| Diagnosis | Application log only | AWR and ASH correlation (SQL ID, wait class, blocking session) |
The purge change is the one operations teams feel first. Deleting rows from a large log table generates redo, fragments the segment and competes with the workload that is writing new rows. Dropping a partition is nearly instant and generates almost none.
Version range as a design problem
Supporting 19c through 26ai from one codebase means the useful features are exactly the ones that do not exist at the bottom of the range. The framework detects the database version at install time and deploys a core profile or an agent profile accordingly — so a 19c installation is not carrying dead code for features it cannot run, and a 26ai installation is not held back to a 2019 feature set.
Deployment runs either as ordered SQL scripts or through Liquibase, and an install verification procedure asserts the result rather than trusting it.
Proving compatibility
The backward-compatibility claim is the whole value proposition, so it is tested rather than asserted. A utPLSQL suite exercises the legacy API surface directly and runs in CI. If a signature drifts, the build fails — which is the only way a promise like this stays true past the first refactor.
Beyond parity, the framework adds anomaly detection against baseline error rates, incident grouping by similarity with an open-to-resolved lifecycle, and — on 26ai — vector embeddings with cosine similarity search, plus an ORDS endpoint that exposes logs as a tool for AI agents.
Released under Apache 2.0.