jump to navigation

DBMS SIG March 10, 2010

Posted by mwidlake in internals, Meeting notes, performance.
Tags: , ,
trackback

I went to the DBMS SIG today {DBMS Special Interest Group meeting of the UK Oracle User Group}. Don’t worry, I am not going to run through the set of presentations and make comments on them – although I like reading such entries by others on their blogs, I generally like them due to the style of writing as opposed to getting information out of them. But there is the odd tidbit that can be worth disseminating to as wide an audience as possible and I like to do my bit.

Having said I won’t go through all the talks… :-). No, I just want to comment that all the talks had merit at this meeting and, quite rightly, the meeting was full. This is nice to see as last year SIG attendance fell across the board, due to the “economic climate”. Very daft, in my opinion, as I see SIGs as free training plus networking opportunities (sorry to use the “networking” word” plus different viewpoints, all of which are invaluable at any time and especially valuable when things are hard.

Go to SIGs (or whatever is available in your country) as it is always worth the day invested. Where else can you see half a dozen experts give opinions and also corner them and ask them more stuff as well?

Anyway, the tidbits. First, Jonathan Lewis demonstrated how he goes about solving issues with complex SQL statements. It was terribly feindish and extremly clever and needs incredible in-depth knowledge of the oracle RDBMS… He draws a pseudo Entity Relationship Diagram of the tables involved, adds in some figures on what filtering will achieve and what ratio of records will be involved in table joins and asks the question “what will probably happen” a couple of dozen times. Yes, I lied, it does not need vast knowledge. It needs a clear, simple approach to solving the problem. And an ERD. I love ERDs and rue their general demise. I use exactly the same method myself to investigate complex SQL performance issues {I think I could be accused of trying to ride on shirt-tails here, but honestly, the step I take if an Explain Plan does not help me is to ERD the statement and look at the indexes and ratios between tables to see how I , as a human, would solve the query. Chatting to a few other old lags, it is a relatively universal approach by those of us who have used ERDs}. If you are a member of the UKOUG I strongly recommend downloading the slides to Jonathan’s talk. If you are not a member, maybe Jonathan will present it again at another venue, or you could get him to come along and do a course on tuning. {Jonathan, if you get a gig as a result if this, I want a pint of Marston’s Pedigree, OK?}

{And thanks to Sean malloy for commenting to provide a link to a published version of Jonathan’s method – Jonathan did mention this, highlighting the fact that it is his first real foray into SQL*Server. However, the method is database agnostic. This is the article}

Second tidbit. Adrian Dodman and Owen Ireland (who both look remarkably like Hollywood hearthrobs in their pictures, but different as their in-the-flesh selves, though very decent chaps they are too.) did an excellent talk on VLDB physical standbys, a topic that has particular resonance for myself. They mentioned parallel_execution_message_size. This defaults to 2k, on 10g at least. It is a rubbish setting. No, let me not beat about the bush, it is an utterly rubbish setting. If you use parallel query, parallel recovery or parallel anything-at-all, check out this parameter and, due dilligence allowing, increase it. Try 8k as opposed to 2k and even 16k. The manual on it says the default of 2k/4k is fine. It ain’t. Increasing the value just takes some memory out of the shared pool and, these days, if you can’t afford a few extra KB out of your shared pool, you need to replace your server with something costing about twice as much as a top-end desktop PC. { Why am I so vigorous in my opinion on this parameter? Well, I had a situation a few months back of trying to migrate a database to a new geographic location for a client in Germany. We did a backup/recovery type operation to do this. Applying the redo logs was proving to be a performance issue so Oracle Corp suggested parallel redo log application. It ran a LOT slower than single thread, about 300% slower. However, increasing the parallel_execution_message_size from 2k to 8k made the parallel log application about 400% faster than single thread. ie a dozen times faster. I know from presentations by Christian Antognini and discussions with others that it is a key parameter to getting parallel query to perform well too.}

Last tidbit. Don’t drop the OUTLN user. Yes, I know, why would you? Just don’t, OK? Especially on Oracle 11. If you do, for whatever reason, DO NOT SHUT DOWN THE DATABASE. Call Oracle Support and pray. Thanks go to Peter Mahaffey for that one. Yes he did. It all went terribly wrong for him.

About these ads

Comments»

1. Greg Rahn - March 11, 2010

Note the new default for parallel_execution_message_size in 11.2 ;)
“16384 bytes if COMPATIBLE is set to 11.2.0 or higher”
http://download.oracle.com/docs/cd/E11882_01/server.112/e10820/initparams176.htm#REFRN10156

mwidlake - March 11, 2010

That’s great Greg :-)

It also allows me to emulate those awful Windows 7 adverts “Hey, I told Oracle to do that, it’s my idea – I designed Oracle 11!” I know, just as convincing as the ads. Oracle probably made that change before I even knew of the problem….

Thanks for the update.

2. Sean Molloy - March 11, 2010

See http://jonathanlewis.wordpress.com/2010/03/04/sql-server-2/
for Jonathan Lewis’s technique demonstrated with Sql Server queries

3. pdv - March 15, 2010

Thx for the writeup Martin.

And it is not just the demise of ERD that is hurting performance/troublshooting and IT Quality in general. It is the lack of understanding of our data.

A datamodel should be explicable, understandable. Too much high-tech in a datamodel, generic datamodels, will only work if the knowledge that is required to use them is kept with the organisation.

I wont repeat my usual rant as I remember it on your earlier post re-ERDs and CRUD but maybe it is time for a datamodelling-appreciation-society. Or is that just dino-behaviour?

(hm.. material for a rant there, need to disucss over a beer in Leeds ?)

4. mwidlake - March 15, 2010

Piet, it IS dino behaviour to want ERDs and CRUDs back – none of the young and thrusting people in IT seem to want it.

But that does NOT mean it is not the correct, best, fastest, most efficient way to do things long term . Maybe we should start siad appreciation society.

I keep meaning to look at the latest Oracle Developer, it apparently has ERD-functionality back in it.

There is SIG for development , but I think it is a very small SIG and it is more to do with the languages used than the modelling? I could be wrong.

http://www.ukoug.org/communities/show_community.jsp?id=1443&parent=811

Maybe I should swing by the next meeting in June. Something to include in the discussion over beers.

Martin


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 156 other followers

%d bloggers like this: