Author |
Message
|
elikatz |
Posted: Sat Jun 05, 2010 6:03 am Post subject: MQ backup using savqmgr |
|
|
Voyager
Joined: 24 Feb 2009 Posts: 86
|
hi all,
we have MQ version 6.0.2.9 installed on windows 2003.
I'm using savqmgr in order to synch this server to the DR site.
I've encounter a problem with this when a queue is changing from remote to local (or any other type change) - it doesn't work...
any ideas? am i missing something?
thanks,
Eli |
|
Back to top |
|
 |
mqjeff |
Posted: Sat Jun 05, 2010 6:18 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
What does "it doesn't work" mean? |
|
Back to top |
|
 |
elikatz |
Posted: Sat Jun 05, 2010 6:24 am Post subject: |
|
|
Voyager
Joined: 24 Feb 2009 Posts: 86
|
If a queue was created and sync as a local queue and then the queue was changed to a remote queue - it will not change on the DR site, it stays a local queue. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Sat Jun 05, 2010 6:32 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Because if QUEUE.A exists as a local queue and then you try and create a new remote queue called QUEUE.A, MQ will say 2 queues are not allowed by the same name. Even though the DEFINE Q REMOTE statement will have a REPLACE at the end of it, that means replace a remote queue, not replace the local queue which is of a different type. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
elikatz |
Posted: Sat Jun 05, 2010 6:41 am Post subject: |
|
|
Voyager
Joined: 24 Feb 2009 Posts: 86
|
|
Back to top |
|
 |
PeterPotkay |
Posted: Sat Jun 05, 2010 7:48 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
What's there to solve? Delete the local queue called QUEUE.A and recreate it as a remote. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
elikatz |
Posted: Sat Jun 05, 2010 8:15 am Post subject: |
|
|
Voyager
Joined: 24 Feb 2009 Posts: 86
|
I'll try to clarify... I have a script that synch the MQ structure to the DR every night so I need an automated solution - should I delete all the queues and channels every night and recreate as part of the DR synch? |
|
Back to top |
|
 |
exerk |
Posted: Sat Jun 05, 2010 9:02 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
Have your automated process place a delete statement in front of any queue you want to change the type of... _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
elikatz |
Posted: Sun Jun 06, 2010 8:01 pm Post subject: |
|
|
Voyager
Joined: 24 Feb 2009 Posts: 86
|
so you suggest my script will first delete all the objects (queues and channels) and then create them as per the export i did?
I guess there is no better version of MQ backup that knows how to override the type as well...  |
|
Back to top |
|
 |
Vitor |
Posted: Sun Jun 06, 2010 8:20 pm Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
elikatz wrote: |
I guess there is no better version of MQ backup that knows how to override the type as well...  |
Most of us use MQ backup to make sites that look just like the site they're backing up, i.e. local queues remain local. That's the much more traditional DR model in my experience because it tends to make failover easier.
(I mean, if you have an application that reads a local queue on the primary box, pointing it at a remote queue when it fails over & gettting it to work poses all sorts of problems....)
If you've come up with something else, then you'll need to script for the difference. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
fjb_saper |
Posted: Sun Jun 06, 2010 8:36 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
elikatz wrote: |
so you suggest my script will first delete all the objects (queues and channels) and then create them as per the export i did?
I guess there is no better version of MQ backup that knows how to override the type as well...  |
If it means that you have no control over when a queue changes from local to remote, to model, to alias... then yes, you need to delete all queues before rebuilding...
However you talk about DR. If you are using linear logging it should mean that all you have to do is apply the linear logs (see manual about applying linear logs to a DR).
If you are talking about an active/active DR site you should freeze the development environment and force all changes to be scripted and go through change control. This way you can apply them to both sites.
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
mqjeff |
Posted: Mon Jun 07, 2010 2:02 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
MS03 could be modified such that it can produce a DELETE QLOCAL statement before each DEFINE QLOCAL statement, instead of producing a DEFINE ... REPLACE.
However, that wouldn't solve this problem, because it would produce a DELETE QREMOTE statement before the DEFINE QREMOTE statement, when it needs to be a DELETE QLOCAL followed by a DEFINE QREMOTE.
And there's no way that MS03 can know that yesterday, some object was a QLOCAL and today that "same" object is a QREMOTE.
I believe one of the sponsors of this forum has a product or two that can help with this, and I'm sort of surprised that they haven't chimed in... but I'd thought this was one of the advantages of the tools from MQSystems, that it can make managing this kind of change over time easier. |
|
Back to top |
|
 |
exerk |
Posted: Mon Jun 07, 2010 2:17 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
elikatz wrote: |
so you suggest my script will first delete all the objects (queues and channels) and then create them as per the export i did?
I guess there is no better version of MQ backup that knows how to override the type as well...  |
No, I did NOT suggest that. What I stated was:
exerk wrote: |
Have your automated process place a delete statement in front of any queue you want to change the type of... |
If you need to change every queue/object, why not just have a second input file for DR? _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
elikatz |
Posted: Mon Jun 07, 2010 3:48 am Post subject: |
|
|
Voyager
Joined: 24 Feb 2009 Posts: 86
|
sorry for the misunderstanding...
what do you mean by second input file?
Quote: |
Have your automated process place a delete statement in front of any queue you want to change the type of...
|
the basic assumption is that I don't know what object was changed before the last backup (and since we have more then 4000 queue and counting I'm not going to check it manually... ) |
|
Back to top |
|
 |
exerk |
Posted: Mon Jun 07, 2010 9:43 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
elikatz wrote: |
sorry for the misunderstanding...
what do you mean by second input file? |
No apologies necessary, I think I misinterpreted one of your posts to mean that possibly all your queue/channel objects changed - skimming, sorry!
elikatz wrote: |
...the basic assumption is that I don't know what object was changed before the last backup (and since we have more then 4000 queue and counting I'm not going to check it manually... ) |
If you don't know what object was changed before the last backup then you definitely need something like MQSystem's MQDocument product (not a plug, merely a mention), which has the facility to take two input files and find differences between them. I'd further state that as you do not have control over your infrastructure (4000+ queues etc.) that it makes no sense you finding the differences - if there's a difference day-to-day, so what? Are you not going to implement those differences? _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
|