eik@os.is (Einar Kjartansson) (03/04/89)
We have been using Oracle on HP 9000/840 computer for about 3 months. During during this priod the database has become corrupted twice, both times resulting in total loss of data. The Oracle support people in Danmark have not come up with any useful information about this. One of the first symptoms is that the exp utility which is used to export data out of the database (i.e. for backups) stops working, this is a sample output: Connected to: ORACLE V5.1.22.2 - Production Enter array fetch buffer size(default is 4096)> Export file: expdat.dmp > E(ntire Database), U(sers), or T(ables): U > E Export Grants (Y/N): N > Y Export the rows (Y/N): Y > Compress extents (Y/N): Y > Exporting the entire data base. . Exporting user definitions. . Exporting all space definitions. . Exporting all clusters. Oracle Error: ORA-0038: ksbgrb: incorrect table RBA in row block EXPORT terminated due to error Both times that this happened we ended up rebuilding the database from backups, resulting in the loss of several days of work. This raises some questions: Do things like this happen to others? on hp9000/3?? or hp9000/8?? ? Why is there no way to patch up a corrupted database? Is our experience with the usefulness of the Oracle support typical? -- Einar Kjartansson | eik@os.is Orkustofnun (National Energy Authority) | eik@geysir.uucp Grensasvegi 9, IS-108 Reykjavik, Iceland | mcvax!hafro!geysir!eik Phone: 354-1-83600 Fax: 354-1-688896 Home: 354-1-16407
pavlov@hscfvax.harvard.edu (G.Pavlov) (03/05/89)
In article <115@geysir.os.is>, eik@os.is (Einar Kjartansson) writes: > > We have been using Oracle on HP 9000/840 computer for about 3 months. > During during this priod the database has become corrupted twice, > both times resulting in total loss of data.... [extract from dump attempt] > Connected to: ORACLE V5.1.22.2 - Production > > Exporting the entire data base...... > > Oracle Error: ORA-0038: ksbgrb: incorrect table RBA in row block > > EXPORT terminated due to error > > Both times that this happened we ended up rebuilding the database from > backups, resulting in the loss of several days of work. > I fail to understand how anyone can seriously consider purchasing a DBMS that insists on "improving" performance by bypassing a given system's file management facility. It's a cheap method for the vendor, but as the above has discovered, may be very expensive to the user. The problem may be user error, system glitch, or dbms error. Regardless of which, the user is now faced with a big black box (a large extent of disk space known only as a huge "file" to the system) which is difficult to pene- trate with the usual system debugging tools and has to be overwritten in toto from backup. What did this user gain and was it really worth it, if (s)he did ? greg pavlov, fstrf, amherst, ny
jas@ernie.Berkeley.EDU (Jim Shankland) (03/07/89)
In article <735@hscfvax.harvard.edu> pavlov@hscfvax.harvard.edu (G.Pavlov) writes: >In article <115@geysir.os.is>, eik@os.is (Einar Kjartansson) writes: [about how Oracle has repeatedly soiled its filesystem on an HP 9000/840, causing loss of several days' work each time ...] > I fail to understand how anyone can seriously consider purchasing a DBMS > that insists on "improving" performance by bypassing a given system's file > management facility. It's a cheap method for the vendor, but as the above > has discovered, may be very expensive to the user.... The user is > now faced with a big black box (a large extent of disk > space known only as a huge "file" to the system) which is difficult to pene- > trate with the usual system debugging tools and has to be overwritten in > toto from backup. There are some persuasive reasons for rolling your own filesystem when you're implementing a DBMS, especially on UNIX, whose filesystem serves DBMS implementors poorly. The problem is not just speed, but reliability. Ideally, you'd like the UNIX vendors to provide reasonable file system services; but if they don't, you're stuck with either using the miserable services they provide, or rolling your own. Of course, if you do roll your own, you need to do the whole job. That means being damned sure it's robust and correct, *and* providing filesystem debugging, repair, and analysis tools. Doing the job right is by no means "a cheap method for the vendor." Jim Shankland jas@ernie.berkeley.edu "There is no help, for all these things are so, And all the world is bitter as a tear."