Logo-Icon
HOMEABOUTSERVICESHOW WE WORKBLOGInstagram-Icon Talk To an Expert
RadixTrie-image
Database health check
Reliability

The Database Health Check: What a Good One Covers and What It Finds

A database health check is the fastest way to learn where an estate really stands. What a thorough assessment covers across SQL Server, Oracle, PostgreSQL and MySQL, what it typically uncovers, and what you should get back.
By RadixTrie3 September 20262 min read
Most organisations do not know the true state of their databases. Not because anyone is careless, but because the people closest to the systems are busy keeping them running, and the questions that matter most, can we recover, are we exposed, how much headroom is left, are rarely asked until something forces them. A database health check asks those questions deliberately, in a fixed amount of time, and hands you the answers in plain language. This article describes what a good one covers, what it usually finds, and what you should insist on receiving.

What a thorough health check covers

  1. Inventory and versions. Every instance, edition and version, mapped against the vendor's support lifecycle, so that unsupported software is visible rather than assumed.
  2. Backup and recovery. What is backed up, how often, where it is kept, when it was last restored, and whether the achievable recovery point and recovery time match what the business needs.
  3. Availability design. Whether high availability and disaster recovery exist, how they are configured, and when they were last exercised.
  4. Configuration. Memory, parallelism, storage layout, logging and platform-specific settings compared with the actual workload rather than with defaults.
  5. Capacity and growth. Data and log growth trends, storage headroom, and the dates at which current limits will be reached if nothing changes.
  6. Performance. The heaviest queries and waits, missing or unused indexes, statistics and maintenance state, and the recurring patterns behind slow periods.
  7. Security. Privileged accounts, authentication settings, encryption in transit and at rest, auditing, and exposure to the network.
  8. Operational hygiene. Alerting, job failures nobody sees, error logs, patch levels and documentation.

What health checks typically find

The findings are remarkably consistent across platforms and industries. Backups that succeed every night but have never been restored. Standby servers that have not been failed over since they were built. Instances still running versions that left vendor support years ago. Maintenance jobs that have been failing silently. Accounts with more privilege than anyone can explain. Storage that will fill in months rather than years. Query patterns that get slower every quarter and are tolerated because they always have been. Individually these are small; together they describe how much risk the business is carrying without knowing it.
A health check is not an audit of the people who run the systems. Its purpose is to give the business an accurate picture and a prioritised plan, and most in-house teams welcome it because it turns their unheard warnings into documented findings.

Platform specifics that matter

  • SQL Server: integrity checks, index and statistics maintenance, Query Store and wait statistics, availability group health, tempdb configuration, and edition-appropriate features.
  • Oracle: patch level against the latest quarterly update, RMAN retention and restore evidence, Data Guard state, diagnostic data review, tablespace and archive log capacity, and which licensed options are actually in use.
  • PostgreSQL: autovacuum effectiveness and bloat, write-ahead log archiving and point-in-time recovery, replication lag, connection management, and major-version support status.
  • MySQL and MariaDB: InnoDB configuration and buffer pool sizing, replication health, binary log retention and backup method, and version support status.

What you should receive

A written report a non-specialist can read, with findings ranked by risk rather than listed by discovery. Each finding should say what was observed, why it matters to the business, and what to do about it, with effort indicated. There should be a short list of things to fix immediately, a plan for the rest, and evidence behind every claim. A health check that ends in a sales pitch rather than a plan has not done its job.

How RadixTrie runs a health check

RadixTrie's senior engineers assess SQL Server, Oracle, PostgreSQL and MySQL/MariaDB estates for South African organisations, from our offices in Randpark Ridge and Stellenbosch. The output is the report described above and a conversation about priorities, whether or not you go on to use our <a href="/services">support and managed DBA services</a>. If you want to see how findings turn into outcomes, our <a href="/blog">case studies</a> show the pattern.
<strong>Related reading:</strong> <a href="/blog/managed-dba-services-explained">Managed DBA Services Explained: What You Hand Over, What You Keep</a> &middot; <a href="/blog/high-availability-disaster-recovery">High Availability and Disaster Recovery: Tested Beats Configured</a> &middot; <a href="/blog/database-performance-tuning">Database Performance Tuning as a Habit, Not a Project</a> &middot; <a href="/blog/choosing-a-database-consultancy-south-africa">How to Choose a Database Consultancy in South Africa</a>
Want to know where your databases really stand?
TAGSDatabase Health CheckDatabase SupportSQL ServerOraclePostgreSQLMySQL
RadixTrie-image
Database health check
Reliability

The Database Health Check: What a Good One Covers and What It Finds

A database health check is the fastest way to learn where an estate really stands. What a thorough assessment covers across SQL Server, Oracle, PostgreSQL and MySQL, what it typically uncovers, and what you should get back.
By RadixTrie3 September 20262 min read
Most organisations do not know the true state of their databases. Not because anyone is careless, but because the people closest to the systems are busy keeping them running, and the questions that matter most, can we recover, are we exposed, how much headroom is left, are rarely asked until something forces them. A database health check asks those questions deliberately, in a fixed amount of time, and hands you the answers in plain language. This article describes what a good one covers, what it usually finds, and what you should insist on receiving.

What a thorough health check covers

  1. Inventory and versions. Every instance, edition and version, mapped against the vendor's support lifecycle, so that unsupported software is visible rather than assumed.
  2. Backup and recovery. What is backed up, how often, where it is kept, when it was last restored, and whether the achievable recovery point and recovery time match what the business needs.
  3. Availability design. Whether high availability and disaster recovery exist, how they are configured, and when they were last exercised.
  4. Configuration. Memory, parallelism, storage layout, logging and platform-specific settings compared with the actual workload rather than with defaults.
  5. Capacity and growth. Data and log growth trends, storage headroom, and the dates at which current limits will be reached if nothing changes.
  6. Performance. The heaviest queries and waits, missing or unused indexes, statistics and maintenance state, and the recurring patterns behind slow periods.
  7. Security. Privileged accounts, authentication settings, encryption in transit and at rest, auditing, and exposure to the network.
  8. Operational hygiene. Alerting, job failures nobody sees, error logs, patch levels and documentation.

What health checks typically find

The findings are remarkably consistent across platforms and industries. Backups that succeed every night but have never been restored. Standby servers that have not been failed over since they were built. Instances still running versions that left vendor support years ago. Maintenance jobs that have been failing silently. Accounts with more privilege than anyone can explain. Storage that will fill in months rather than years. Query patterns that get slower every quarter and are tolerated because they always have been. Individually these are small; together they describe how much risk the business is carrying without knowing it.
A health check is not an audit of the people who run the systems. Its purpose is to give the business an accurate picture and a prioritised plan, and most in-house teams welcome it because it turns their unheard warnings into documented findings.

Platform specifics that matter

  • SQL Server: integrity checks, index and statistics maintenance, Query Store and wait statistics, availability group health, tempdb configuration, and edition-appropriate features.
  • Oracle: patch level against the latest quarterly update, RMAN retention and restore evidence, Data Guard state, diagnostic data review, tablespace and archive log capacity, and which licensed options are actually in use.
  • PostgreSQL: autovacuum effectiveness and bloat, write-ahead log archiving and point-in-time recovery, replication lag, connection management, and major-version support status.
  • MySQL and MariaDB: InnoDB configuration and buffer pool sizing, replication health, binary log retention and backup method, and version support status.

What you should receive

A written report a non-specialist can read, with findings ranked by risk rather than listed by discovery. Each finding should say what was observed, why it matters to the business, and what to do about it, with effort indicated. There should be a short list of things to fix immediately, a plan for the rest, and evidence behind every claim. A health check that ends in a sales pitch rather than a plan has not done its job.

How RadixTrie runs a health check

RadixTrie's senior engineers assess SQL Server, Oracle, PostgreSQL and MySQL/MariaDB estates for South African organisations, from our offices in Randpark Ridge and Stellenbosch. The output is the report described above and a conversation about priorities, whether or not you go on to use our <a href="/services">support and managed DBA services</a>. If you want to see how findings turn into outcomes, our <a href="/blog">case studies</a> show the pattern.
<strong>Related reading:</strong> <a href="/blog/managed-dba-services-explained">Managed DBA Services Explained: What You Hand Over, What You Keep</a> &middot; <a href="/blog/high-availability-disaster-recovery">High Availability and Disaster Recovery: Tested Beats Configured</a> &middot; <a href="/blog/database-performance-tuning">Database Performance Tuning as a Habit, Not a Project</a> &middot; <a href="/blog/choosing-a-database-consultancy-south-africa">How to Choose a Database Consultancy in South Africa</a>
Want to know where your databases really stand?
TAGSDatabase Health CheckDatabase SupportSQL ServerOraclePostgreSQLMySQL