Tom Kyte about Things we "know"

Last week I attended the Tom Kyte seminar in Utrecht. This was a very impressive seminar held by a real Oracle database Guru. Tom says he still thinks of himself as being a developer and not a DBA. This is strange since most of this seminar was meant for DBA’s (at least that’s what I think it was). I am still puzzled with the question for whom this seminar was meant to. I think it was for DBA’s and architects.

The first day Tom was very eager to teach us that you should test everything you do. A lot of the knowledge of experienced Oracle consultants is based on that we learned or heard in the past. The things we learned could not be true anymore, Oracle 6 is not the same als 10g.

Even more dangerous are the things we think we should do without ever testing these thoughts. select into statements are evenly performant as using cursors. In Oracle 10g it should not matter if you use EXISTS of IN in your query. Who has ever tested which solution is the best of these?

Tom Kyte’s real strength is his ability to create simple examples. His book “Effective Oracle By Design” is full of these examples. He has examples for everything he states. These is no room for quesswork in his seminar; everyting is proven with very well choosen examples.

Tom started with mentioning his favorite tools like: autotrace, tkprof and statspack. He was very clear that you should run statspack and tkprof on your production database. The output of these measurements should be used with current runs when things go wrong. This way you can see what’s changed in case your system is not performing as well as it used to do.

It was very usefull to see him using these tools. The attendants of the seminar are now well equiped to understand and interpret a tkprof file. You can mease what you want; but understanding what you have done is of course very important.

Schema design is also very important for a well build system. Tom thinks that you should do everyting in the database. Triggers, check-constraints, enforcing business rules in the database. That’s what’s important. Databases mostly outlive the user interface that was build on top of them. Therefore enforcing rules should be done in the database ensuring that many different front-ends will nog mess up the data.

In a future post I will work out some of the examples Tom showed us.