Case Study · Manufacturing / Database Performance

From 300 users to 1,500 in one week: tuning the Oracle database behind ELARABY’s SAP

ELARABY Group’s SAP system was slowing to a crawl, and the proposed remedy was a flash storage array costing more than US$180,000 with three months between the purchase order and the first faster screen. Khwarizm was asked to look at the Oracle database underneath it instead. Within a week the same hardware was carrying five times the users.

A slow ERP system rarely announces itself as a crisis. It arrives as a production planner who stops running the report and keeps the numbers in a spreadsheet instead; as a warehouse team that saves up its postings for the end of the shift because the screen takes too long to come back; as a finance clerk who has learned to press Enter and then look away. At ELARABY Group — 45,000 employees, more than 35 plants, products shipping to over 60 countries — that friction had hardened into a limit. The system could not comfortably hold more than about 300 people working at once, so the business had quietly stopped putting more of them on it. The recommendation on the table was to buy faster storage. Khwarizm was asked to look at the database first.

A ceiling nobody chose

ELARABY has been manufacturing in Egypt since 1964, and building under other companies’ names since Toshiba arrived in 1974. Today the group runs 26 businesses, manufactures under more than 17 international licences alongside its own Tornado brand, and reported revenue of EGP 35 billion in 2023. An organisation that shape does not run one process at a time. Sales orders, production orders, plant maintenance, warehouse movements and after-sales service all land in the same ERP, and they land continuously — a second shift in one plant overlapping with month-end in finance and a service queue that never empties.

That is what makes a concurrency ceiling expensive in manufacturing specifically. It is not felt as downtime, which would at least be measured and escalated. It is felt as a slow, permanent tax on judgement: the planner who reschedules from yesterday’s extract because today’s would take too long to pull, the storekeeper who posts a movement an hour after it physically happened, the branch that promises a customer a delivery date it cannot actually see. The data in the system drifts a little further from the factory floor every day, and nobody files a ticket about it.

The three-month answer

The proposal in front of the business was a new flash storage array: more than US$180,000 of hardware and, once procurement, shipping, installation and a migration window were honestly counted, roughly three months before a single user felt anything change. It is the reflex answer to a slow database, and it is a reasonable one, because storage is the easiest part of the stack to buy and the hardest to argue with. Nobody is ever criticised for recommending faster disks.

But a purchase order is not a diagnosis. Faster storage repays the investment only if the database is genuinely waiting on disk — and a database that has run out of headroom is often waiting on something else entirely. Sessions can queue behind one another rather than behind the hardware. Work can be done correctly but many more times than it needs to be. A query plan that was efficient when a table held a hundred thousand rows can quietly become the most expensive thing on the system when it holds fifty million, without anything in the infrastructure looking unhealthy at all.

In every one of those cases, new storage makes the wrong part of the system faster. The array arrives, the numbers improve slightly, the ceiling stays roughly where it was, and the business has spent both the money and the three months.

Reading the database first

Khwarizm’s engagement began with evidence rather than with changes. The question was not “how do we make this faster” but the narrower and more useful one: where is the database’s time actually going, and what is the first constraint that will bind if we remove the one in front of it? The work that followed stayed inside the Oracle Database and its configuration — no new servers, no new storage, no SAP upgrade, and no application code rewritten. That is why it could be done in a week rather than a quarter, and why it could be reversed quickly if any single change had made things worse.

One week, five times the load

By the end of that week the system was carrying 1,500 people at once on the hardware it already had — five times the load it had struggled with before — and the flash array was not ordered. The commercial argument writes itself: the money was not spent, and the three-month wait for a supply chain was not incurred, because the constraint was never in the hardware in the first place.

The results

The number that reads best on a slide is the money. The one that mattered inside the plants was the other one: five times as many people able to do their work in the system on the same Monday morning, without waiting a quarter for permission from a supply chain. A planner who can pull today’s figures instead of yesterday’s, a storekeeper who posts a movement when it happens, a service desk that answers with what the system actually says — that is what a database with headroom buys, and it was sitting inside the hardware ELARABY already owned.