Database Administration Services
Keep critical databases fast, recoverable and supportable.
Specialist database health, performance, resilience, security and managed support for production environments.
Discuss this requirement →Start with the environment, risk and required outcome.
Specialist database health, performance, resilience, security and managed support for production environments. Namandla Consultants begins with evidence and recommends a proportionate engagement rather than a generic technology package.
Connected expertise for the wider environment.
Clear steps. Visible decisions.
What database administration actually covers
Six areas. Most organisations without a dedicated database administrator have the first two and none of the rest.
Backup and recoverability
Native backup configured, transaction logs managed, restores tested. Covered operationally on backup and recovery.
Availability
Clustering, availability groups or replication where the recovery objective justifies it, and a documented rebuild where it does not.
Performance
Indexing, statistics, query plans, blocking and the workload profile. The largest area and the one with the most recoverable value.
Capacity
Data file and log growth, tracked with a projection rather than watched as a percentage.
Maintenance
Index and statistics maintenance, integrity checks, log truncation, running on a schedule and monitored, because these jobs fail silently.
Security
Authentication mode, least privilege on database roles, encryption at rest and in transit, and the audit trail where personal information is involved.
Database performance tuning
The area where most of the available improvement sits, and the one most often addressed by buying hardware.
Measure the wait first
A slow database is waiting on something specific: CPU, storage, locks, memory, network or the application. Wait statistics tell you which. Adding CPU to a database waiting on storage latency changes nothing and costs money.
Indexing is usually the largest single lever
Missing indexes force scans. Duplicate and unused indexes slow every write and consume storage and backup capacity. Both are common in the same database at the same time, because indexes get added for a problem and never reviewed.
Statistics are the quiet one
The query planner chooses an execution plan from statistics about the data distribution. Statistics that have not updated leave the planner working from a picture of the data as it was years ago, and it chooses badly. Reports get gradually slower and nobody links it to a maintenance job.
Blocking and long transactions
One long-running transaction holding locks can make an entire application appear broken. Identifying the blocking chain takes minutes with the right query and can take days by guesswork.
Query and application patterns
Row-by-row processing where a set-based operation would do. Queries returning far more data than the application uses. These belong to the application rather than the database, and pointing at the right layer saves the wrong team a week.
Storage latency
Covered on server and database infrastructure and worth repeating: a volume with free space and throughput headroom can still be the bottleneck if latency is high, and the symptom looks like a slow application.
The maintenance that has usually stopped
The most consistent finding when we take over a database estate.
Index maintenance failing since an upgrade. A maintenance plan or script that stopped working after a version change. The job still appears in the schedule. It reports failure into a mailbox nobody reads.
Statistics never updated because the maintenance job that would have done it is the one that stopped.
Integrity checks not running, so corruption is discovered during a restore rather than at the time it occurred, when it could still have been isolated.
Transaction logs growing without truncation, usually because the recovery model expects log backups and none are configured. The volume fills eventually, and it fills at a bad moment.
Backups running with no restore ever performed. Covered elsewhere and it belongs on this list because it is found on almost every takeover.
Each of these is quick to correct. The reason they persist is that none of them produce a visible symptom until they produce a serious one.
Platforms
Microsoft SQL Server
Instance configuration, availability groups, index and statistics maintenance, query tuning, licensing position.
Oracle Database
Instance and listener, RMAN backup, tablespace and growth management, AWR analysis, patching within the support window. Namandla’s EPM practice works with Oracle databases under finance applications daily, so an Oracle database under a Hyperion or FCCS environment is one conversation rather than two vendors. Covered on Oracle EPM and Hyperion services.
PostgreSQL and MySQL
Increasingly present underneath applications and appliances, frequently with nobody claiming them. Configuration, vacuum and maintenance, replication, performance.
Managed cloud database services
Azure SQL, RDS and equivalents remove patching and backup mechanics and leave you responsible for version currency, performance, cost and access control. Less administration rather than none, and the version deprecation schedule is a real obligation. Covered on cloud managed services.
What Namandla delivers
Database health assessment covering performance, maintenance, capacity, availability and security. Performance tuning from measured wait statistics. Index and statistics strategy. Maintenance implementation and monitoring. Capacity projection. High availability design matched to the recovery objective. Version upgrade and migration. Licensing position review. Ongoing administration under managed data services or the managed IT agreement.
Remote delivery nationally. Onsite in Gauteng where the environment requires it.
Common questions about Database Services
What do database administration services include?
Backup and recoverability, availability, performance tuning, capacity management, maintenance and security across your database platforms.
The distinction from general IT support is that these are database-specific disciplines. A capable systems administrator can keep a database server running. Knowing why a query plan changed, whether an index is helping or costing, or why a log file will not truncate is a different skill set.
Do we need a database administrator?
Below a certain size, not full time. What you do need is someone accountable for the six areas above, whether that is an internal person with the skills or an arrangement like this one.
The common position is a database estate that works, has never been assessed and has maintenance that stopped some time ago. That state persists comfortably until it does not, and the transition is usually abrupt.
Why is our database slow?
Measure the wait before changing anything. A slow database is waiting on something specific: CPU, storage, locks, memory, network or the application itself.
Wait statistics identify which. The most common causes in mid-market estates are missing or duplicate indexes, stale statistics leading the query planner to choose bad plans, blocking from a long transaction and storage latency. None of those are fixed by more CPU, which is where the money usually goes first.
Our reports have slowly got worse over two years. Why?
Most often statistics that stopped updating, combined with data growth. The query planner works from statistics about the data distribution, and stale statistics mean it chooses plans that suited the data years ago.
The gradual nature is what disguises it. Nothing broke, so nobody investigated, and the degradation is attributed to there being more data. Updating statistics and reinstating the maintenance that should have been doing it frequently produces an immediate and substantial improvement.
Can you support Oracle databases under a finance application?
Yes, and it is one of the places our two practices genuinely intersect. The database and the EPM application above it are one conversation rather than two vendors pointing at each other.
Where a consolidation or close cycle runs long, the cause is as often the database or the infrastructure as it is application configuration. Being able to look at the query plans and the application logic in the same session shortens that diagnosis considerably.
Do managed cloud databases still need administration?
Yes, less of it. The provider handles patching and backup mechanics. You remain responsible for version currency, performance, cost, access control and schema design.
Version currency is the obligation most often missed. Providers deprecate database versions on a published schedule and forced upgrades arrive whether or not you are ready. Tracking that calendar is a real task and it is nobody’s job by default.
What about POPIA and our databases?
Databases holding personal information carry the same obligations as anywhere else: access control, encryption where appropriate, retention and the ability to establish who accessed what.
The specific gap we find most often is production data copied into development and test environments, which moves personal information into environments with weaker controls and broader access. Masking or synthetic data for non-production is the standard answer and it is frequently not implemented.
When is a database service more than we need?
When you have one small database behind one application, the vendor supports it, backups run and someone checks them, and performance is not a complaint.
What is still worth doing once is a health check: verify a restore works, confirm maintenance is actually running, check the log file behaviour and look at the index position. That is a short engagement and it either confirms you are fine or finds something worth knowing. Either outcome is useful.