| Author |
Message
|
| jchacon |
 Posted: Wed Mar 21, 2007 2:59 am Post subject: queue recovery |
 |
|
Newbie
Joined: 21 Mar 2007
Posts: 2
|
Hi.
I'm thinking if it is possible to recover a queue to the state it had a time ago (with its messages).
For example, some user has deleted some important messages and you want to recover the queue to the state it had two hours ago.
Do you have any idea?
Thanks |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Mar 21, 2007 3:17 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Short answer is no.
Medium answer is if you've got a system backup of 2 hours ago (or a backup containg this message) maybe. But it's not straightforward.
Long answer is why are users puttering round in a queue deleting messages, and why are the messages in the queue long enough to be deleted? It's not a database...
(Though from a recovery point of view the problem is very similar. If a user deleted an important row of information from a table 2 hours ago, you'd experience very similar problems recovering it).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Mar 21, 2007 5:59 am Post subject: |
|
|
Guest
|
| Look at the MQ V6 System Admin. Guide for rcdmqimg and rcrmqobj. These control commands enable you to 'back up' an object (to the log) and recover it, if necessary. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Mar 21, 2007 6:08 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| Look at the MQ V6 System Admin. Guide for rcdmqimg and rcrmqobj. These control commands enable you to 'back up' an object (to the log) and recover it, if necessary. |
Doesn't back up the messages on the object, does it? 
You'd still need to roll forward through the linear log to get that. And if the message has been read & committed at some point in the past you'd need to end the roll forward at a consistent point prior to that time, which may not be on a log file boundary.
Like I said, maybe. But not straightforward. And maybe I should have used a more general term than "backup"; "media" might be better.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Mar 21, 2007 2:14 pm Post subject: |
|
|
Guest
|
Rcdmqimg (record mq image) and rcrmqobj (recover mq object) are used for 'media recover'. They are only supported with linear logs. Yes, the object and the messages can be backed up (recorded) to the log for later recovery.
Look at the System Admin Guide for what these control commands can do for you. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Mar 21, 2007 8:00 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
But if you want a "recovery in time" and not up to the last moment you will need additional tools (I believe cressida was supplying some good ones and no I have no commercial interest there).
Standard MQ recovers from media up to the point of failure or up to the present....
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Wed Mar 21, 2007 11:34 pm Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
| fjb_saper wrote: |
But if you want a "recovery in time" and not up to the last moment you will need additional tools (I believe cressida was supplying some good ones and no I have no commercial interest there).
Standard MQ recovers from media up to the point of failure or up to the present....
Enjoy |
Yes, Cressida has some tools for replying (and I have also no commercial interest), but it also requires linear logging. The ability, to reply messages is designed for test opportunities.
It is mostly not a good idea, to reply messages in MQ - especially in production or live environments. Such a mechanism is contradictory to the concepts of MQ (assured delivery)! MQ guarentees, not to loose and not to duplicate any message.
If resending is a requirement of your environment, then the sending application should be responsible therefor - and the receiving application must be able, to handle (maybe accidentially created) duplicates!
_________________
Regards
Hubert |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Wed Mar 21, 2007 11:59 pm Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| HubertKleinmanns wrote: |
Yes, Cressida has some tools for replying (and I have also no commercial interest), but it also requires linear logging. |
no commercial interest either, and it also requires messages to be persistent... 
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Mar 22, 2007 1:06 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| HubertKleinmanns wrote: |
It is mostly not a good idea, to reply messages in MQ - especially in production or live environments. Such a mechanism is contradictory to the concepts of MQ (assured delivery)! MQ guarentees, not to loose and not to duplicate any message.
If resending is a requirement of your environment, then the sending application should be responsible therefor - and the receiving application must be able, to handle (maybe accidentially created) duplicates! |
I think you mean "replay messages in MQ", but it's a good and valid point. When you recreate your queue manager / queue using any of the methods mentioned, it is essential to ensure that the messages are in a consistent state with the applications connected to the infrastructure.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Thu Mar 22, 2007 2:40 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
| Vitor wrote: |
| ... I think you mean "replay messages in MQ"... |
Of course you are right 
_________________
Regards
Hubert |
|
| Back to top |
|
|
| dgolding |
| Posted: Thu Mar 22, 2007 4:46 am Post subject: |
|
|
Yatiri
Joined: 16 May 2001
Posts: 668
Location: Switzerland
|
It always amazes me that 99% of the time recovery is only needed to bring back a message that was deleted/destructive-GET'd, and that is precisely what the record MQ image media stuff does NOT do. It will dutifully do the PUT and then straight away do the GET right in front of your horrified eyes. The whole exercise is farcical and in ten years of production middleware I think I've seen a media recovery needed ONCE. But because IBM recommend to use linear-logging as "best-practise" anybody who suggests otherwise is shot down in flames.
So, either make the consuming transaction write out a backup message to a file somewhere that can be replayed by another utility; or look at "mirrorq" or pub/sub mechanisms to take a copy of every message. Of course, both these methods will require a regular "purge" to prevent an overflow of backed-up messages. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Mar 22, 2007 6:47 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| dgolding wrote: |
But because IBM recommend to use linear-logging as "best-practise" anybody who suggests otherwise is shot down in flames.
|
it's all about predictability and sizing right... if you do that Circular is perfect and is a lot faster too ...
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Mar 22, 2007 6:51 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Michael Dag wrote: |
| dgolding wrote: |
But because IBM recommend to use linear-logging as "best-practise" anybody who suggests otherwise is shot down in flames.
|
it's all about predictability and sizing right... if you do that Circular is perfect and is a lot faster too ... |
It's the sizing that gets you. No-one can ever accurately predict message volume, or if they do they go out on some kind of sales junket and triple the traffic overnight without warning.... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Bruniche |
| Posted: Sun Jul 29, 2007 11:45 pm Post subject: |
|
|
Newbie
Joined: 07 Jun 2007
Posts: 7
|
Hello
I use this post to make a little "transverse" subject about linear log to save (on windows 6.0.2.1 version).
I make a vbs script which obtain the last log file name for evant AMQ7467 and AMQ7468.
In the IBM documentation, they say :
| Quote: |
| Message AMQ7467 gives the name of the oldest log file needed to restart the queue manager. This log file and all newer log files must be available during queue manager restart |
To test, i stop a QM (of test of course :p) move the AMQ7467 file (in my case it was S0000000.LOG) and restart the QM without problem. It's not what the doc says. Or i don't understand it in the good way.
At last, my question is : I really need to converse the AMQ7467 file ?
My script get the AMQ7467 and AMQ7468 file, look which of one is the older and archive all the log which are oldest than the one choose.
But like my QM doesn't "live" (i don't create any more object (Queue/Channel/trig/etc) since the creation) it seem that the AMQ7467 file never be update so all the file log are always newest compare to it. And i purge nothing at the end.
As i have a script which contain all the command to create the QM and all his object, i want to only get the AMQ7468 file and archive all the file that are oldest to it (not take care about AMQ7467 file).
I'm in a good way or i make a big mistake somewhere ? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jul 30, 2007 12:42 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Under linear logging there are 2 types of log files:
- files needed to recovery the queue manager
- files needed to recover objects
These are described by the 2 messages you reference. If the queue manager has no need to recover a damaged object it doesn't reference the recovery log (S00000000.log if you've not modified the queue manager since creation). If it does need to recover an object at start up, it will try to reference this file and complain if it's missing.
If you want to combine the files, use a record image command to take another recovery point into a more current log. This is considered good practice with linear logging.
There's also a support pac which does much the same as your vbs script you might want to refer to - MO73 IIRC but I might not.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
