Server and Database Infrastructure Support
Engineer server and database environments for operational resilience.
Architecture, remediation and lifecycle services for production application and database infrastructure.
Discuss this requirement →Start with the environment, risk and required outcome.
Architecture, remediation and lifecycle services for production application and database infrastructure. 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 we run
Windows Server
Domain services, file and print, application hosting, certificate services and the roles nobody documented that turn out to matter during recovery.
Linux
Application hosting, web and middleware tiers and the appliances that are Linux underneath whether or not the vendor says so.
Microsoft SQL Server
Instance configuration, backup, index and statistics maintenance, log management, always-on availability where the recovery objective justifies it.
Oracle Database
Instance and listener configuration, RMAN backup, tablespace and growth management, patching within the support window.
Storage
Arrays, LUNs, presentation, capacity and firmware.
Directory and identity
Active Directory health, replication, sites and services, domain controller placement and hybrid synchronisation to Entra where it exists.
Namandla also runs an Oracle EPM and Hyperion practice, which means Oracle database work under a finance application is one conversation rather than two vendors pointing at each other. Covered on Oracle EPM and Hyperion services.
The failures we find
Directory service health nobody watches
Replication failing between sites for weeks. A domain controller holding a role nobody knows about. Time drift, which breaks authentication in ways that look like everything except a clock problem. Active Directory fails quietly and then catastrophically.
Database maintenance configured once
Index maintenance jobs that have been failing since a version upgrade. Statistics never updated, so the query planner works from a picture of the data as it was three years ago. Transaction logs growing without a backup to truncate them, until the volume fills at a bad moment.
Growth managed at the limit
Databases and file volumes tracked by whoever notices a disk-space alert. Growth trend and projection turn that into a planned purchase months ahead.
End-of-support platforms in production
Almost always because a business application is certified only against that version. Legitimate as a constraint and not legitimate as an undocumented one. It needs an exception record, a compensating control and a plan.
Single points of failure in the middle tier. Clustered application servers on one storage array. Two hosts on one power feed. A licence server on a virtual machine with no redundancy and no documented rebuild.
Performance blamed on the wrong layer. An application is slow, so more CPU gets added, and the cause was a missing index or a storage path saturated by a backup job overlapping the working day. Diagnosis before purchase saves a surprising amount of money.
Service accounts nobody owns. Running scheduled tasks and application services, with passwords that nobody holds and that will expire eventually. Discovered during an incident.
Capacity and performance
Measure before buying. The default response to a performance complaint is more resource. It is sometimes right and it is often expensive and ineffective. Establish which layer is constrained: CPU, memory, storage throughput, storage latency, network or the application itself.
Storage latency is the one most frequently missed. A volume with plenty of free space and plenty of throughput headroom can still be the bottleneck if latency is high, and the symptom presents as a slow application rather than as a storage problem.
Track trend, not state. A database at sixty percent of its volume is a number. A database that has grown from forty to sixty percent in five months is a date. Capacity reporting that projects forward is what turns an emergency purchase into a planned one.
Right-size in both directions. Over-provisioning is as common as under-provisioning, particularly in virtualised environments where a specification was set at build time and never revisited. Allocated memory that is never touched is memory unavailable to something that needs it.
Lifecycle
The three dates that matter, tracked with enough lead time to be planned.
Hardware warranty and end of support
Running production on hardware without a support contract is a decision, and it should be one rather than an oversight.
Operating system and database version support
Published years in advance. There is no excuse for being surprised, and organisations are surprised regularly because nobody owns the calendar.
Licence renewal and true-up
Particularly for database licensing, where the metric is frequently misunderstood and an audit finding is expensive. Core-based licensing in virtualised environments is where most of the surprises sit.
We track all three as part of the managed service and report them with lead time rather than at expiry.
Resilience
Matched to the recovery objectives from the business impact analysis, described on business continuity planning. Not applied uniformly.
Clustering and availability groups for the systems where minutes matter. Real cost, real complexity and worth it for a small number of systems.
Replication to a standby for the systems where hours matter.
Backup and documented rebuild for everything else, which is most of it.
The rebuild documentation is the part that gets skipped. A system with a good backup and no documented build is a slow recovery, because someone has to work out the configuration under pressure. Recovery runbooks are covered on backup and recovery.
What Namandla delivers
Assessment
Inventory, capacity, performance, support currency, resilience, configuration and directory health.
Design and build
Server and database platform design sized from measurement, deployed to a documented standard.
Migration
Version upgrades, hardware refresh, virtualisation and cloud moves, phased with fallback.
Managed operation
Patching to the ring structure on patch and vulnerability management, monitoring, capacity management, database maintenance, backup verification and performance review.
Directory services
Active Directory health, replication monitoring, hybrid synchronisation and the cleanup that most estates need.
Lifecycle tracking across hardware, software support and licensing, reported with lead time.
Onsite work is Gauteng. Remote operation and design run nationally.
Common questions about Server & Database Infrastructure
Do you support both Windows and Linux servers?
Yes, both, along with the database platforms on them: SQL Server, Oracle Database and the common open-source engines.
Most South African mid-market estates are Windows-dominant with Linux appearing underneath appliances, middleware and application tiers, often without anyone treating it as a managed platform. Those Linux systems are frequently the least patched things in the environment precisely because nobody has claimed them.
Our application is slow. Is it the server?
Sometimes. Establish which layer is constrained before buying anything: CPU, memory, storage throughput, storage latency, network or the application itself.
Storage latency is the most commonly missed cause. 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. Adding CPU to that server changes nothing and costs money. Diagnosis first is not a delay, it is what makes the spend effective.
What database maintenance do we actually need?
Backup with verified restores, transaction log management, index and statistics maintenance, integrity checks and growth monitoring. Configured once and then monitored, because these jobs fail silently.
The most common finding is index maintenance that has been failing since a version upgrade and statistics that have not updated, so the query planner is working from an old picture of the data. Both degrade performance gradually, which is why nobody links the slowdown to a maintenance job.
We are running an unsupported operating system. What should we do?
Record it as an exception with the reason, a compensating control, an owner and a review date, then plan the remediation on a realistic timeline.
The usual reason is a business application certified only against that version, which is a legitimate constraint. What is not legitimate is leaving it undocumented. The compensating controls that work are network isolation, restricted access, removal of internet reachability and increased monitoring on that specific system.
Should we move our servers to the cloud?
Assess per workload rather than as a policy. Some belong there, some are cheaper and simpler where they are, and some cannot move for latency, licensing or regulatory reasons.
Database licensing deserves particular attention, because core-based metrics can behave very differently on cloud infrastructure and the cost model can change substantially in either direction. Covered on cloud migration and cloud managed services.
How often should servers be patched?
Monthly on a ring structure, servers sequenced by dependency with a verified restore point and a rollback plan, in an agreed maintenance window.
Domain controllers one at a time, never together. Database before application tier. Cluster nodes rolled rather than in parallel. Post-patch verification checks that the service works rather than that the server booted, which is a distinction that matters more than it sounds.
Can you look after our Active Directory?
Yes, and it usually needs it. Replication health, domain controller placement and roles, time synchronisation, stale object cleanup, group and permission review and hybrid synchronisation to Entra where it exists.
Active Directory is the system most likely to be quietly unhealthy in a mid-market estate, because it works well enough for long enough that nobody looks. Replication failing between sites for weeks is a routine finding and it produces symptoms that look like almost anything else.
Do you handle Oracle databases under finance applications?
Yes, and it is one of the areas where our two practices genuinely intersect. The database platform and the EPM application above it are the same conversation rather than two vendors pointing at each other.
Where a consolidation or a close cycle runs long, the cause is as often infrastructure as it is application configuration, and being able to look at both shortens the diagnosis considerably.
When is a managed server service more than we need?
If you have two or three servers, a stable environment and someone internal who patches them and checks the backups, you may be adequately covered already.
What is worth doing regardless is verifying that a restore actually works, tracking your support expiry dates, and writing down how each server would be rebuilt. Those three cost almost nothing and they are what most environments are missing. If you have them, you are in reasonable shape.