| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Recovery with circular logging |
« View previous topic :: View next topic » |
| Author |
Message
|
| dgolding |
 Posted: Mon Mar 10, 2003 1:37 am Post subject: |
 |
|
Yatiri
Joined: 16 May 2001
Posts: 668
Location: Switzerland
|
..I love a good discussion to start the week with! 
AFAIK, if a "malicious or clumsy user" does a CLEAR QLOCAL, you will never be able to recover from this using rcrmqobj. I've never tried it, but by deleting the file object and invoking recovery, it will replay the (perfectly valid) CLEAR QL command all over again 
IMHO using LL for pure media recovery is an anachronism. Buy more and better disks, and mirror them instead.... and write some sort of application logging or audit trail (which linear logging does NOT give you) for application recovery purposes.... |
|
| Back to top |
|
 |
| meekings |
| Posted: Mon Mar 10, 2003 5:19 am Post subject: |
|
|
Voyager
Joined: 28 Jun 2001
Posts: 86
Location: UK, South West
|
Sorry guys - still not getting my basic question answered. I think I'm not expressing it well enough. I know that the best method is probably to use circular logging with queues (and logs) on mirrored disks, but suppose that isn't an option. Then, on my queues, I have sufficient persistent messages (all committed, but no apps up to read them) such that their data can't all be contained within the maximum configurable active linear log space. Then suppose the disk with my queues on goes belly up. I can re-build my queue manager from a script, but the queues will all be empty. Is it possible to recover ALL the messages from the logs, and if so, how?
And when the manual talks about recovering "objects", does it mean, for example, just a queue, or the queue + its contents (assume the system is currently up but inactive - no transactions in progress, no messages "in flight"). |
|
| Back to top |
|
|
| dgolding |
| Posted: Mon Mar 10, 2003 5:32 am Post subject: |
|
|
Yatiri
Joined: 16 May 2001
Posts: 668
Location: Switzerland
|
AFAIK you should still be able to recover all zillion of your committed, persistent messages - as JHlastead pointed out, it's maximum 63 files that you spread your UNCOMMITTED messages over.
Recovering an object means queue + contents, as of the point before the crash.
Probably the simplest way of recovering all your queue objects is to copy the "queues" directory (for Open systems MQ managers), delete the contents and start up the queue manager. It should detect the errors in the objects and do recovery automatically.
Or you can recover all queues using the rebuild queue manager script as a template to do a "rcrmqobj" for each QLOCAL - should be really easy with a "grep" or two....
Obviously, you should fully test these scripts first
BUT, with LL, you need to do frequent (at least daily) housekeeping. There is a PERL script on the SupportPAC web page that will compress and finally delete unnecessary log files. |
|
| Back to top |
|
|
| Troilus |
| Posted: Tue Mar 11, 2003 6:44 am Post subject: |
|
|
Apprentice
Joined: 12 Jul 2002
Posts: 28
Location: Belgium
|
dgolding is right in his last reply, but do keep in mind that at the time of recovery MQ (non-z/OS) expects all logfiles to be on the same folder, meaning on the same disk. That could become an issue.
I do not agree with dgolding in his previous contribution. MQ logs everything you need to do an application recovery. Only, it is difficult to read, but that is why we wrote an MQ log analyzer, one of it's functions is exactly application recovery. Think of the overhead of logging every update from your application, why do that when MQ already does it very efficiently. |
|
| Back to top |
|
|
| dgolding |
| Posted: Tue Mar 11, 2003 8:41 am Post subject: |
|
|
Yatiri
Joined: 16 May 2001
Posts: 668
Location: Switzerland
|
..My point was about the logging, that IBM do not supply a user-friendly version to look at the log. "dmpmqlog" is practically "user hostile" to use, and you have to shut down the queue manager in order to dump the logs, as far as I remember...
But that log formatter sounds interesting! Any chance it could be shared...... |
|
| Back to top |
|
|
| pgorak |
| Posted: Wed Mar 12, 2003 12:10 am Post subject: |
|
|
Disciple
Joined: 15 Jul 2002
Posts: 158
Location: Cracow, Poland
|
One more post to this never ending subject...
I remember reading a document on recovery (one from IBM, devoted to UNIX systems) that said that before issuing rcdmqimg command, one must stop the channels first. I guess it's about uncommitted batches which may be not completed/confirmed by channel agents that they suggested this.
So my question is: does one risk any inconsistency when issuing rcdmqimg while there are messages coming in or out through channels?
Unfortunately, I can't give you the document title offhand, but if anyone needs it, I'll search for it.
Piotr |
|
| Back to top |
|
|
| Troilus |
| Posted: Wed Mar 12, 2003 2:44 am Post subject: |
|
|
Apprentice
Joined: 12 Jul 2002
Posts: 28
Location: Belgium
|
imho: No.
Only advantage I see in stopping all channels AND all other applications neatly, is that less logs might be needed for recovery.
dgolding: sharing our log-analyzer? Sure. At the right price. It is a commercial project. In order to not cross the line on this forum between giving information and advertising I can only say: have a look at our website. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
