Databases
Oracle Database — planned
Will read ALL_SOURCE for PL/SQL bodies, DBA_TAB_MODIFICATIONS for writes and DBA_SCHEDULER_JOBS for schedules. This integration is planned: documented here as reference, not connectable from the admin today.
Oracle estates concentrate more pipeline logic inside the database than any other
platform. Packages containing thousands of lines of PL/SQL, scheduled by
DBMS_SCHEDULER, writing to tables in the same instance, are the normal shape —
and almost none of it is in source control.
That makes Oracle both the hardest estate to reason about without reading the database and
the most rewarding once a connector does. ALL_SOURCE and ALL_DEPENDENCIES
together yield a genuinely complete transformation graph, which is not true of any other
platform here.
Oracle Database today
Decim does not connect to databases today. Stored procedures and SQL kept in a connected GitHub repository are read during pipeline discovery and cited during an investigation. When the deciding evidence lives in the database — a row count by day, a column's values — Decim writes a check: a read-only SQL query, validated against a read-only allowlist and never executed by Decim, for someone on your team to run. The result goes back into the incident and triggers a new revision of the hypotheses.
The sources that ship today are GitHub, Google Cloud Logging, Jira Cloud and the optional Windows agent. Everything below this point describes the planned Oracle Database integration: what it is designed to read, and why.
What Decim will read from Oracle Database
The intended read-only surface for this integration. It is reference material for the roadmap — and useful on its own, because these are the views and APIs worth knowing during an incident whether or not any tool reads them for you.
| What | From | Why it matters |
|---|---|---|
| PL/SQL bodies | ALL_SOURCE | Package, procedure and function text, line by line |
| Dependency edges | ALL_DEPENDENCIES | What each object references, and of what type |
| Write activity | DBA_TAB_MODIFICATIONS | Inserts, updates and deletes since the last statistics gather |
| Schedules | DBA_SCHEDULER_JOBS, DBA_SCHEDULER_JOB_RUN_DETAILS | DBMS_SCHEDULER definitions and run history |
| Object change times | ALL_OBJECTS.LAST_DDL_TIME | When a package was last recompiled |
| Live contention | V$SESSION, V$LOCK | Blocking chains during a stall |
| Column metadata | ALL_TAB_COLUMNS | Types, precision and nullability |
Permissions it is designed around
Written out in full, because "read-only access" is not a specification. These are the grants the planned integration is designed around and may change before it ships. Nothing below grants the ability to write, and row access would be requested only on the specific tables you name. You do not need to create any of this today.
CREATE USER decim_agent IDENTIFIED BY "...";
GRANT CREATE SESSION TO decim_agent;
-- Catalog and dictionary. SELECT_CATALOG_ROLE covers most DBA_ views.
GRANT SELECT_CATALOG_ROLE TO decim_agent;
-- Dynamic performance views for contention evidence.
GRANT SELECT ON V_$SESSION TO decim_agent;
GRANT SELECT ON V_$LOCK TO decim_agent;
-- Reconciliation tables only.
GRANT SELECT ON SALES.INTAKE_BATCH TO decim_agent;
GRANT SELECT ON SALES.REJECTED_TRANSACTIONS TO decim_agent;
-- Note the V_$ form: V$SESSION is a public synonym for V_$SESSION and
-- cannot be the object of a GRANT.What it would build
What this source would contribute to the pipeline topology and to the evidence available during an investigation:
- A near-complete transformation graph from PL/SQL bodies and dependencies
- Scheduled work and its run history from DBMS_SCHEDULER
- Target nodes and write volumes from DBA_TAB_MODIFICATIONS
- Recompilation events that correlate with an incident window
Today, topology is built from code in GitHub, and each connection is marked direct or inferred. The design direction for sources like this one is a provenance model: a step found in a definition is declared, a step seen running is observed, one that is both is verified, and where two sources disagree the disagreement is kept as a drift note rather than resolved silently. That model is planned, not shipped.
Failure modes it would surface
What this source is uniquely good at proving — and, just as usefully, at disproving. An investigation that can refute a hypothesis cheaply is worth as much as one that confirms it. Until the integration ships, the same signals can be checked by hand, or requested by Decim as a check your team runs.
| Failure mode | The signal |
|---|---|
| Package recompiled mid-incident | LAST_DDL_TIME inside the window |
| Scheduled job stopped silently | Gap in JOB_RUN_DETAILS with no failure row |
| Load wrote nothing | INSERTS flat in DBA_TAB_MODIFICATIONS |
| Blocking during a stall | Blocker chain in V$SESSION |
Limits
What this source cannot tell you, even once it is read. Stated because an investigation that overstates its sources produces confident wrong answers, which is worse than an honest cause unclear.
ALL_SOURCEshows only objects the connecting user can see; a wrapped package body is unreadable by anyone- Multitenant instances need the grants applied per PDB, not once on the CDB
V$views are instance-local — a RAC cluster needsGV$to see the whole picture
Related integrations
- SQL Server — Will read catalog metadata, procedure bodies and write activity — the definitions git never sees.
- Informatica PowerCenter — The repository database holds mappings, sessions and run statistics — including per-target row counts.
- cron & systemd timers — The scheduler with no database. Will read crontabs, timer units and journal history.
See all integrations, or how the sources are combined into one graph.
Get started
Investigating a Oracle Database pipeline?
Bring an incident you already know the answer to. If Decim gets it wrong, that is a more useful demo than one where it doesn't.