| Author |
Message
|
| gman |
 Posted: Thu Jun 02, 2005 6:08 am Post subject: How to determine if full repositories are in Synch? |
 |
|
Newbie
Joined: 15 Dec 2004
Posts: 4
Location: Pennsylvania
|
| How can I determine if the two full repositories in my MQ cluster are in synch? I am running MQ 5.3 with CSD 7. Thanks. |
|
| Back to top |
|
 |
| sebastianhirt |
| Posted: Thu Jun 02, 2005 6:14 am Post subject: |
|
|
Yatiri
Joined: 07 Jun 2004
Posts: 620
Location: Germany
|
Hi,
I don't recall an easy way that does not involve comparing what you have on the one and what you have on the other.
But theoretically (Correct me somebody if I am wrong) the SYSTEM.CLUSTER.REPOSITORY.QUEUES should have the same depth.
Also you should find something in your errorlogs if it fails.
cheers
Sebastian |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Thu Jun 02, 2005 6:26 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
amqrfdm could help (if you are on windows or unix), but just a guess.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Jun 04, 2005 6:00 am Post subject: Re: How to determine if full repositories are in Synch? |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| gman wrote: |
| How can I determine if the two full repositories in my MQ cluster are in synch? I am running MQ 5.3 with CSD 7. Thanks. |
If the channels between the two FRs are able to run, trust IBM, and assume all is well.
What are you really trying to find out?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Jun 04, 2005 12:47 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Use runmqsc to display all cluster objects.
Redirect the output into a file
Analyse both files for differences.
Enjoy  |
|
| Back to top |
|
|
| gman |
| Posted: Mon Jun 06, 2005 9:42 am Post subject: Re: How to determine if full repositories are in Synch? |
|
|
Newbie
Joined: 15 Dec 2004
Posts: 4
Location: Pennsylvania
|
Thanks for your responses. I am really trying to do the following:
I have an MQ (ver 5.3 CSD 7) cluster running on a couple Windows 2000 Advanced Server (SP4) machines. I need to do a restore of one of the servers (SRV2) to an earlier point in time (due to some changes that took place during recovery testing). This machine contains a FULL repository queue manager (QM_FR2) and a PARTIAL repository queue manager (QM_PR2). There is also a FULL (QM_FR1) and PARTIAL repository (QM_PR1) on another server (SRV1).
My plan to do so was as follows.
Original Status will be:
-All queue managers in MQ cluster are started
-Server SRV2 (containing QM_FR2 and QM_PR2) just restored from an earlier point in time.
Steps I will take:
-STOP queue manager QM_PR2 (w/ partial repository) (Don't know that I need to do this now?.?.)
-Stop the auto defined sender channels (SYSTEM.DEF.CLUSSDR) on the FULL repository being refreshed (QM_FR2).
-RUNMQSC QM_FR2
-REFRESH CLUSTER(PROD) REPOS(NO)
-END
-Restart “stopped” SYSTEM.DEF.CLUSSDR channel for QM_FR2
-Review the two full repositories (QM_FR1 and QM_FR2) verify they are sync'ed
-START queue manager QM_PR2 (w/ partial repository)
-Stop the auto defined sender channels (SYSTEM.DEF.CLUSSDR) on the PARTIAL repository being refreshed (QM_PR2).
-RUNMQSC QM_PR2
-REFRESH CLUSTER(PROD) REPOS(NO)
-END
-Restart “stopped” SYSTEM.DEF.CLUSSDR channel for QM_PR2
My main questions are:
1. Are the REFRESH CLUSTER(PROD) REPOS(NO) commands correct for both the FULL and PARTIAL repositories above?
Or do I need to use REPOS(YES) on the FULL to accomplish this? I know (believe) I would first have to demote it to a PARTIAL before doing this.
2. It was suggested that I verify the 2 FULLs are synched before I REFRESH the PARTIAL repos. Sounds logical but how do I verify this?
I have read the IBM SCRIPT (MQSC) Command Reference Redbook (REFRESH CLUSTER pg 278) and searched for postings on this and IBM's site (found a very interesting one "Image backup of a Full Repository QM. Then a restore. Uh-oh" that Peter took part in - Jan 2004) but I am still uncertain.
Any thoughts or suggestions of additional resources on this topic are appreciated. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jun 06, 2005 11:28 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I believe the best you could go with would be to demote the full repository that got recovered to a partial than make it a full repository again. It should pump its information from the other FR that stayed fine.
In future I would advise (if you can) to demote the full repository to partial before the recovery. This way you would not corrupt the existing FR that is not affected by the recovery process.
Enjoy |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Jun 06, 2005 3:48 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| sebastianhirt |
| Posted: Tue Jun 07, 2005 1:45 am Post subject: |
|
|
Yatiri
Joined: 07 Jun 2004
Posts: 620
Location: Germany
|
I think I should re-read the documentation about how MQ stores repository information! This sounds like a really little number to me, considered that you have so many objects. I was led to belive that every object in the cluster would create one message in the CLUSTER.REPOS.QUEUE?!  |
|
| Back to top |
|
|
| Nigelg |
| Posted: Tue Jun 07, 2005 6:12 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| Initially each cluster object is represented by an individual msg in the REPOS queue, but the individual msgs are consolidated at some time by the cluster maintenance routine. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jun 07, 2005 9:10 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
As a little interesting excercise, on a test system, issue REFRESH cluster, and note the depth of the S.C.R.Q. before and after each REFRESH. Keep refreshing (space them like 30-60 seconds apart). Once the depth gets close to 1000, the next refresh will compress the messages down to a couple of dozen.
Because REFRESH cluster causes a lot of activity in the clusters, don't do it where message throughput cannot be compomised. Some of your cluster XMITQs will rise to several hundred for a couple of seconds, depending on how big your cluster is.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
