Thank you, Paul - your explanations were very clear.
Cheers.
Heinz
Paul S Dennis wrote:
Heinz,
1) this is controlled by the EXCLINT
parameter on the backup cfstruct command. Is basically says that only
data
older than this value should be backed. The default is 30 secs. The
assumption
is that most data on shared queues is short lived, so by only backing
up
stuff over a certain age we can optimise the backup processing.
2) My understanding is that you just
have to issue the RECOVER CFSTRUCT command, although i am not totally
up
to speed with where the CFRM policy exists etc! The size and attributes
of the structure are defined in the CFRM policy, and this is used by
the
CF when we need to allocate the structure. Basically MQ will attempt to
connect to the structure, and if it doesn't exist then it will get
allocated
with whatever attributes are defined in the CFRM policy.
3)You need to issue the RECOVER
CFSTRUCT
command to initate recovery. I certainly didn't intend to imply
anything
else.... What I did say though was that you don't need to have all the
qmgrs in the QSG running to be able to recover the structure.
Thanks
Paul
Paul Dennis
WebSphere MQ for z/OS Development
IBM Hursley
Paul.
Thank you very nuch for the explanation. However, I will grab the
opportunity
and, if you allow me, squeeze a little further:
1) Can you please ellaborate what you mean by "persistent
messages over a certain age"?
2) Assuming the CF structure was completely wiped out (failure or
something
equivalent to a power-on-reset) does the people responsible for the CF
need to do something (define lists and/or structures) before MQ
recovers
the queues or can the whole recovery process be left to MQ?
3) My understanding was that the recovery process of a failed CF would
need to be initiated by a RECOVER CFSTRUCT command. Somehow I got the
impression
from your text that even without this command being issued MQ would do
the recovery of the shared queues upon restart. Is this correct?
Thank you again.
Heinz
Paul S Dennis wrote:
Hubert, that is not quite right! The contents of the shared queues are
rebuilt when you do a RECOVER CFSTRUCT.
When the BACKUP CFSTRUCT command is issued the contents of the CF
(persistent
messages over a certain age) are copied from the CF structure being
backed
up into the log of the qmgr doing the backup. At a later stage, if
recovery
is needed then a qmgr will read this backup, and then the logs from
this
point on of all the qmgrs in the QSG to rebuild the message content of
the queues that were on the failed structure. You don't need all of the
qmgrs to be started to do recovery, just the logs to be available and
readable
by the one queue manager that is doing recovery (hence why you need
SHAREOPTION(2
3) on the active logs, they wouldn't be readable by another qmgr
otherwise).
If you deem that the amount of time that will be required to do a
recovery
of the CF structure is too great (you forgot to backup the structure on
a regular basis!) it is possible to use the RECOVER CFSTRUCT
TYPE(PURGE)
command to make the queues/structure available, but they won't contain
any messages. There is no standard way of recovering a CF structure to
a local queue.
The original logic behind having a manual recovery of the structures is
the assumption here that if you had a failure of one structure, you may
well have the failure of multiple structures close together. The
RECOVER
CFSTRUCT command allows you to specify multiple structures to recover
at
the same time, it can then recover all of the structures with a single
read of the logs, rather than having to read for each structure.
Thanks
Paul
Paul Dennis
WebSphere MQ for z/OS Development
IBM Hursley
Hello,
There are two MQSC commands BACKUP CFSTRUCT and RECOVER CFSTRUCT, which
allow a manual rebuild of the CF structures. As far as I know, these
commands
rebuild only the structure, not the contents. Rebuilding the shared
queues
will be done by the members of the QSG. In difference to local queues
the
contents of shared queues are spread over the active logs of several
QMgrs
in the QSG. So you need not anly one but all QMgrs of a QSG, to rebuild
shared queues.
Regards
Hubert
> -----Ursprüngliche Nachricht-----
> Von: [EMAIL PROTECTED]
> Gesendet: 30.10.06 22:23:22
> An: [email protected]
> Betreff: CF Recovery in a QSG Environment
> Hello MQers.
>
> I have two questions regarding disaster recovery using QSG:
>
> 1) I was told that other products (DB2 was explicitly mentioned)
rebuild
> the Coupling Facility lists and structures themselves if the CF is
lost,
> without need of manual intervention. Does MQ do something similar?
> 2) Assuming a CF is really lost, is there any way to rebuild the
shared
> queues as local queues from the MQ log?
>
> Thanks in advance for any help.
>
> Heinz Klein
> OLTP Tecnologia & Solucoes Ltda.
> Sao Paulo/SP - Brasil
>
> To unsubscribe, write to [EMAIL PROTECTED]
and,
> in the message body (not the subject), write: SIGNOFF MQSERIES
> Instructions for managing your mailing list subscription are
provided
in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
--
Hubert Kleinmanns
Beratung / Schulung / Projektleitung
Tel.: +49 (0) 60 78 / 7 12 21
Fax: +49 (0) 60 78 / 7 12 25
Mobil: +49 (0) 178 / 6 97 22 54
To unsubscribe, write to [EMAIL PROTECTED]
and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.13.18/506 - Release Date:
30-Oct-06
List
Archive -
Manage
Your List Settings -
Unsubscribe
Instructions for managing your mailing list subscription are
provided in the Listserv General Users Guide available at http://www.lsoft.com
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.13.18/506 - Release Date: 30-Oct-06
List Archive -
Manage Your List Settings -
Unsubscribe
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
|
