| Author |
Message
|
| Gideon |
 Posted: Wed Oct 13, 2010 12:29 pm Post subject: Log not available |
 |
|
Chevalier
Joined: 18 Aug 2009
Posts: 403
|
I am running WMQ 7 on Linux
I tried to start my queue manager, and got the following response:
| Code: |
\bash-3.2$ \strmqm XLINUXQM
WebSphere MQ queue manager 'XLINUXQM' starting.
AMQ7017: Log not available. |
It appears that my logs have been corrupted. Is there a way to recreate them. I tried deleting them and restarting, but that does not work.
Any ideas ?
Thanks |
|
| Back to top |
|
 |
| exerk |
| Posted: Wed Oct 13, 2010 1:41 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Create another queue manager with exactly the same logging parameters, then move its log files (including lfh file) into the 'broken' queue manager's log directory. It doesn't always work, but always worth a first attempt at resurrection.
_________________
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 |
|
|
| gbaddeley |
| Posted: Wed Oct 13, 2010 2:02 pm Post subject: Re: Log not available |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2502
Location: Melbourne, Australia
|
| Gideon wrote: |
| I tried deleting them and restarting, but that does not work. |
The qmgr creates and formats logs as it needs them.
You must *never* delete "circular" logs.
Its OK to delete "linear" logs that are no longer required for qmgr restart / recovery. There are SupportPacs for automating this.
_________________
Glenn |
|
| Back to top |
|
|
| LouML |
| Posted: Mon Oct 15, 2012 3:31 am Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
| exerk wrote: |
| Create another queue manager with exactly the same logging parameters, then move its log files (including lfh file) into the 'broken' queue manager's log directory. It doesn't always work, but always worth a first attempt at resurrection. |
Just wanted to say this is exactly what I needed. Thanks!
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
|
| Andyh |
| Posted: Tue Oct 16, 2012 6:52 am Post subject: |
|
|
Master
Joined: 29 Jul 2010
Posts: 237
|
Copying over a set of logs from a dummy queue manager is known as a cold start.
This is not a supported operation and should only be used under the guidance of MQ L2/L3 support.
A backup of the current queue manager state should always be taken before attempting this procedure.
When a queue manager restarts normally it uses the content of the recovery log to bring the persistent state back to the logical state it was in when the queue manager ended. The queue manager then backs out any active transactions to restore the system to an appropriate state.
When a cold start is performed there are no log records to replay and the queue manager files are left in exactly the state they were in when the queue manager last ended. If you're lucky and the queue manager ended normally with no indoubt transactions then all active transactions will have ended and all of the queue buffers will have been flushed to disk and no log record needs to be replayed at restart.
If you're not so lucky then the buffers didn't get flushed at shutdown and at restart you might:
1. gain messages
2. lose messages
3. suffer object damage
4. corrupt queue manager meta data |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Oct 16, 2012 7:24 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Andyh wrote: |
Copying over a set of logs from a dummy queue manager is known as a cold start.
This is not a supported operation and should only be used under the guidance of MQ L2/L3 support.
A backup of the current queue manager state should always be taken before attempting this procedure.
When a queue manager restarts normally it uses the content of the recovery log to bring the persistent state back to the logical state it was in when the queue manager ended. The queue manager then backs out any active transactions to restore the system to an appropriate state.
When a cold start is performed there are no log records to replay and the queue manager files are left in exactly the state they were in when the queue manager last ended. If you're lucky and the queue manager ended normally with no indoubt transactions then all active transactions will have ended and all of the queue buffers will have been flushed to disk and no log record needs to be replayed at restart.
If you're not so lucky then the buffers didn't get flushed at shutdown and at restart you might:
1. gain messages
2. lose messages
3. suffer object damage
4. corrupt queue manager meta data |
 and bad of me not to have caveated my answer. Going by the name of Gideon's queue manager I judged it to a 'crash-and-burn' sand-box setup - still, no excuse on my part for not stating it's an unsupported (but unfortunately rather well known and used) method.
_________________
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 |
|
|
| LouML |
| Posted: Tue Oct 16, 2012 9:23 am Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
I should have stated that this was in our Development environment, so we weren't so concerned with losing data as we would have been in Production.
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Oct 16, 2012 9:40 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9411
Location: US: west coast, almost. Otherwise, enroute.
|
| LouML wrote: |
| I should have stated that this was in our Development environment, so we weren't so concerned with losing data as we would have been in Production. |
My experience has been that bad habits in test/dev lead to bad habits in prod.
_________________
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 |
|
|
|
|
