Database Consultancy 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 priorities. 

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 else.

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 fun.

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 problem.

In general, expect an overall improvement in performance of around 10-50% by tuning the database.

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 lost nothing.

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.