ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » Workflow Engines - IBM MQ Workflow & Business Process Choreographer » [Solved]FMC31100W

Post new topic  Reply to topic Goto page Previous  1, 2
 [Solved]FMC31100W « View previous topic :: View next topic » 
Author Message
jmac
PostPosted: Thu Jan 09, 2003 1:48 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website AIM Address Yahoo Messenger MSN Messenger
kriersd
PostPosted: Fri Jan 10, 2003 8:17 am    Post subject: Reply with quote

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
View user's profile Send private message
jmac
PostPosted: Fri Jan 10, 2003 8:58 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website AIM Address Yahoo Messenger MSN Messenger
kriersd
PostPosted: Fri Jan 10, 2003 11:21 am    Post subject: Reply with quote

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
View user's profile Send private message
nwhi
PostPosted: Wed Jan 15, 2003 1:02 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page Previous  1, 2 Page 2 of 2

MQSeries.net Forum Index » Workflow Engines - IBM MQ Workflow & Business Process Choreographer » [Solved]FMC31100W
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.