As others have pointed out, the DB2 governor will let you kill threads
that have exceeded some arbitrary amount of CPU time. There's
obviously pluses and minuses to that.
Using WLM you can age those long-running queries so they drop to a
low enough importance that they don't substantially
In a message dated 3/2/2011 12:44:49 A.M. Central Standard Time,
bernd.oppol...@t-online.de writes:
I'm working in the SQL training business from time to time, and I saw
horrible SQLs which wasted machine time for hours, issued from remote
Yeah Craig Mullin's DB/2 book says 70% of tuning
I know the DB2 forum would be better, but this may be more of a WLM question.
We are having occasional performance issues that appear to be rooted in some
interactive research queries. The words 'DB2 governor' have been mumbled,
but some think that the WLM would be a logical starting point.
I know this has been discussed before and I'm sure you tried to search the
archives.
I am assuming these queries are coming through the DDF interface. In the
past I have set up WLM DDF service classes with multiple service periods and
objectives, much the same as TSO work. The longer the DDF
We are having occasional performance issues that appear to be rooted in some
interactive research queries. The words 'DB2 governor' have been mumbled,
but some think that the WLM would be a logical starting point.
Details?
I've found the worst thing you can do is use the Governor to cancel
To solve the problem finally, you will have some DB2 expert to
examine the SQLs that the remote users are sending. Because
very often the people outside send the SQL through end user tools,
they are not well trained and could do much better. This will cost some
money at the start, but in the long
6 matches
Mail list logo
