Rick's right, users with the file already open won't know about the new
index.
In Perry's case, that's easy to work around, so I didn't think about that.
I still think mucking with the right bits or bytes in INDEX.MAP will put
the index in the right state to fake out any process that _subsequently_
opens the file so they will update the index going forward.
Then you can go backpopulate the index either thru your own program that
writes to the INDEX.nnn file directly, or maybe a controlled
record-by-record delete & restore of the data records.
On 4/28/2011 1:29 PM, Rick Nuckolls wrote:
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
_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users
