Re: bcheck, SE and OnLine
In article <1s8f49INN128@emory.mathcs.emory.edu> pauls@easter.euro.csg.mot.com (Paul Smith) writes: > >This is running on an Informix-SE engine (2.10.03K) on a Motorola 68040-based >platform under AT&T Unix System 5.3 > >Currently there are some 1.5 million rows in the master file and some 350000 >rows in the pairs file. > >1) Periodically, bcheck reports corruption of the index file. Any ideas > what could cause this ? We have several production systems using I4GL & SE 2.10.03F under SunOS 4.1.2. One of them contains a table that has some indexed fields updated annually in April/May. Typically, we wait till after hours, then drop all indexes on the table, do the updates, then re-index. The table has 20 columns for a total row size of around 300 bytes, and the current size is a little over 125,000 rows -- not that big in the grand scheme of things. When we recently did this annual processing, bcheck reported one of the indexes as corrupted after the re-index. This didn't happen last year, and we have neither changed the table definition nor re-indexed in the intervening time. The index is on a single char(10) field allowing duplicates. In a large percentage of the table's rows (~50%), the field in question is NULL [no editorial comments on database design, please :-)]. I didn't check, but my guess that there is not nearly so large a duplication factor for the non-NULL values. As it happens, we are in the latter stages of moving the system with the problem table to 4.10/5.00. So, we have .O3F and 4.10/5.00 test databases set up. I did an ASCII unload of the table, and all characters were printable ASCII characters. I loaded the data into an un-indexed version of the table in the .03F test database and added only the suspect index. bcheck said it was corrupted just like in the production table. I did the same thing in the 4.10/5.00 test database, and everything looked OK -- no errors from bcheck. So, I didn't investigate further. We're so close to upgrading the production system, I'm going to "wait for the next release." We were able to work around the problem by moving about a third of the rows to a separate table for "historical query only" until the upgrade is completed. To do the split, I unloaded the big table and used Unix utilities to make two unload files. I then dropped and recreated the table, along with the second holding table. I loaded and indexed the two tables, and bcheck gives no errors on either table. This process resulted in moving around 41,000 rows out of the original table into the holding table. This is perhaps not what you wanted to hear. However, if you have a way to test the problem under the newer engine, it might be worth your time. Or, you may be able to split your table based on your application. >2) Repairing the indexes takes some 8 hours, not funny on a production > system. Any tips for speeding it up ? Nothing comes to mind that you probably haven't already considered. >3) Given the amount of data, are we really asking too much of SE and should > we be looking to upgrade to an Informix-Turbo or even an OnLine system ? We ask the same question from time to time. The general word that I get is that OnLine is designed more to address scalability and contention problems on systems with large numbers of users. If you have a system with no obvious bottlenecks (low RAM, etc.) and only relatively few users, your chances of seeing dramatic improvement just by going to OnLine are very hard to predict. Perhaps others with more direct experience could comment. >Answers on a postcard please. Having a great time -- Wish you were here! The sun is wonderful and the surf is exquisite! Tomorrow a bus tour, then on to the Alps! >Regards, >Paul > >Paul Smith, Tel. : +44 (0)31 479 1233 >Motorola I.C.S.G., Fax. : +44 (0)31 479 1447 >Easter Inch, Post : w10070 >Bathgate, email: pauls@easter.euro.csg.gss.mot.com >West Lothian, Mobile: +44 (0)836 522062 >EH48 2EH Pager : +44 (0)523 623016 Good luck, Walt. -- Walt Hultgren Internet: walt@rmy.emory.edu (IP 128.140.8.1) Emory University UUCP: {...,gatech,rutgers,uunet}!emory!rmy!walt 954 Gatewood Road, NE BITNET: walt@EMORY Atlanta, GA 30329 USA Voice: +1 404 727 0648