| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ calls VS DB2 Calls |
« View previous topic :: View next topic » |
| Author |
Message
|
| Jesh |
 Posted: Fri May 02, 2003 8:53 am Post subject: MQ calls VS DB2 Calls |
 |
|
Novice
Joined: 09 Apr 2003
Posts: 12
|
hi,
we have a cics application that reads a set of DB2 tables and prepares a huge array(table) of offsets and lengths. Then it formats the output based on these offsets and lengths. We are doing about 200 DB2 calls to prepare that table. This cics appln. is performance critical. Totally about 2000 different instances(data combination) of the array is possible. Based on the input we build the corresponding instance array as I had explained above. We build the array for evey request from scratch ie., we issue 200 DB2 calls for every request. (Each array is of size 20000 bytes)
We are looking to improve the performance of this appln. So instead of doing 200 DB2 calls, we are thinking of having a batch program run at the start of the day that would read DB2 tables(that CICS appln is doing now), prepare the 2000 diffferent instances of the array possible and put that as a message into MQ queue (which would be indexed on message ID) by setting a message ID. We thought we would follow a predefined format for the message ID so that for a given combination of input, we can frame the message ID from the input data itself.
Then we can read the MQ with the Message ID that we framed and get the corresponding array instance. In effect, we would avoid the 200 DB2 calls and instead would be doing only a single MQBrowse.
Now, I just want to know how good a design is this. Can MQ be used in these scenarios.
Also, I would like to know which is more expensive --- MQ queue or a DB2 table?
Thanks !
Jesh |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri May 02, 2003 9:18 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Yes, you could use a queue this way. Yes, the performance of the call to retrieve one message from the queue based on MsgID would be less than the performance of making 200 separate DB2 calls.
But you should probably start with more normal database optimization techniques - for instance creating views, or creating a new table to hold your format arrays. |
|
| Back to top |
|
|
| Jesh |
| Posted: Tue May 06, 2003 6:56 am Post subject: |
|
|
Novice
Joined: 09 Apr 2003
Posts: 12
|
Thanks Jeff.
We are concerned that we would be using MQ as a data repository, which is something uncoventional. Will there be anyother problem if we use MQ for this?
Regards,
Rajesh |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue May 06, 2003 7:58 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
There is no particular problem that you would run into by storing messages long term on a queue, other than an additional load on your system from managing persistent messages - like a potentially longer time while quiescing a queue manager as it makes sure that the messages are committed to disk.
But as you say, it is unconventional. That is why it's better to start with more conventional database techniques, in my opinion. Particularly because you are using an unconventional MQSeries technique to solve a conventional database problem. |
|
| Back to top |
|
|
| Chris123 |
| Posted: Wed May 07, 2003 6:10 am Post subject: |
|
|
Novice
Joined: 14 Apr 2003
Posts: 11
|
| I agree with Jeff. Instead of creating the 2000 different instances as messages at the beginning of each day, why not create them as rows in a table indexed on your unique id. Then instead of single MQBrowse you have a single SELECT statement. |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Thu May 08, 2003 12:45 am Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
If you're dealing with a //SYSPLEX environment, you would have to think on the single point of failure(SPF) too. What I mean is: Messages placed on a local queue is "only" available on the local machine/LPAR unless they are placed in a SHARED queue.
Normally I've seen //SYSPLEX applications are using DB2-datashare to reduce the SPF risk.
So my 1st idea will be just create a new DB2 table and place the batch generatesd reports here, instead of doing MQ.... You might get into a battle with your DBA 
Just my $0.02 
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
