| Author |
Message
|
| Ma.Pony |
 Posted: Thu Dec 24, 2009 10:56 pm Post subject: Can MQ7 use Database as message repository ? |
 |
|
Newbie
Joined: 24 Dec 2009
Posts: 5
|
Hi Guys,
As my title, if yes, can HQ Cluster use Active-Passive to share to same DB instance for message receovery ?
Thanks,
Derek |
|
| Back to top |
|
 |
| Michael Dag |
| Posted: Fri Dec 25, 2009 1:33 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
as an MQ application or MQ itself storing messages in database?
if the later then the answer is no, unless for specific parts of shared queueing on z/OS.
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Dec 25, 2009 3:31 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
WMQ stores messages in a proprietary format on all platforms; and it does not offer any alternative storage methods.
As a side note, databases like DB2 and Oracle, store databases in a proprietary format, as well. What this means, in a practical terms, is that you cannot navigate down the UNIX/Windows filesystem and expect to see messages in the queues folder.
On z/OS, queues are stored in linear data set spaces (LDS) - a VSAM construct of 4k blocks of bit streams - again, in a proprietary format.
z/OS Parallel Sysplex offers a high-availability shared-queue storage of messages in a Coupling Facility. Queues with the appropriate attributes (and other z/OS-specific configurations) can cause messages put/get by applications to be diverted to/from the CF so they can be processed by any queue manager is the same QSG. An additional layer of software (DB2 Data Sharing) performs this diversion of messages to the CF - just as it does for DB2 tables.
Things are stored in the CF as structures (again, not databases). These structures are only available to authorized applications (like DB2 Data Sharing) in the same QSG.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sat Dec 26, 2009 8:17 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Whether or not MQ uses a database to store message contents has nothing to do with whether or not it can be used in an HA Cluster with active/passive nodes.
MQ has been able to participate in an HA cluster with active/passive nodes since sometime in the v5 timeframe.
MQ v7.0.1.0 makes it much easier to create and manage an HA cluster with active/passive nodes, as most of the heavy lifting is built into the product.
MQ still does not require that you purchase or support any other software to run it - which using a database to store message content would. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Dec 26, 2009 10:16 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
The topic title asked Can MQ7 use Database as message repository?
The simple answer is no. WMQ does not offer any alternatives to the way it stores messages. Queues are not databases or tables, and messages in queues are not stored in rows.
WMQ v7 MQI supports Message Properties which can be selected with SQL92, a subset of SQL. The use of SQL92 tends to lead database folks to falsely believe that WMQ uses databases and tables.
For an understanding of v7 Message Properties and the MQ API interface, watch this presentation: http://publib.boulder.ibm.com/infocenter/ieduasst/v1r1m0/index.jsp?topic=/com.ibm.iea.wmq_v7/wmq/7.0/MQI/iea_330_wmqv7_API_3_Selectors/player.html
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Ma.Pony |
| Posted: Sun Dec 27, 2009 6:54 pm Post subject: |
|
|
Newbie
Joined: 24 Dec 2009
Posts: 5
|
| One more question, under the same Queue Manager, can we set multiple file stores for different Queue/Topic Name ? This is for speeding up IO access ... Thanks. |
|
| Back to top |
|
|
| Vitor |
| Posted: Sun Dec 27, 2009 8:34 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Ma.Pony wrote: |
| One more question, under the same Queue Manager, can we set multiple file stores for different Queue/Topic Name ? This is for speeding up IO access ... Thanks. |
No. And if you're that desperate to improve performance there are better places to start. Disc I/O is very seldom a bottleneck. Is your question as vague and theoretical as your other post, or do you actually have a performance problem?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Dec 28, 2009 4:43 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Without disagreeing with Vitor, I'll add that you can and should have your MQ transactional logs on seperate disks from your queue files.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Dec 28, 2009 5:45 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PeterPotkay wrote: |
| Without disagreeing with Vitor, I'll add that you can and should have your MQ transactional logs on seperate disks from your queue files. |
This is IIRC in the documentation.
But this is more to do with message integrity in the event of disk failure than performance. But I agree it does help performance as well.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mvic |
| Posted: Mon Dec 28, 2009 11:00 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| Vitor wrote: |
| But this is more to do with message integrity in the event of disk failure than performance. But I agree it does help performance as well. |
Agree, it's a bit of both. And anyone who cares about performance of persistent messaging should separate qmgrs/QMNAME and log/QMNAME onto separate devices.
The performance gain is something you can put in the bank every day. The theoretical extra safety is, like an insurance policy, something you may never need to call upon. |
|
| Back to top |
|
|
|
|
