The database is slow, and nobody can say why.
Guessing is expensive. Every recommendation we make comes with the evidence that produced it — and an explanation you can check yourself.
Does this sound familiar?
- A report that was fast last year now takes minutes.
- The application times out at month end. Every month.
- Backups exist, but nobody has ever restored one to find out.
- Growth has no plan — you find out about disk when it runs out.
- There is no high availability, or there is and it has never been tested.
How we approach it
01 — Measure
Read the engine, not the symptoms
AWR and ASH on Oracle. DMVs and Query Store on SQL Server. pg_stat_statements and vacuum behaviour on PostgreSQL. Performance Schema on MySQL.
02 — Explain
Diagnosis with the evidence
Not "add an index". Which statement, which plan, which wait event, and why it changed. If we cannot show you the evidence, we do not make the claim.
03 — Fix
In an order you agreed to
Highest gain and lowest risk first, one change at a time, measured after each. Production is not the place for a batch of simultaneous changes.
04 — Protect
Restore tested, capacity planned
A backup that has never been restored is a belief, not a backup. We restore one, time it, and write the number down.
What you get
- A diagnosis report with the evidence behind every finding.
- A prioritised fix plan — gain, risk and effort for each item.
- The fixes applied, with before and after measurements.
- A restore actually performed and timed, not assumed.
- A capacity plan, so growth stops being a surprise.
Technologies
FIOCRUZ
1,100 database projects across six engines, brought under one set of operating practices.
Read the case →Tell us what you are trying to fix.
A tangled integration, a slow database, a system nobody understands any more. The first conversation is 30 minutes and costs nothing.