Based on a LinkedIn post originally published on 16 March 2026
After obtaining my MASE certification, during my time at Compaq and later Hewlett-Packard, I became deeply interested in a particular systems problem:
How far could Oracle RDBMS performance be pushed if storage, operating system and database were treated as one integrated system rather than three separately tuned components?
At the time, around 2005, many performance discussions concentrated on individual layers.
Storage specialists optimised arrays and logical volumes. Operating-system specialists examined memory, processes and I/O behaviour. Database administrators tuned Oracle configuration, SQL execution and cache management.
Each discipline performed valuable work, but the boundaries between them could hide the most important interactions.
I wanted to understand what would happen if the complete path—from database request to physical storage and back—were designed as one cohesive architecture, particularly at multi-terabyte scale.
Performance emerges across layers
A database operation does not travel directly from SQL to disk.
It passes through several layers, each of which can change the timing, ordering and volume of the work:
Application workload
|
v
Oracle execution and cache behaviour
|
v
Oracle RAC coordination
|
v
Tru64 filesystem and I/O path
|
v
Logical-volume and storage layout
|
v
Storage controllers and cache
|
v
Physical devicesAn optimisation in one layer may provide little value if another layer immediately becomes the constraint.
Worse, two independently reasonable optimisations may work against one another. A database may expect one I/O pattern while the operating system aggregates or schedules requests differently. A storage layout may provide excellent sequential throughput while the application generates highly distributed random access.
End-to-end performance therefore cannot always be understood by examining each component in isolation.
A locally optimal component does not guarantee a globally optimal system. The meaningful result is produced by the interaction between the layers.
The Alpha-based home lab
I used my Alpha-based home lab to explore the problem.
This was not a customer implementation, an official product or a commercial proposal. It was an environment for technical investigation: a place where assumptions could be tested without the constraints of a production change process.
The lab allowed me to combine several areas I had been studying:
- storage-device and volume layout;
- Tru64 I/O behaviour;
- operating-system scheduling;
- database cache management;
- Oracle RAC clustering behaviour;
- high-availability design;
- and system behaviour during failure and recovery.
The purpose was not to optimise a single benchmark until it produced an impressive number. I wanted to observe how the architecture behaved as a system.
Designing the data path deliberately
At multi-terabyte scale, storage layout becomes an architectural decision.
Where database files are placed, how I/O is distributed and which components share a failure domain can affect both performance and availability.
A coherent design needs to consider several concerns together:
PERFORMANCE RESILIENCE ---------------------------- ----------------------------- Distribute I/O effectively Avoid shared failure domains Use available parallelism Preserve service during faults Reduce avoidable contention Maintain consistent data Align cache behaviour Support predictable recovery Measure the complete path Test degraded operation
Performance and resilience cannot be separated completely. A design that achieves excellent throughput only while every component remains healthy may perform unpredictably during the conditions in which the system is needed most.
Likewise, a highly redundant architecture can underperform if every protective layer introduces unmanaged contention or duplicate work.
Clustering changes the optimisation problem
Oracle RAC introduced another dimension.
The architecture was no longer concerned with one database instance accessing one storage path. Multiple cluster nodes needed coordinated access to shared data while maintaining consistency and service availability.
That created questions such as:
- How should work be distributed between nodes?
- Where does coordination become more expensive than local processing?
- How do cache behaviour and storage access influence one another?
- What happens to the I/O profile when a node fails?
- Can the remaining system absorb that workload predictably?
- Does the storage architecture preserve both throughput and data integrity during recovery?
+----------------+
| Oracle node A |
+----------------+
\
\ coordination
\
+----------------+
| Shared data |
/
/ coordination
/
+----------------+
| Oracle node B |
+----------------+
Performance depends on:
node behaviour + coordination + OS I/O + shared storageThe database, cluster, operating system and storage needed to agree about the shape of the workload, even though each layer expressed it differently.
Cache is useful only when its role is understood
Cache existed at several points in the architecture: within Oracle, inside the operating system and in the storage subsystem.
Adding cache at every layer does not automatically make a system faster. Each cache changes what the next layer sees.
If the interaction is poorly understood, the architecture may:
- retain the wrong data;
- duplicate buffering unnecessarily;
- delay writes in unexpected places;
- produce misleading benchmark results;
- or create complex recovery behaviour after a failure.
The relevant question is not simply how much cache exists. It is which layer should make each decision, what consistency guarantee is required and where the authoritative state resides.
Every optimisation layer introduces state. If that state cannot be explained during normal operation and failure recovery, the apparent performance gain may carry an unacceptable operational cost.
Testing assumptions rather than protecting them
The value of the home lab was freedom to experiment.
I could change layouts, alter configuration, generate demanding I/O patterns and observe behaviour without needing to defend an established production design.
A useful experiment followed a simple loop:
Form an architectural hypothesis
|
v
Change one meaningful part of the system
|
v
Measure end-to-end behaviour
|
v
Introduce load or failure
|
v
Inspect where the hypothesis was wrong
|
v
Refine the design and repeatThis is different from collecting configuration recommendations and applying them independently. The purpose is to understand why a change works, under which conditions it stops working and which other components it affects.
The result
Through repeated experimentation, I gradually designed a high-availability Oracle cluster whose I/O characteristics exceeded anything I had personally encountered internally at that time.
The result did not come from one unusual parameter or one exceptionally fast component. It came from aligning the layers:
- the workload was considered at database level;
- cluster behaviour was included in the design;
- Tru64 I/O characteristics were treated as part of the solution;
- storage layout supported the expected access patterns;
- cache responsibilities were considered across the stack;
- and failure behaviour was treated as a design condition.
This remained personal technical exploration. It was not commercialised, presented as an Oracle product or developed with knowledge of any later vendor roadmap.
When principles reappear commercially
Years later, after Sun Microsystems was acquired by Oracle, I watched with interest as Oracle released a commercial platform based on similar broad architectural principles: database software, compute, storage and I/O behaviour designed as a more integrated system.
The commercial product and my home-lab work were obviously different in scale, engineering resources, implementation and purpose. I do not claim that my experiments caused, anticipated in detail or were equivalent to Oracle’s product development.
What interested me was the recurrence of the architectural principle.
When several layers exist primarily to serve one workload, designing them together can unlock results that isolated component tuning cannot.
Good system-design ideas often reappear because the underlying constraints reappear. The technology changes, the branding changes and the scale changes, but the architectural tension remains.
Technical insight and personal timing
Looking back, the experience also contains a career lesson.
It is possible to explore a technically promising direction without turning it into professional visibility, organisational influence or commercial opportunity.
Technical curiosity answers one set of questions:
Can this work? Why does it work? Where are the limits? What happens during failure?
Professional impact introduces others:
Who needs this? How should the evidence be communicated? Which business problem does it solve? Who can sponsor the next stage? How can the work become visible and reusable?
I had concentrated on the first set. I had not yet developed the personal marketing or organisational positioning needed for the second.
That does not diminish the technical exploration. It explains why technically sound work can remain private while a similar principle later becomes visible through an organisation capable of productising it.
The enduring lesson
I do not describe this experience as evidence that I was “ahead of my time.” That phrase places too much emphasis on personal prediction and too little on the recurring nature of good engineering principles.
The more useful conclusion is that coherent system design remains valuable across generations of technology.
Whenever teams divide a performance problem along organisational boundaries, it is worth reconstructing the complete path. Storage, operating system, network, clustering and application behaviour do not respect reporting lines.
The user experiences the result of the whole system.
Perhaps I was on the right technical track, but not yet on the right personal marketing track. Good ideas need more than technical validity: they also need timing, communication and a path into the world.
This article is based on my original ideas, experience, analysis and conclusions. Artificial intelligence tools were subsequently used as editorial and research assistants to review grammar and wording, improve structure and presentation, organise some arguments into clearer logical sections, and help review references to legal, regulatory and technical concepts.
Where relevant, factual and regulatory references were checked against the sources cited in the article. AI assistance does not replace professional legal, regulatory, financial or technical advice, and the final selection, interpretation, opinions and conclusions presented here remain my own.
Comments
Post a Comment