Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!sun-barr!cs.utexas.edu!hellgate.utah.edu!csn!boulder!chs!danq From: danq@jetson.UUCP (Daniel Quinlan) Newsgroups: comp.databases Subject: Re: Sybase gripes Message-ID: <116@jetson.UUCP> Date: 15 Jan 91 21:15:21 GMT References: <5716@tantalum.UUCP> Organization: CHS, Inc., Boulder Lines: 95 > Hi. I'm in charge of administering a moderately large sybase database, and > I've run into a couple of things that bother me. So, I thought I'd whine > a little and see if anyone else has worked around these problems: < basically problems with backing up sybase databases to 8mm tapes. > Well, since someone else started the complaining, I have the same problem, and a few other complaints. Unfortunately, I have no solutions. Here are my complaints, however. Is there anyone from Sybase around? Backups ------- Backups are particularly difficult to perform; we use 8 mm tapes, as does most of the Unix community at this point. For some difficult to fathom reason, Sybase requires that dump devices be declared within the database, and designates an 8mm tape as a disk. For a presumably related reason, Sybase is unable to dump to multiple 8mm tapes. This limits the size of our database, and is such a serious deficiency that it could in the future cause us to move to a different data- base system. Sybase positively requires a local tape to dump to, and is unable to dump to a pipe or across the network. Networks are a reality today; having a local tape drive on a machine dedicated to a Sybase database is a waste of resources, as well as a tremendous inconvenience. During backups, there is no feedback about the progress of the backup, eg. how much has been dumped, how much remains, and how long the process will take. Backup tapes are not labeled, so there is no way to discover what is on a backup tape without reloading it. A backup tape cannot be reloaded into a smaller partition than it was in originally, even if the actual data is con- siderably smaller than the new partition size. There is no single command to completely backup a database; that is, since an actual sybase installation consists of several "databases", including "master", "model", and the actual application database(s), you might expect you would be able to back up all of them with a single command. This is not the case. Multiple database dumps to a single 8mm tape are not sup- ported. Since "master", for instance, is a very small data- base, it would be operationally convenient (for unattended overnight backups) to put multiple backups on a single tape. Similarly, it might be convenient to dump the log, then the database to a single tape. Recovery from problems -------- ---- -------- Once Sybase decides a database or a log is corrupt, there is no recovery other than to reload the entire database from backup tapes. In one particularly painful instance, Sybase was restarted, found it could not open the log (due to an error in an upgrade procedure), and marked the entire data- base "suspect". Although the log was available in uncor- rupted form, and the database was also not corrupted (at least before Sybase marked it "suspect"), there was no option other than to reload the entire database. For an 80 Mbyte database, this operation took 4-5 hours! Large applications due to LARGE STATIC libraries ----- ------------ --- -- ----- ------ --------- Because Sybase distributes their libraries in static rather than dynamic form, applications developed using their inter- face libraries are rarely smaller than 1 Mbyte. This is a tremendous waste of disk space, as well as a performance issue on machines with multiple copies of sybase applica- tions and limited memory. Other Problems ----- -------- Why is there no terminal interface for a Sun window? Eg, it is impossible to run a Sybase application compiled for an ascii terminal inside a Sun Window. This is basically incomprehensible; I assume it's a marketing ploy of some sort. Daniel Quinlan {uunet,boulder}!chs!danq System Administrator 303/442-1111 x3124 Consumer Health Services Boulder, CO -- Daniel Quinlan {uunet,boulder}!chs!danq System Administrator 303/442-1111 x3124 Consumer Health Services Boulder, CO