ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General IBM MQ Support » Rebuilding queue index

Post new topic  Reply to topic
 Rebuilding queue index « View previous topic :: View next topic » 
Author Message
mgrabinski
PostPosted: Fri Sep 12, 2003 2:44 am    Post subject: Rebuilding queue index Reply with quote

Master

Joined: 16 Oct 2001
Posts: 246
Location: Katowice, Poland

Hi

Do you know if index set on a non-shared queue on z/OS can be dynamically rebuilded? I know that rebuildung takes place during queue manager start. Is there any way to force it during work?
_________________
Marcin Grabinski <><
Back to top
View user's profile Send private message
GMcCarthy
PostPosted: Fri Sep 12, 2003 5:40 am    Post subject: Reply with quote

Centurion

Joined: 06 Nov 2001
Posts: 113
Location: Melville NY

Marcin,

I don't have an answer for you...still researching. May I ask why you would want/need to do this dynamically?
_________________
Regards,
Gina

IBM Certified MQSeries Specialist
Back to top
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger
mgrabinski
PostPosted: Fri Sep 12, 2003 6:27 am    Post subject: Reply with quote

Master

Joined: 16 Oct 2001
Posts: 246
Location: Katowice, Poland

I have a couple of queues with quite frequent puts and gets (with matching correlid). The queues are indexed - by correlid. Every day there are some 5000 messages put and got to/from those queues. Not every get is succesful - there some 200-300 misses per day. This is not bad - it's about 5% - but after few days, the queues contain thousands messages. When a new message comes, it is wriiten at the end. Getting applications waste huge amount of time to get to the right message - they cannot use the index, since it's not up to date.

I can't restart the queue manager every night. Once-twice a month is all I can do.
_________________
Marcin Grabinski <><
Back to top
View user's profile Send private message
EddieA
PostPosted: Fri Sep 12, 2003 6:35 am    Post subject: Reply with quote

Jedi

Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles

There is no way, from an application, that you can tell it to use, or not to use, the index. This is all handled internally within MQSeries.

Are you saying that GETs using CorrelationID return a 2033 even when the message is present.

I'm not sure what you mean by:
Quote:
Getting applications waste huge amount of time to get to the right message


Do you mean the application BROWSEs the queue checking the CorrelationID of each one, looking for a match.

Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0
Back to top
View user's profile Send private message
GMcCarthy
PostPosted: Fri Sep 12, 2003 6:49 am    Post subject: Reply with quote

Centurion

Joined: 06 Nov 2001
Posts: 113
Location: Melville NY

I found a discussion similar to what you are speaking of. Please let me know if this helped.

Performance Correlid Index
_________________
Regards,
Gina

IBM Certified MQSeries Specialist
Back to top
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger
PeterPotkay
PostPosted: Sat Sep 13, 2003 3:25 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

If you are 5.3, check out the MQSC script manual (http://publibfp.boulder.ibm.com/epubs/html/csqzaj09/csqzaj09tfrm.htm).

Look for the IndxType section under the DEFINE QUEUE command. To me it says that if you alter this attribute of the queue from CORRELID to NONE and then back again, and there are no uncommitted units of work in this queue, the index will be rebuilt, without a QM restart.

I know at 5.2, the QM definitly needed to be restarted.

See my results for testing this.
http://www.mqseries.net/phpBB2/viewtopic.php?t=5475&highlight=index

My tests indicate that even as you put more messages to the queue, the index is maintained and updated.

Marcin what you say is if I have 2 messages on an indexed queue, and I restart the QM, the index is forever only for just those 2 messages??? As more messages get added, the index ignores them? Until the next QM restart (at 5.2)? My test results don't agree
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
mgrabinski
PostPosted: Mon Sep 15, 2003 10:06 pm    Post subject: Reply with quote

Master

Joined: 16 Oct 2001
Posts: 246
Location: Katowice, Poland

I'm not sure about rebuilding of the index. I noticed long times needed to complete an MQGET with matching CorrelId. The queue in question is indexed. I guessed it was due to problem with indexing, but then I noticed even longer times in a queue without index. So I may have been wrong.

It would be great if someone from Hursley labs clarified this issue for us all. Is the queue index rebuilt in flight or not? What is the cost?

I need to investigate the problem more thoroughly - I will collect data from MQ trace for a week or so and will see the general picture.

Thank you for you posts so far.
_________________
Marcin Grabinski <><
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General IBM MQ Support » Rebuilding queue index
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.