| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Repository |
« View previous topic :: View next topic » |
| Author |
Message
|
| Ctischbein |
 Posted: Tue Dec 11, 2001 1:55 pm Post subject: |
 |
|
Newbie
Joined: 10 Dec 2001
Posts: 1
Location: Philadelphia
|
Seems we have a corrupted repository.
Does anyone know of a way to rebuild the repository?
Any help would be appricated!
Chris
|
|
| Back to top |
|
 |
| bduncan |
| Posted: Wed Dec 12, 2001 10:09 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
hahaha... Someone needs to write a book on this. Corrupted repositories seems to be quite a common problem with clusters. I would like to say there is a hard and fast set of rules to follow to recover, but unfortunately I've seen repositories get corrupted for many different reasons, and they usually involve unique ways of resurrecting them.
I will point out this. How many repositories have you? If more than 1, you may have some additional difficulties. If both are corrupted, and you repair one of them, the other might actually "infect" the other one with the corrupted data again!
One might think that the way around this is to turn off all sender channels on the repositories before fixing them, but then you might have repository-related messages in the transmission queues, and then after you fix everything, and start the channels again, the messages flow, corrupting the repositories again!
I'm assuming that the corruption you are experiencing is "ghost" objects. This seems to be the most common problem. You've deleted a queue or removed a queue manager from your cluster, but it still appears in the repository. Normally, this isn't much of a problem. If you are dealing with ghost queues for instance, just ignore them. Although they will always appear on the DIS QCLUSTER(*) list, the workload balancing algorithm won't actually route any messages to these queues. And after 90 days, the repositories will remove these objects because they haven't had any activity for that period of time.
As far as other types of corruption, I'm afraid you'll have to give me more detail. Usually fixing it involves repairing the full repositories, and once this is accomplished, issuing REFRESH CLUSTER(x) commands on all the queue managers with partial repositories. This command will always cause the queue manager to query one of the full repositories and rebuild its own partial repository. Unfortunately, this trick doesn't work between full repositories. In other words, you might expect to be able to issue REFRESH CLUSTER(x) on one of your two full repositories (the corrupted one) and it will query the other full repository (non-corrupted repository) for all the objects in the cluster so that it can rebuild its repository, but unfortunately it doesn't work this way. One can't take precendent over the other. When you issue the command in this way, the two repositories will basically negotiate between themselves to try and get their views of the cluster in sync. This can lead to you infecting an otherwise uncorrupted full repository.
But more info about your problem would be helpful. I've heard of people effectively clearing the queue that contains all the objects in the full repositories and being able to recover from this, but in my experience, sometimes I've had to resort to rebuilding the cluster from sratch (i.e., blowing away the queue managers).
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
