| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| [Solved]FMC31100W |
« View previous topic :: View next topic » |
| Author |
Message
|
| jmac |
 Posted: Thu Jan 09, 2003 1:48 pm Post subject: |
 |
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
Dave:
I couldn't agree more... This statement by Wolfgang should have everyone doing this maintenance on at least a weekly basis.
I must admit, I still don't understand what this does, being a DB2 novice, but I trust Wolfgang to be right.
Thanks for pointing out this document to me.
Got any more I should know about 
_________________
John McDonald
RETIRED |
|
| Back to top |
|
 |
| kriersd |
| Posted: Fri Jan 10, 2003 8:17 am Post subject: |
|
|
Master
Joined: 22 Jul 2002
Posts: 209
Location: IA, USA
|
I guess I could explain what this actually does to your system.
By running stats on the database your actually gathering information on the CURRENT data within the database. This is will generate meta data that can be later used to bind the most efficient access paths. In a nut shell, this tells the system to use the most efficient access path for a given SQL statement. For instance if you only have 5 rows in a table then runstats may decide that a table space scan is the most efficient way to access data in the table. Let's say that over time the table has grown and now has 100,000+ rows in the table. Unless you do a runstats rebind the system may not use the most efficient access path. Once the data in the table changes then the access paths may not be valid. The next time we do runstats rebind the system may choose to use an index rather than a table space scan. Running runstats rebind will create the most efficient access paths for the CURRENT data. Doing this on a regular basis will keep your access paths up to date and your system running at optimal performance.
I am not a DBA, but this is my understanding.
Dave
_________________
Dave Krier
IBM WebSphere MQ Workflow V3.4 Solution Designer |
|
| Back to top |
|
|
| jmac |
| Posted: Fri Jan 10, 2003 8:58 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
Dave:
OK, I think I get this. The rebind, is like the logical equivalent of reorganizing a VSAM KSDS dataset. Seems like its a little sexier, since based on what you are saying, it actually, can make some dynamic decisions as to how to access a particular table.
Does this sound right?
THANKS for the info
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| kriersd |
| Posted: Fri Jan 10, 2003 11:21 am Post subject: |
|
|
Master
Joined: 22 Jul 2002
Posts: 209
Location: IA, USA
|
You are correct Jmac.
Dave
_________________
Dave Krier
IBM WebSphere MQ Workflow V3.4 Solution Designer |
|
| Back to top |
|
|
| nwhi |
| Posted: Wed Jan 15, 2003 1:02 am Post subject: |
|
|
Apprentice
Joined: 19 Dec 2002
Posts: 25
Location: UK
|
Don't forget that the runstats only takes effect for static SQL (i.e. SQL statemements coded into the Workflow source code) after a rebind. Also, the re-bound executables only take effect after stopping and restarting the Workflow server(s)! (You don't have to stop the workflow servers to do runstats and rebinds, just afterwards a quick stop/restart to get the new access plans to take effect)
In other words, the standard maintenance you have to perform on the Workflow database means you have to bring the Workflow server down and up again, albeit very quickly. Also, being MQ based, if you do this in 'quiet' times then hopefully no-one will notice. It should appear as an xx second 'blip' in performance if you get it right.
Just something to be aware of if you're quoting 24x7 availability.
PS I your buildtime environment seems slower than when you first configured it, try a runstats. Even though this uses dynamic SQL it can have a noticable effect.
PPS V.Good DBA's will do a Reorgchk and judge which tables need a runstats and rebind and only do those that are necessary. This is especially useful for a virtual "24x7" system because reorgs are much slower require the Workflow servers to be stopped to run. Of course, it would be nice if this was automated ... perhaps it is in DB2 v8.
_________________
Nick Whittle
IBM Certified Solutions Designer -
WebSphere MQ Workflow V3.4
MQSolutions (UK) Ltd |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
