Services P/L and DBVision P/L specialise in a range of services in the relational database
field and its applications. We insist on realistic pricing, timely service and
audited quality. Continuous training in the latest technologies is one of our major
Unlike so many others in the Australian market, we do not
hold expensive offices in trendy suburbs, we do not sponsor activities that have nothing
to do with our business and we do not have over the top advertising budgets. We also
do not write books on ORACLE during our contracts. This allows us to provide our
customers with absolutely first class service and products. At a price that is
unbeatable. If you want to pay for the "glitz", then kindly look somewhere
ORACLE database design and performance tuning.
- Been doing it for the last 11 years. On my own. Must be
doing something right...
IMHO, database designers should learn the target database engine and its
capabilities in depth. The number of times I've seen relational databases used to
store time-series data and indexed in a completely and utterly useless fashion is just not
Performance tuning is another aspect that deserves special treatment. It is so easy
to fall into the "dogmas" of tuning. There is no such thing as a
"silver bullet" procedure that can fix the ills of bad design and poor coding.
Unless the system is grossly under-sized (it happens...), don't expect database
tuning to produce miracles. A badly designed application and database will NEVER
provide stellar performance, no matter how much hardware you throw at it or how much you
tune the database engine.
The concept that hardware will speed up and thereby avoid the need for good design and
good coding was invented by a hardware manufacturer. What did you expect?
Don't fall into the upgrade spiral, it's a well known trap and it will not solve the
In general, expect an overall improvement in performance of around 10-50% by tuning the
Tuning the design of the database can give you better gains, of the order of 50-100%
better overall performance.
But for really big speed changes, of orders of magnitude, you have to refine and tune the
design of the application and its code. In particular the SQL code. How does
27 hours reduced to 3 minutes of processing strike you as a performance improvement?
I've done this sort of thing so many times people think I know undocumented tweaks
to ORACLE. Complete NON-SENSE. It's easy.
Guy Harrison in his book SQL Performance Tuning gives the direction. All you gotta
do is learn and refine your knowledge and understanding of the applications, the database
and the SQL. Or hire someone like me who has been there, done that.
ORACLE database administration.
- On the following: VMS, UNIX, Windows NT. Been doing it since
V5. Then V6. Now with V7 and V8.
It's amazing how the basic principles of database administration have not changed a single
bit since the old days of hierarchical databases:
Match the administration to the OS.
Good I/O distribution.
Compartmentalisation of the database into functional and behavioural partitions.
Attention to memory sharing, the context the database runs in and the planned evolution
path of the system.
Simple, really. But how many people get lost in the technicalities and detail
without looking at the big picture first?
Relational application database design and tuning.
- This is a concept that I've been hammering everywhere I go. Dave Ensor
(ex-ORACLE consultant and internationaly recognized as a design and tuning expert) shares
these thoughts. If everybody spent some time doing this before they start coding,
there wouldn't be so many disaster stories...
Designing an ORACLE database cannot be a separate activity from developing an application
to use that database. Yet this is precisely what is done in most cases. Result
is blown schedules, panic tuning and corners cut all over the place.
Design of the application in turn cannot be separate from the design of the supporting
database. I often hear of systems developed in mainframes that made the trip to
relational databases in super-minis. Invariably, these are systems that use a
"file system" approach in their use of ORACLE (and other relational databases).
Minimal use is made of the relational capabilities of the database. I've seen entire
systems developed without a single PK/FK enforcement at database level, without trigger
validation and logging, without a single line of PL/SQL.
This is completely wrong. The argument is often used this maintains portability.
Utter RUBBISH! Relational databases CANNOT be used successfully without
making use of their inherent BASIC operational mechanisms. Portability should
not be achieved by restricting the features used.
Rather a set of basic features should be decided upon depending on the nature of the
database systems used (relational OR hierarchical, but never AND). A layer of code
is then written for each independent database to match the feature-set of the
application with the feature-set of the engine.
The application code is static, what changes is the portability layer or library.
This is how truly portable systems are designed. Not as completely brain-damaged
software that will run badly everywhere.
If the application software is destined to a relational database, basic features of
relational database design such as PK/FK relationships, defaults, triggers and stored code
CANNOT be ignored! Write code in the portable layer for syntax differences and
functional differences, but do not ignore a basic relational feature just because not all
relational databases have it.
Code the feature into your portability layer if it doesn't exist. As simple as that!
If this proves to be very difficult, seriously consider not supporting the
relational database vendors that do not have the feature. Things being what they are
in this business, in all probability it will appear in a later release and you'll have
Portable systems have been around since UNIX and C started, nearly 20 years ago.
It's about time the simple concepts of portable software design percolate into the average
commercial software development in Australia.