I did some investigation of this in the past, and it is a nightmare. I seem to recall that for a given process to correctly update an index, the index had to have been created and enabled at the time that the file was opened by that user. Otherwise, a user that had the file open prior to the build.index would not update the newly enabled index.
The implication is that you want to have everyone off of the system while doing a BUILD.INDEX. Alternately, create the index, build it, then rebuild it after the next restart. Building it will cause it to be "enabled", which ensures that all of the processes treat it that way at the restart. An enabled, partially built index will cause all sorts of anomalous behavior unless you specify "NO.INDEX" in all the right places. I did submit this as a problem, complete with a demo program, to Rocket a while ago. But I have no reason to believe that it has been fixed. If you are really willing to work with a partially built index... Another possible trick, if your index is "NO.NULLS" , and is built on a i-type that calls a subroutine, would be to make the return value of the subroutine blank during the first build. This will cause the BUILD.INDEX process to functionally skip the list creation for all records and enable the index immediately after the select. Once that is done, recatalog the program with the real code, but do not change the calling i-type. Thereafter, the index should be updated, at least for those processes that opened the file after the first, null, BUILD.INDEX. Depending on your OS / hardware configuration, it can sometimes be worthwhile to COUNT the file prior to the first BUILD.INDEX; causing the caching of most of the file in memory. (You can test this by COUNTing the file twice, and seeing if the second one goes appreciably faster than the first.) Indeed, once you get all of the processes updating the index, you could probably write a little program to figure out all of the ids that are indexed, MERGE.LIST INTERSECT this against the id's that should be indexed on the file, and then readu the record, blank out the reference field(s) (saving the correct record) writeu the record to create an "old version" of the record on file write the original record, thus updating the index to the current version. Rick Nuckolls Lynden Inc. On Apr 28, 2011, at 10:38 AM, Perry Taylor wrote: > Hey Chuck. > > The CONCURRENT option is actually there although it's not documented > (and I suspect not officially supported). All it really does it not > lock the file which doesn't happen until the select is completed anyway. > One would have to make sure no updates were being made to the file until > the select finishes or the index build may not be complete and accurate > or may include entries for deleted records. At this point not taking a > file lock on the data file seems less useful as the index file is going > to be cleared prior to population and the population doesn't really take > all that long in comparison to the select in most cases. In any event > seems very messy to me. > > Traditional relational databases have the option to build/rebuild > indexes while the table is in use. In the end it seems to me that > Rocket needs to come up with a completely new strategy for > building/rebuilding an index. > > Perry > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Charles > Stevenson > Sent: Thursday, April 28, 2011 10:53 AM > To: U2 Users List > Subject: Re: [U2] [UV] Marking New Index as Built > > That should work. > And then you can write your own update program to back-populate the > index w/o having to do a build at all. > > But if your & my connivings are true, then why doesn't RocketSQ give > that to us as a concurrent build option? A few years ago they (as IBM) > > declared that 7x24 uptime was a big goal for U2. > > Warm regards, > Chuck > > On 4/27/2011 2:24 PM, Perry Taylor wrote: >> I have a need in UniVerse to add a new index on a large file which has >> existing indexes. I don't have a time window in the coming days in >> which to build the index but need to use the index for new records > which >> will be added to the file after the index has been created. Is there > a >> way to force UniVerse to think that the index has been built so that > it >> can be used for newer records allowing me to defer the build to a > later >> date? >> >> Thanks. >> Perry Taylor >> Zirmed, Inc. >> >> >> >> >> CONFIDENTIALITY NOTICE: This e-mail message, including any >> attachments, is for the sole use of the intended recipient(s) >> and may contain confidential and privileged information. Any >> unauthorized review, use, disclosure or distribution is >> prohibited. ZirMed, Inc. has strict policies regarding the >> content of e-mail communications, specifically Protected Health >> Information, any communications containing such material will >> be returned to the originating party with such advisement >> noted. If you are not the intended recipient, please contact >> the sender by reply e-mail and destroy all copies of the >> original message. >> _______________________________________________ >> U2-Users mailing list >> [email protected] >> http://listserver.u2ug.org/mailman/listinfo/u2-users >> > > _______________________________________________ > U2-Users mailing list > [email protected] > http://listserver.u2ug.org/mailman/listinfo/u2-users > _______________________________________________ > U2-Users mailing list > [email protected] > http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
