| Author |
Message
|
| jcv |
 Posted: Tue May 08, 2007 6:44 am Post subject: recover log from partial data |
 |
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
Hello!
Is it possible to restore amqhlctl.lfh from S0000000.LOG, S0000001.LOG and S0000002.LOG?
When I have stopped qmgr, I have backed up only .LOG files, and forgot to backup amqhlctl.lfh, now I would like to dump that log.
I have actual amqhlctl.lfh file of that qmgr, but it's not consistent, since it was restarted in the mean time. Any chances to do it or not? |
|
| Back to top |
|
 |
| jcv |
| Posted: Tue May 08, 2007 7:10 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
Without any intervention on amqhlctl.lfh, it reports:
AMQ7701: DMPMQLOG command is starting.
LOG FILE HEADER
***************
counter1 . . . : 63084 counter2 . . . : 63084
FormatVersion . : 3 StrucId . . . . : 'HLFH'
logactive . . . : 3 loginactive . . : 2
logsize . . . . : 1024 pages
baselsn . . . . : <0:19:23168:0>
nextlsn . . . . : <0:19:23215:26427>
lowtranlsn . . : <0:19:23215:23448>
minbufflsn . . : <0:19:23215:23664>
headlsn . . . . : <0:19:23215:23448>
taillsn . . . . : <0:19:23215:26426>
hflag1 . . . . : 0
-> CIRCULAR
HeadExtentID . : 2 LastEID . . . . : 1178513485
LogId . . . . . : 1153501946
FirstArchNum . : 4294967295 LastArchNum . . : 4294967295
nextArcFile . . : 4294967295
FileCount . . . : 3
Files . . . . . : 2, 0, 1
LastCId . . . . : 1153501951 softmax . . . . : 4194304
AMQ7719: DMPMQLOG command is using a default of '0:19:23215:23448' for the starting dump location.
AMQ7723: DMPMQLOG command cannot find the requested Log Sequence Number (LSN).
AMQ7716: DMPMQLOG command has finished unsuccessfully.
From the documentation:
Log File Header
Each log has a single log file header, which is always the first thing formatted by the dmpmqlog command. It contains the following fields:
logactive The number of primary log extents.
loginactive The number of secondary log extents.
logsize The number of 4 KB pages per extent.
baselsn The first LSN in the log extent containing the head of the log.
nextlsn The LSN of the next log record to be written.
headlsn The LSN of the log record at the head of the log.
tailsn The LSN identifying the tail position of the log.
hflag1 Whether the log is CIRCULAR or LOG RETAIN (linear).
HeadExtentID The log extent containing the head of the log.
it looks like I would have to recover LSN data from .LOG files. Is there a way to do that? Thanks. |
|
| Back to top |
|
|
| dgolding |
| Posted: Tue May 08, 2007 8:04 am Post subject: |
|
|
Yatiri
Joined: 16 May 2001
Posts: 668
Location: Switzerland
|
No, AFAIK. But, why do you need to recreate it? You're using circular logging,so you have no media to archive, you just want to recreate your log file directory.
If you build a dummy queue manager with circular logging with exact same spec of number and size of log files, then rename this directory (in /var/mqm/log ) to be the same name as your busted queue manager this will work (make sure the queue manager is not running!) |
|
| Back to top |
|
|
| jcv |
| Posted: Tue May 08, 2007 8:25 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
Yes, thank you, I did it already (created temporary qmgr just for dump log purposes). The only catch is to use -b switch, then it works, otherwise reports what I already posted.
And if I copy original QMQMOBJCAT it works even better. |
|
| Back to top |
|
|
| jcv |
| Posted: Tue May 08, 2007 10:52 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
My intention was to use recovery log for auditing purposes. I have noticed heavy cpu workload placed on amqzlaa0_nd process which prevented the whole system to function properly and which didn't stop until I restarted qmgr.
During normal workload I see only 3 amqzlaa0 instances with some arguments like -fip0 , 1, and 2. Now I try to analyze log to see what was the qmgr doing. I didn't get any FDC files or something. I know that maybe problem was caused by some instance of some application which died after receiving qmgr quiescing exception, but looking at top processes I couldn't tell which application was problematic. amqzlaa0_nd used about 50 % of cpu time, while the second process on a top list (some application which uses that qmgr, and which never caused any problems) used only about 5 %. Probably better idea was to kill that process...
Last edited by jcv on Wed May 09, 2007 6:55 am; edited 1 time in total |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue May 08, 2007 11:00 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I'm fairly sure that the recovery log is not adequate for auditing purposes, particularly when you're using CIRCULAR logging.
And that goes double if you're using non-persistent messages.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue May 08, 2007 11:56 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jefflowrey wrote: |
I'm fairly sure that the recovery log is not adequate for auditing purposes, particularly when you're using CIRCULAR logging.
And that goes double if you're using non-persistent messages. |
I'm fairly certain it's not... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jcv |
| Posted: Wed May 09, 2007 1:10 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| I didn't have neither any API exit prepared nor trace for API calls turned on, so my only hope was recovery log. I'm going to set up an API exit for monitoring all API calls issued on that qmgr, hopefully it will not introduce an excessive overhead until I figure out the problematic application. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed May 09, 2007 1:44 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jcv wrote: |
| hopefully it will not introduce an excessive overhead until I figure out the problematic application. |
Nope, it's likely to kill performance! 
Monitoring all API calls for a queue manager and tracing them is going to be a lot of additional work. You're likely to feel it in resource terms.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jcv |
| Posted: Wed May 09, 2007 3:02 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| And what does amqzlaa0_nd process do, in compare with amqzlaa0 -fip? This is Solaris machine, the only thing I know of them (and I assume they are related) is that amqzlaa0 implement LQM agent. |
|
| Back to top |
|
|
| dgolding |
| Posted: Wed May 09, 2007 3:07 am Post subject: |
|
|
Yatiri
Joined: 16 May 2001
Posts: 668
Location: Switzerland
|
amqzlaa_nd = non-DCE version.
You'll find in /usr/mqm/bin that amqzlaa0 is actually a link to amqzlaa_nd.
The -fip is a reference to a file that contains the command line, which is really annoying because it would be nice to know which agent this process is running for, but you can't see it with a "ps". |
|
| Back to top |
|
|
| jcv |
| Posted: Wed May 09, 2007 4:01 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
True, it is a link:
lrwxrwxrwx 1 mqm mqm 24 Jun 20 2006 /opt/mqm/bin/amqzlaa0 -> /opt/mqm/bin/amqzlaa0_nd
I assume this details on implementation are not free, where did you find them? My search for a keyword "fip" in the docs leads only to ssl fips, which have nothing to do with this command line arguments for amqzlaa0 (I suppose). Although, right now, my main interest is to find out what caused such qmgr behaviour. |
|
| Back to top |
|
|
| dgolding |
| Posted: Wed May 09, 2007 4:17 am Post subject: |
|
|
Yatiri
Joined: 16 May 2001
Posts: 668
Location: Switzerland
|
I assume when say
| Quote: |
| details on implementation are not free |
you don't mean that if you pay IBM money they will tell you what it is
I don't think you'll the "fip" interface documented in public anywhere, it's internal to IBM. |
|
| Back to top |
|
|
| jcv |
| Posted: Wed May 09, 2007 4:48 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| I don't care what it is - when it works fine. Since it didn't complaint about anything, it must have worked properly, but the input caused overload of the process. That's why I'm looking for a way to monitor API calls. The only thing which worries me is the possibility that it didn't log any errors, didn't receive excessive API requests, and it still wasted cpu. I hope there is no such possibility. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed May 09, 2007 5:01 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
What version/FixPack of MQ?
Did you search IBM's website for issues with this process using excessive CPU?
Are most of the applications connecting to this qmgr using bindings or client channels?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
