Tuesday, July 19, 2005

OOUG

I am on my way to the Ohio Oracle User Group for the day tomorrow. Looking at the agenda, I can see I overdid one of my slots. It is a full day affair starting at 9:15 with one of my favorite 'fluffy' presentations on "Things you know"

After that I’m doing Tools I use. It still surprises me sometimes how many people don’t know about simple things like autotrace, tkprof and the like. To me though the real meat of that presentation is when I talk about instrumentation.  This is something I think is missing from many developed applications. One thing I really like about HTML DB is the fact that it is fully instrumented whether you want it or not (just like 10g, not that 9i and before were not, but 10g really is). Nothing worse than walking into a customer with a slow application and having the answer to “so, where do you think it is slow” be answered with “somewhere between line 1 and line 10,000,000 – we are not sure really”.

Then, the problem presentation.  I probably will have to adjust the schedule on the fly there.  I have an hour to do SQL Techniques and it has been a while since I finished it in an hour.  It is funny how the seminar sections grow over time – every time I do it, I have maybe 5 more minutes of material somehow.  This time, I have this to consider while talking about scalar subquery caching and reducing function calls.  Neat stuff.

The next session is on Efficient Schema Design – I’ll be able to skip one of the sections in this since I’ll have covered it to some level in the SQL Techniques.  That might get us back on track. 

I close up with Top 5 things done wrong.  The first slide simply says:

  • Lack of bind variables
  • Lack of bind variables
  • Lack of bind variables
  • Lack of bind variables
  • Lack of bind variables

Get the point?  The next on has the real list

  • Lack of bind variable
  • Not having a good testing environment
  • Not having any configuration management
  • Trying to be database independent
  • The DBA versus Developer relationship

Funny thing to me is that most of the talk is not “design” related so much as environmental issues.  Your IT’s mindset and procedures are the things done wrong mostly.  That last point really irritates me – the DBA vs Developer.  I see it over and over and over again.  The DBA feels their job is to protect the database from the evil developers.  The developers on the other hand try to find any way possible to not have to engage the DBA.  This always leads to suboptimal implementations and lots of finger pointing.  It is the ultimate self fulfilling prophecy – The DBA’s will have proven that the database needs protection (since the application is so poorly performing and resource intensive) and the developers will have proven that they need to work around the DBA’s in order to meet schedules.  It does not happen everywhere – but it does happen a lot.   

If you would like to help out a fellow DBA with her first really big presentation, see this request for information.  Sounds like an excellent topic and I’m surprised we don’t see more of them in this genre.  I’m all for it.

POST A COMMENT

32 Comments:

Anonymous Shawn Brockway said....

Tom,
Can't wait until tomorrow. I get to trade a day of work for an entire day of Tom Kyte presentations. Is there a better way to spend a day? For tomorrow there will only be a fellow DBA and I in attendance, but I'm hoping that in the future I can get some of our lead developers and system design folks to one of your presentations. We DBA's have finally gottem them to read your Oracle books and have been able to use them as a way to bridge the "DBA vs. Developer" gap.

Tue Jul 19, 12:06:00 PM EDT  

Anonymous Anonymous said....

I have been a production DBA before and I would not let most production support DBAs anywhere near a development meeting let alone an architecture meeting. Typically all I get out of production support DBAs(and often DB developers as well) is complaints about how stupid everyone is accept for them. They complain and complain and then when you ask them for a better war to do something they give you a high and mighty response that is extremely vague(because they don't know anything about design and development, etc...).

I routinely hear the same cliched responses from them about how java developers are bad because of 'insert cliche here'. They are totally useless from a development stand point. They seem to think they know everything when they can't even build a little widget application for themselves. This includes DBAs who have been on the team with me. They so alienate the development team that I have to spend significant periods of time smoothing things over to get them to work with me.

There are a small number of production DBAs who are useful on the development team, but it is very few and very far between. I try to be one of them. I know java and the j2ee architecture. So I can work with the development team instead of just complain.

Tue Jul 19, 12:36:00 PM EDT  

Blogger Niall said....

I'm afraid that I rather suspect your second slide to be in reverse order of practical importance.

Your first slide is of course technically flawless.

Tue Jul 19, 03:15:00 PM EDT  

Anonymous Anonymous said....

I would respond to the previous anonymous post, but I have to debug another java application problem.

Signed,
Production DBA

Tue Jul 19, 03:16:00 PM EDT  

Blogger Joel Garry said....

The DBA feels their job is to protect the database from the evil developers.

Problem is, if you don't do this, then not only do you have problems with code checkin/checkout/qa, but when any little thing goes wrong management allows developers to go in with various tools and change things. Code that hasn't seen the light of expert one-on-one, data, parameters that affect the entire app, whatever, the developer is used to being able to be in total control, and you wind up with no accountability and potentially disastrous results. That is quite a bit worse than what you said "Nothing worse" about, mere performance issues. And I've had to clean up after.

The developers on the other hand try to find any way possible to not have to engage the DBA.

When I've been a DBA I've tried to set things up so this is a good thing. I think developers should have freedom to be creative, and there should be an iterative process between development and production to reconcile what is produced with the production realities.

Of course, right now I'm trying to reconcile some "sophisticated" XML product with an Oracle relational database, and wondering how an Oracle DBA might have had input to it, and I just don't see any way. The XML seems to have this idea of shipping the metadata with the data, so you wind up with metadata that says nothing about anything to contain metadata within the data, and tables with fields to contain the metadata translations to the relational db and metadata about the transaction (much of which came from the Oracle db!) and all the data in varchar2(4000) with the occasional funny character. Or something like that. If it works, who am I to complain?

Tue Jul 19, 05:00:00 PM EDT  

Blogger Alberto Dell'Era said....

In my experience, the DBA-Developer relation is just an incarnation of the more general problem - how to build a team out of individuals with different experiences and expectations.

The solution is, always, very simple - it boils down to understanding that listening to what others bring forward, asking if you don't know what the heck are they talking about, and why not a bit of researching, is the fast path to *personal* success, since that way you get proficient very very fast, in the other's choice of technology but also in your personal one. In the meanwhile, you probably make the team's effort a success, which brings back self-motivation and recognition by management (and later, very later, and maybe, salary increase ;).

The so-called "cultural gap" between Developers and DBA is just and only a nice excuse - sure there is, but not so difficult to fill, if one wants to improve him/herself.

Tue Jul 19, 05:11:00 PM EDT  

Blogger Thomas Kyte said....

Joel Garry said...
....
Problem is, if you don't do this,


Ok, I'll admit that in the talk, what I mean by that is much more clear.

Basically - I'm talking about the DBA that won't permit a thing. Nothing invented after version 6. That just says "NO" with arms crossed. No reason why, just says "NO". The DBA that is so intent on "saving" the database from the developers - they never talk to them

This is a two way street - I'm not picking on either side at all, it is a communication thing.

Tue Jul 19, 05:12:00 PM EDT  

Blogger Wijaya Kusumo said....

Tom,
Is it possible to share some of your public presentation slide with us? There are many of us who don't have the opportunity to hear you live...

Tue Jul 19, 10:52:00 PM EDT  

Blogger Jeff Hunter said....

Wijaya Kusumo said...
Hereis one.

Tue Jul 19, 11:16:00 PM EDT  

Blogger Noons said....

“somewhere between line 1 and line 10,000,000 – we are not sure really”.

Ah yes: fuzzy logic... :)

Can't agree more with the instrumentation. Any chance of a chapter on just that in the new book(s)? The sort of thing I'm after is along the lines of: "this is what you can do to instrument your Oracle database interface/API/data layer". We're going to start re-development of major areas of our applications and I'm pushing like crazy for full database instrumentation, any and all ideas/suggestions/guidelines will be welcome.

Wed Jul 20, 03:05:00 AM EDT  

Blogger Pete_S said....

Well as a (ex?)developer… I feel a bit ganged up on ;-)

I'm amazed that there is still this "two-sides" approach to Developer / DBA relationships - it just does not cut it in a modern IT shop, well not my one!
My developers trust the DBA team and the DBAs trust us. We go to them for help and they come to us for advice. This works by mutual respect and constant communication.
When we have major development projects we always bring in one (or more) DBA team member for the duration - they see what we are doing, they guide us from mistakes and, hopefully, see new techniques being applied. Our objective is to deliver a sustainable, reliable and cost effective system for our customers and not to boost the egos of any team members

Wed Jul 20, 05:50:00 AM EDT  

Blogger Thomas Kyte said....

Wijaya Kusumo said...
Is it possible to share some of your public presentation slide with us?


click on the files tab on asktom...

Nuno Souto said...
Any chance of a chapter on just that in the new book(s)?


not in volume I but definitely yes in volume II

Wed Jul 20, 06:16:00 AM EDT  

Blogger Aman Sharma said....

Hi sir
hope the prestentation is going so much fine.Wish you all the very best and good luck.
Sir,I just read your presentation of Things we know.It was really an eye-opener.Saw one more thing in th slides,"Copyright Kyte Inc".What is that sir?
have a safe journey.
regards
Aman

Wed Jul 20, 07:24:00 AM EDT  

Blogger Thomas Kyte said....

Kyte Inc is what I use for signing contracts for books and other stuff, it did not belong on that presentation, I've sent the corrected copy over to them (that was a "special" copy of it that does not have all of the slides I presented as that would give away the jokes, needed to be updated)

Wed Jul 20, 07:44:00 AM EDT  

Anonymous Martin said....

Just curious, In the presentation Jeff Pointed out, what were the quiz questions you asked?

It's a presentation I would love to attent some time by the way. I Hope you will come to holland again sometime.

Wed Jul 20, 07:46:00 AM EDT  

Blogger Thomas Kyte said....

The quiz questions are all things that have "obvious answers", but the obvious answers are all wrong (like who was the first president of the US)

Wed Jul 20, 07:51:00 AM EDT  

Blogger LC said....

Good to hear that HTMLDB is instrumentated. Instrumentation makes so much possible. Where is HTMLDB technology really going? Has it got legs? Is anyone major ( much higher traffic than our favorite asktom ) outside of oracle using this or is this truly for small database-centric applications? How would you complete this: HTML db is best suited for applications that ...

thanks.

Wed Jul 20, 08:01:00 AM EDT  

Anonymous Anonymous said....

HTMLDB is instrumentated

I wonder why Oracle support can't find/solve our HTMLDB import/export error?

Wed Jul 20, 09:36:00 AM EDT  

Blogger Niall said....

I wonder why Oracle support can't find/solve our HTMLDB import/export error?

Have you tried escalating it?

Wed Jul 20, 10:55:00 AM EDT  

Blogger Rachel said....

Tom said

The quiz questions are all things that have "obvious answers", but the obvious answers are all wrong (like who was the first president of the US)

Yeah I remember those. I got to be the guinea pig when you presented that at NYOUG. As I recall, I got at least half right (mind full of trivia she has, and not much else)

Wed Jul 20, 08:29:00 PM EDT  

Blogger fuzzyllamaduck said....

Tom, you've mentioned you're a Google fan, have you seen GCHEESE Does Oracle's business plan stretch to 2069--full PeopleSoft integration?

Anyone, I'm looking for a pointer to information on 9iR2 Solaris 64 Optimal Flexible Architecture with a SAN. Are there still benefits with OFA on a SAN? Or, does utilizing only two mount points (non-OFA) make more sense. I found the following NetApp.pdf but it is focused on vendor specific configuration. Note our SAN is not NetApp--I'm just seeking the concepts and have a very limited storage knowledge. Let me know if this doesn't follow blog protocol, sorry.

Thu Jul 21, 12:51:00 AM EDT  

Anonymous Anonymous said....

Anonymous said...
HTMLDB is instrumentated

I wonder why Oracle support can't find/solve our HTMLDB import/export error?



Just curious, what is the HTML DB import/export error?

Thu Jul 21, 09:44:00 AM EDT  

Anonymous Anonymous said....

The first slide simply says:

* Lack of bind variables
* Lack of bind variables
* Lack of bind variables
* Lack of bind variables
* Lack of bind variables

Get the point?


No.

Thu Jul 21, 09:55:00 AM EDT  

Blogger Thomas Kyte said....

Get the point?
No.


Then you have been very lucky to not work on a system where they didn't get the point from the development perspective

Thu Jul 21, 10:31:00 AM EDT  

Blogger Jeff Hunter said....

No updates in two days. Tom must be having one of those trips from h*ll again...

Thu Jul 21, 04:44:00 PM EDT  

Anonymous Sergio said....

LC said:
...
Where is HTMLDB technology really going? Has it got legs?
...


Tom invited me over to respond to this. HTML DB is a full blown feature of the Oracle database. It has been ever since Database 10g came out. We're now mere days away from our third release of HTML DB. First came 1.5, then 1.6, and 2.0 is around the corner. Plans for the subsequent releases are already underway. As long as Oracle sells relational databases and customers are looking for a quick and easy way to get data in and out of those databases via the web, HTML DB will be a feature of the database.

The technology itself may evolve. Heck, we may even "get our AJAX on" just because everyone is doing it. But, it will always be a tool for rapid development of web applications on the Oracle database.

Is anyone else besides Tom using it? Sure, but this is difficult for us to find out as HTML DB is one of those free features that don't appear on a price list. I think you'll find that it's mostly used in intranet settings and that some of those intranet applications even sustain larger volumes than asktom.oracle.com. If I'd have to guess, I'd say that AskTom endures higher than average throughput. That doesn't mean that HTML DB can't handle loads bigger than AskTom. Because that would be implying that the Oracle database can't handle it. HTML DB scales just as well as the database does.

If I had to complete your sentence, it would go something like this: HTML DB is best suited for applications that:

* Need to be developed and deployed quickly
* Have evolving requirements and are therefore developed iteratively
* Operate on data in an Oracle database

Thu Jul 21, 05:37:00 PM EDT  

Blogger Jeff Hunter said....

Anonymous said...

The first slide simply says:

* Lack of bind variables
* Lack of bind variables
* Lack of bind variables
* Lack of bind variables
* Lack of bind variables

Get the point?


No.

Don't worry, this guy doesn't get it either.

Thu Jul 21, 07:54:00 PM EDT  

Anonymous Anonymous said....

Tom,

Sometimes, I would like to simulate the same load as in my production in terms of users to test a particular query, proc or package. Do you think it's will be wise to purchuse let's say Loadruner? Do you have any thoughts on this...

Fri Jul 29, 11:56:00 AM EDT  

Blogger Thomas Kyte said....

Do you think it's will be wise to purchuse let's say Loadruner?

it is a matter of scale. loadrunner is "big", it is comprehensive, but big.

If you are a rather large company, it would be a very good tool to have company wide. For a single project, to be used once and then not again for a long time - it would not be cost effective probably.

Fri Jul 29, 12:15:00 PM EDT  

Anonymous Anonymous said....

Following up...But any ideas on let's say for a small co. users simulations..? Any scripts ? tools you might use?

Fri Jul 29, 01:22:00 PM EDT  

Anonymous galactic_hitchhiker said....

Hello Tom,
about the DBA / Developer relationship ...

what are your thoughts on the pros/cons of creating username filtered views over the V$ views ? Our DBA team has decided to hide all v$ views from developers so that a developer can see only his/her session specific information in the v$ views.

Their primary reason was that developers do not know enough about the views and they might submit some attrocious joins over these views which might really put a load on the database. The secondary reason being security.

Also, I would appreciate if other DBAs / Developers chime in about the policy in their organisations, or even if it is a good or bad idea.

By they way, I am a bit against it but I am a development manager ( a newbie at the mgmt stuff, but the developer in me ain't dead yet! ) and I need to see both sides of the issue.
My argument against their primary reason was that developers really are not that stupid and bad queries / joins can be written by anybody ( even a DBA ) and V$ views are not a pre-requisite ingredient of bad queries!

You can email me at galactic_hitchhiker@yahoo.com

Thanks

Sun Jan 08, 03:20:00 AM EST  

Blogger Thomas Kyte said....

what are your thoughts on the pros/cons of creating username filtered views over the V$ views ?

Their first reason is utter nonsense if you ask me. All DBA's and developers already have the ability to create horrible queries - way way before getting to the V$ views.

In a development environment, developers need access to the V$ and even DBA_ views for most things to work properly - and to do their job.

In production - nope, they do not need this access.

Development - yes.

Production - no.

Test/QA - yes, after a problem is identified (you don't want it on by default just in case a piece of code came to rely on having the access - you don't want that code in production necessarily)

Sun Jan 08, 08:10:00 AM EST  

POST A COMMENT

<< Home