Thanks for the replies.
We're testing this on Windows but are contemplating on doing this on Sun Solaris. We're using circular logging. I'm surprised the sequence of events worked, especially as we were using persistent messages. The reason we don't want to replicate the LOGs is because they seem to be involved in a lot more disk I/O and therefore we need to replicate more.
Can anyone think of scenarios that this approach would definitely not work in or scenarios I should try?
Thanks.
| "Juch, Robert" <[EMAIL PROTECTED]>
Sent by: "MQSeries List" <[EMAIL PROTECTED]> 17-Nov-2004 19:40
|
To: MQSERIES cc: Subject: Re: Backing up "Q" files but not the "LOG" files |
Kulbir,
Again, I do mainframes. On the mainframe, if you have an out-of-sync condition between your page datasets and your logs, the queue manager will abend with a s6C6.
I'm not sure if a queue manager would stay up on an small platform or not.
If you don't replicate the queue datasets and only the logs, you would then need EVERY log ever created to restore the queues.
Ò¿Ó
Bob Juch
Citigroup
MQ Mainframe Support Team
Weehawken, NJ
201-974-2147
mailto:[EMAIL PROTECTED]
-----Original Message-----
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of
[EMAIL PROTECTED]
Sent: Wednesday, November 17, 2004 1:21 PM
To: [EMAIL PROTECTED]
Subject: Re: Backing up "Q" files but not the "LOG" files
You should check with IBM, however... The technique will work, but if an
object is broken, then it will likely be broken forever. Also, there's no
guarantee the queue file will accurately reflect the state of the queue.
That is, there may be messages that would have been backed out and synced
with the log, but not yet on the queue file.
The point is if IBM didn't think the log file was needed, then they
wouldn't have created it. You may be better off keeping the LOG files and
not the queue files. Then at least, you can rcrmqobj the queue files once
the queue manager is running.
Also, if you issued the rcdmqobj after your step 12, it should restore the
queue back to step 6 You are using Linear logs right ?
"Kulbir S. Thind"
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
SK.COM> cc:
Sent by: MQSeries Subject: Backing up "Q" files but not the "LOG" files
List
<[EMAIL PROTECTED]
n.ac.at>
11/17/2004 12:04
PM
Please respond to
MQSeries List
Hi,
We're thinking about setting up replication for our queue manager to ensure
that just the Q files are backed up but not the LOG files for the queue
manager. This is being contemplated as it appears the log files are
updated far more than the Q files as the LOG files are doing internal
MQSeries checks, etc. We need to reduce the amount of data that we're
replicating.
My first thoughts on this were that this would not work as the Q files
would be out of sync with the LOG files. However we performed the
following:
1. Created a queue manager
2. Started the queue manager
3. Created some queues
4. Put some message on the queues
5. Ended the queue manager
6. Took a copy of the LOG files used by the queue manager
7. Started the queue manager
8. Put some more messages on the queues
9. Created another queue object
10. Ended the queue manager
11. Restored the LOG files that were backed up in step 6
12. Started the queue manager
At this point I was expecting issues but I found that the queue manager
started without problems and it recognised the queue that was created in
step 9. Does this mean if we took a copy of the LOG files and restored
them to a queue manager at a later point retaining the latest Q files we
would have no problems? Has anyone tried this or no of any problems?
Cheers,
Kulbir.
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
