Index rebuild

Index rebuild

Post by Matt McGeachi » Fri, 13 Aug 1999 04:00:00



Received the following error trying to do an index rebuild using Progress 6.3F13
running on HPUX 10.20:

SYSTEM ERROR: I/O error 0 in writeto, ret 8191, file 4(lbi)(srt), addr
2147475456

I'm assuming this is because the sort file could not grow past the 2 gig limit.
Documentation in higher versions talks about creating a db.srt file which would
get around this problem. I tried this with version 6 but it did not work. Does
anyone know of a way around this?

 
 
 

Index rebuild

Post by Niels Diepevee » Fri, 13 Aug 1999 04:00:00


Matt McGeachie schreef:

Quote:

> Received the following error trying to do an index rebuild using Progress 6.3F13
> running on HPUX 10.20:

> SYSTEM ERROR: I/O error 0 in writeto, ret 8191, file 4(lbi)(srt), addr
> 2147475456

> I'm assuming this is because the sort file could not grow past the 2 gig limit.

Seeing that 2147475456 + 8191 = 2^31 - 1, I think you're right.

Quote:> Documentation in higher versions talks about creating a db.srt file which would
> get around this problem. I tried this with version 6 but it did not work. Does
> anyone know of a way around this?

Split the indexes into groups that stay under the 2GB limit. If any
single index is can't be sorted within 2GB, rebuild it without sorting.

--
Niels Diepeveen
Endea automatisering

 
 
 

Index rebuild

Post by Paul T. O'Lea » Fri, 13 Aug 1999 04:00:00


On Thu, 12 Aug 1999 04:16:38 GMT, Matt McGeachie


>Received the following error trying to do an index rebuild using Progress 6.3F13
>running on HPUX 10.20:

>SYSTEM ERROR: I/O error 0 in writeto, ret 8191, file 4(lbi)(srt), addr
>2147475456

>I'm assuming this is because the sort file could not grow past the 2 gig limit.
>Documentation in higher versions talks about creating a db.srt file which would
>get around this problem. I tried this with version 6 but it did not work. Does
>anyone know of a way around this?

I s'pose you could divide and conquer. Do the rebuild in steps, doing
a portion of the indexes at a time. You do this by aswering "Some" to
the "All/None/Some" question at the beginning of the idxbuild.

You can semi-automate this by  writing a procedure using the _file and
_index metaschema tables to build flat-files with file names and index
names. You can then add an "envelope" of responses to idxbuild, and
make that the input to it. I think Dan Foreman's DBA guide even has
the text of a procedure to do this, along with instructions on how to
make it work.

AFAIK, Dan's at USI Atlanta; and I believe their web site is at
http://www.usiatl.com .
--
Paul T. O'Leary
Evco Plastics, a leader in plastics injection molding
DeForest, WI USA
paul_o at evcoplastics dot com

 
 
 

1. Difference in ranking results from a full index rebuild verses an incremental rebuild

I have a problem that I find interesting and maybe someone else will too.
I'm seeing the following behavior in my full text searches and it seems
rather bizarre. I have a full text index on a varchar column in a table with
about 18,000 rows. I have a timestamp column so I can do incremental
rebuilds.

On performing the following steps:

1. Perform a full index rebuild
2. Perform a freetexttable query and note the ranking of the results ( Call
this results 1 )

3. Insert a few hundred rows of new data
4. Perform an incremental index rebuild
5. Perform a freetexttable query and note the ranking of the results ( Call
this results 2 )

6. Perform a full index rebuild
7. Perform a freetexttable query and note the ranking of the results ( Call
this results 3 )

Now comparing the 3 results I see that the new rows I added are ranked
significantly higher in the result set for results 2, after the incremental
rebuild, than they are in results 3, after the full rebuild. I have found
that a row will go from being ranked 5th from the top after the incremental
index rebuild to 30th after a full index rebuild. This variability in the
results is not acceptable to my application.

Currently I have configured the background index update functionality and
then once a night I do a full index rebuild. I would rather not have to do
the full rebuild but it seems to be to only way I can get consistent
ranking. Has anyone else had this problem and if so is there any way to get
the incremental index rebuild to return rankings that are consistent with a
full index rebuild?

Thanks,

Marvin Hamon

2. PA-DBA

3. Index rebuilding, possible?

4. Problems w/Using Values from a Field

5. Index Rebuilds / Repairs URGENT !!

6. DBCC SQLPERF

7. dbcc, index rebuild

8. Can't install SQL 6.5 over the 120day eval

9. Large Table/Slow Index Rebuild

10. Cluster Index Rebuild very slooooooooow

11. Scheduling of fulltext index rebuild problem

12. index rebuilding

13. Index rebuilding and Sorted Data option