An open-source Oracle scraper writes session and plan history into Postgres for later forensics

The post's inventory of what an Oracle performance incident is actually made of runs to eight entries: database and instance, session ID and serial number, SQL ID and plan hash value, module and action and program, wait class and wait event, blocking and blocked sessions, SQL text, and execution-plan operations ^[12]. The author's position is that some of those make reasonable metric dimensions, that treating all of them as labels can create a large number of series, and that SQL text and execution plans are not natural metric labels at all ^[13]. So two of the eight are excluded from a label-based store before cardinality is even the argument ^[1]. SQL text as a label value is a mistake you only make once.

That exclusion is what shapes the schema. Copying the full SQL text or execution plan into every sample would waste storage and make the repository harder to query, so each kind of evidence is stored according to its own lifecycle and the pieces are connected through relational keys ^[9]. Grafana is the interface and the PostgreSQL repository is the evidence, in the author's framing ^[2]. The problem is stated narrowly: retaining enough connected evidence to investigate after the workload has already changed, rather than reading a metric at this exact moment ^[3].

Prometheus is the only alternative the post develops ^[18]. That leaves the sizing question open in the way these projects usually leave it. The default schedule is described as what the tool currently includes ^[7], and every interval is configurable per collector on the argument that a small development database and a busy production estate do not need the same sampling policy ^[6]. Read that schedule as a starting point you tune against your own instance, not a tested policy you can inherit from someone else's estate.

The part I would weight highest has the least sales copy attached to it: the collected data is not locked inside the tool, so DBAs can query the schema directly, join it with their own information, build new Grafana panels, or export it with standard tools ^[15]. History repositories die when the only way to ask a new question is to wait for someone to add a panel. This one puts the evidence in a database its users already know how to interrogate, which is the condition under which the retained rows are worth their disk.