This is an interview which I made with Tom Kyte in Zurich in September 2006
L.H.: Mr. Kyte, you are Vice President of the world’s largest database software company and you also are the man behind the http://asktom.oracle.com/ website.
Since more than 6 year you have provided kind of support to the Oracle community for their every day problems in your forum.
Judging from your experience, what are the most common mistakes made about database applications?
T.K.: This is a timely question, I just finished my “Worst Practices” material for some upcoming conferences (Oracle Open World included).
The worst practices I see out in the field are:
1) Blindly believing everything just because it is printed. I cannot even guess what percentage of technical material about Oracle published on the Internet is wrong. During the construction of my material for this Worst Practices talk – it took me about 10 minutes to find 10 really “good” (meaning really bad) examples of technically incorrect information. I used http://www.google.com/ to search for “Oracle Tuning Tips” and found some really bad material quickly.
2) Not using bind variables! Developers for whatever reason make this common mistake time and time and time again. Not using bind variables in most applications will cause 4 things to happen:
a) they will run slower in single user mode, a large percentage of the program run time will be spent parsing SQL, not executing it.
b) they will use memory entirely inefficiently, the shared pool will be a point of contention.
c) their applications will not scale as users are added – hard parsing is a point of much serialization in the database.
d) their application will be subject to SQL injection issues (put SQL Injection into the search box on http://www.google.com/ and see how many articles you get back on that).
So, by not using bind variables – the developers help to ensure they will have a slow running program that creates memory issues in the shared pool, that cannot scale and will be a huge security risk.
3) Implementing very generic data base designs. Generic code can be useful, in some rare cases – however, if you want something maintainable, understandable and performant – you will actually design your system, from day one.
4) Not having a credible test environment. For example – not testing to scale (if you are going to support 100 concurrent transactions, you need to be able to test that you can do that – and then test it!). Or – testing against an empty database; that will not give you any indication that your developed application will actually perform in real life.
L.H.: After 14 year of work with Oracle Database, what is the feature to your mind today which makes Oracle Database unique among other database providers?
T.K.:http://www.oracle.com/technology/oramag/oracle/05-may/o35asktom.html
My favorite feature – Oracle’s concurrency model.
L.H.: The average database of today is by far larger than what has been considered a Very Large Database only a few years ago.
What are the most challenging task for a database administrator today?
T.K.: Keeping up with the technology! Many of the things we used to spend a lot of time doing manually are much more automated than they were a decade ago. And there are hundreds of new features to learn about. In the last decade we’ve gone from having a 1 Terabyte database be considered “huge” to being considered just “average” in size. Many things we did not use or need to use a decade ago – such as partitioning (did not exist) – are things we need to have mastery over today. Therefore, the working set of knowledge a DBA needs today is very much different from the working set of knowledge they had to have 10 years ago. We need to “forget” about some of the things that were automated (such as undo management – I’m glad I don’t have to figure out exactly how many rollback segments of what size I need anymore) and keep up with all of the new tools we have to manage data such as partitioning, data guard, streams and so on.
L.H.: The trend of the Oracle Database Server goes clearly into the direction of self management and self maintenance.
Will there be a need for database administrators for the database of the future and what will be their main tasks?
T.K.: Absolutely – see the points above. Every time we automate something – 3 or 4 other “new things” are added. Sure – we automated PGA memory management in 9i, but we added Streams and Change Data Capture. The list of things DBAs do is not necessarily shrinking, but it is ever changing.
L.H.: Will the database server of the future be able to also kind of auto-tune the application?
T.K.: This is why I say “tuning is not dead”, but how we tune has to change. In the past – we would tune by tuning SQL. Nowadays the database is pretty good at tuning SQL – with SQL profiles, an ever smarter optimizer, the index advisor, the materialized view advisor, the SQL advisor and so on – tuning SQL is something we spend less and less time on.
What we have to focus on is how we do things – our algorithms. Maybe far far out in the future, the database can detect what an application is doing and “fix it”, but for the time being – only we can.
For example, the datab ase will not turn logic such as:
for x in (select * from t1)
loop
insert into t2 values X;
end loop;
into
insert /*+ APPEND */
into t2 select * from t1;
That is our job and will be for the immediate future.
L.H.: Oracle already has its own logical volume manager (Automatic Storage Management) its own cluster file system and since March 2006 also its own media management server (Oracle Secure Backup), which can be used to not only backup the database but also the entire Oracle software stack including application servers, the collaboration suite as well as OS-files.
Will Oracle be kind of an operating system some day?
T.K.: We tried that once before actually, a thing called “Raw Iron” http://news.com.com/2100-1001-219075.html
It was not widely adopted – maybe it was before its time. I can certainly see the usefulness of such a thing – I personally already consider Oracle to be my operating system in many cases. I’m not saying Oracle is working on it (I have no knowledge to that effect), just that I could see it happening sometime in the future. A database appliance, much like you have network attached storage.
L.H.: Thank you very much Mr. Kyte.
Posted by Lutz Hartmann 
