Re: Informix running on Linux

In article <E96FIs.D3t@news.nsw.CSIRO.AU>, Peter Wiley <peter@prospect.a nprod.csiro.au> writes > >In article <pf7LsCABi7XzEw5n@smooth1.demon.co.uk> David Williams ><djw@smooth1.demon.co.uk> writes: > >[snip] > >> I think they should >> >> a) dump SE it's outdated > >NO No No No No noooooooooooooooooooooooooooooooooooooooooooooooooooo. Yes - SE is crap. If you lose power to the machine - as a site of mine did recently then the database gets corrupted. There is no automatic rollback and recovery from crashes. It is just not reliable. The customer had a crash 3pm Tuesday. They just rebooted which of course automatically repaire filesystems. This left some SE tables corrupt. The client did not notice until 4:45pm. i.e. carried on running updates on corrupt tables making the situation worse. Eventually they receive errors and called us. I ran bcheck and found errors on around 4 to 6 tables (the exact number escapes me). One corrupt table was job (200Mb for the .dat file and it had 13 indexes on it). bcheck wanted to rebuild all of them. It then failed with out of buffers (probably used up all of memory)... You EXPECT ME TO BUILD 13 INDEXES ON A 200MB TABLE TO RECOVER ONE PARTIAL UPDATE... I then tries to unload the table and reload it...bases on the rate of growth of the .dat file the reload would not finish until 10pm! I would then need to rebuild indexes. Next do the other tables including a job progress table which was 3-4 times the size of the job table.... Basically I had to restore the database from backup. Note at this point the transaction log contains my drop table and the reinsertion of the rows.....bad mistake... Since was are not responsible for UNIX/backups we had to get the customers IT department to do the restore. Of course they go home at 4pm... The next day they did not get in until 11am (at 9am I actually got an answer machine...pelease leave a message and someone will call you!!).They started the restore of the database (you can't restore just the corrupt tables as the system catalogs do not them match the actual tables. This finish arounf 3pm but the person running it has gone into a meeting so I did not heard it was done until ~4pm. THE TRANSACTION LOG FOR THE DAT WAS 192MB! THIs INCLUDES MY UNLOAD DROP AND INSERT AND AS SE DOES NOT SUPPORT TIMED RESTORE AND HITTING CTRL-C DURING A ROLLFORWARD WOULD RESULT IT A CORRUPT DATABASE - NO FAST REECOVERY REMEMBER... I told the customer first thing Thursday morning that a) we were able to restore the backup .. b) We now had the database in the same state as on Morning as we could not do the rollforward so they would have to redo Tuesday work... I would not have made the mistake with SE if I used it more often but I'm used to online...why should I learn two DB engines from one vendor?? Beside even if I had made no mistake rolling forward a days work could have easily taken several hours. THERE ARE NO ONLINE ARCHIVES OR LEVEL 1 LUCHTIME ARCHIVES POSSIBLE UNSING SE. THUS RESTORE TAKES LINGER. >I trust that's clear enough. > >SE is one of the all-time *great* database products for small databases & >sites who don't want/can't afford a DBA to nursemaid a pain in the arse >DBMS. It works just fine for databases in the <10Gb range that don't need Hence they carry on using a corrupt database until it's sh*t and have IT staff who don't realise the importance of fast restores... >BLOBs and don't need to be up 24 hours/day. Of need fast recovery/ timed restore i.e. reliablity. > >If you're serious, I suggest you're seriously out of touch with where an >awful lot of peoples' systems are. > >A cheap SE port to Linux - now that'd be something to play with. Excellent >hook to get people learning. > Try a cheap port of DSA 7.2 which supports timed restores. ONE RELIABLE ENGINE TO LEARN, NAD ENGINE WHICH CAN RECOVER FROM POWER FAILURES... >Oracle & Progress have nothing like SE in terms of simplicity combined >with the functionality. Hell, Progress still doesn't have Stored Procs or >dictionary RI. > >Peter Wiley -- David Williams