Skip to main content

Overview Tab: Reference

This page is the source of truth for the in-app Explain this panels on the Schema Explorer detail view's Overview tab. Each section is written once as a content partial under _explain/ and rendered both here and inside the dashboard's info panel (scripts/build-explain.mjs compiles the registry).

Object Counts​

How many objects of each type the selected schema contains — one tile per object type the engine reports.

What each engine shows​

  • PostgreSQL — tables, indexes, views, functions, and sequences.
  • SQL Server — tables, indexes, views, procedures, functions, triggers, and sequences.
  • MongoDB — collections, indexes, and documents; the database is the schema scope here, and the Documents tile is a volume figure rather than a structural one.
  • Oracle — tables, indexes, views, procedures, functions, triggers, and sequences, plus the Valid / Invalid / N/A validity tiles.

A tile appears only when the engine provides that object type; a zero means the engine reported zero, not that nothing was collected.

How it's calculated​

  • Counts come from the agent's schema inventory, scoped to this schema: refreshed roughly every 10 minutes on PostgreSQL and MongoDB, every 4 hours on SQL Server and Oracle with default intervals.
  • The change chip compares against the previous comparable period.

Reading it​

Counts should move when deployments move them and stay flat otherwise. When a tile changes and nobody claims it, the Changes tab names the object, the change type, and the moment it happened — that is the drill-down, not the tile itself.

Valid​

The number of Oracle objects in this schema whose status is VALID — compiled, usable, and serving queries. This tile appears for Oracle.

How it's calculated​

  • Oracle tracks a validity status for every object in dba_objects; the agent collects the count of VALID objects with the schema inventory.

Reading it​

In a healthy schema this equals the object total. Its job is to be the denominator: when Valid drops while Invalid rises, a dependency change just broke compiled objects in this schema — the two tiles together say how many, and the Changes tab says what changed.

Invalid​

The number of Oracle objects in this schema whose status is INVALID — objects that failed compilation or were invalidated by a change to something they depend on. This tile appears for Oracle.

How it's calculated​

  • Oracle marks views, procedures, packages, and similar compiled objects INVALID when their dependencies change; the agent collects the count from dba_objects with the schema inventory.

Reading it​

Zero is the target. A transient non-zero after a deployment can self-heal — Oracle often recompiles on next use — but objects that stay invalid are broken code paths waiting for a caller. The Changes tab shows what changed right before the number rose; recompile or fix what remains.

N/A​

The number of Oracle objects in this schema whose validity status is N/A — objects Oracle reports without a valid/invalid state. This tile appears for Oracle.

How it's calculated​

  • Some object kinds carry no validity in dba_objects — synonyms are the common case, and partitioned indexes track usability separately per partition. The agent counts them as reported.

Reading it​

Informational, not a health signal: N/A means "validity does not apply," not "unknown problem." A stable non-zero is normal for schemas using synonyms or partitioning; per-partition index usability shows up in the object inventory's Status column instead.

Schema Identity​

An identity card lists the engine, hosting instance, database, and schema, and the schema switcher in the page header jumps between schemas of the same database without losing tab or time-window state.

Overall Health​

The selected schema's health score, using the same five-dimension model as the database health score — Performance, Security, Configuration, Schema, Maintenance — scoped to this schema's alerts.

How it's calculated​

  • The dimensions, weights, and score bands are identical to the database health score (see the Database Explorer's health reference); the ring turns green at 80 and amber at 60.
  • The schema scoping is in the alert counting: alerts that name this schema count against it, and alerts with no schema context are treated as database-wide — they affect every schema in the database. Instance-level alerts always count too, because a server problem is every schema's problem.
  • On MongoDB, the database is the schema, so all of the database's alerts count.
  • The per-category arrows open the Alerts tab pre-filtered to the alerts behind that dimension.

Reading it​

Compare it against the parent database's score: a schema scoring below its database means this schema specifically carries the findings — usually schema-dimension alerts like missing indexes or bloat on its objects. Matching scores mean the drag is database-wide, and the database's own health view is the better place to work from.

Total Size​

The combined size of the selected schema's objects, summed from the most recent size reading of each object in the selected window.

How it's calculated​

  • The agent collects per-object size metrics on its schema-collection cadence; this tile sums the latest reading per object within the schema.
  • The same tile on the Database Explorer's Schema tab covers the whole database; here it is scoped to one schema.

Reading it​

Read it with the treemap next to it: the tile says how much, the treemap says where. A schema growing while its object count stays flat means existing objects are growing — usually a handful, which the treemap makes obvious.

Object Sizes​

A treemap of the selected schema's objects sized by their storage footprint — the fastest answer to "where does this schema's space live?"

How to read it​

  • At the top level, each cell is an object type group (tables, indexes, …) sized by the group's total within this schema. Click a group to drill into its individual objects.
  • Inside a group, each cell is one object; very small objects (under a quarter percent of the group) roll up into a dashed Other cell so the long tail doesn't hide the picture.
  • Objects reporting zero size are left out. If everything reports zero — common right after adding a database, before statistics have refreshed — the card says so rather than drawing an empty chart.

Reading it​

A single dominant cell is concentration risk: one table carrying the schema. An index group rivaling the table group means as much space is spent finding data as storing it — sometimes justified, often redundant indexes worth an audit in the objects list below.

Database Objects​

The selected schema's object inventory — every table, index, view, and routine the agent has collected for it, searchable and sortable, largest first by default.

Columns​

  • Name — the object's name, with a type icon.
  • Type — the object type badge (table, index, view, procedure, function, trigger, sequence, collection — whichever the engine supports).
  • Status — object validity where the engine reports it: Oracle objects and index partitions show valid/unusable states, and a warning marker appears when an object's statistics are more than 90 days old.
  • Rows — the row count, where collected.
  • Size — the object's storage footprint.

The list can be searched by name, filtered by type, and paginated; column visibility choices persist in your browser.

How it's calculated​

  • Rows come from the agent's schema inventory, scoped to this schema — the same collection that feeds the count tiles above.
  • Row counts and sizes are the most recent readings; a stale-statistics warning means the figures may lag reality.

Reading it​

Sort by Size for the giants and by Rows for indexing-review candidates. On Oracle, watch for unusable index partitions after bulk loads — they silently stop serving queries until rebuilt. The stale-statistics marker matters most: an optimizer working from 90-day-old statistics makes 90-day-old decisions.