cheeks@edsr.eds.com (Mark Costlow) (01/15/91)
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:
1. Remote tape drives.
In this age of networked computers, and considering all of the
network-based functionality that sybase DOES have, not
supporting remote archive devices seem completely ludicrous.
Has anywone done anything to work around this problem? (I was
thinking one could set up a FIFO as a "disk byte stream" dump
device and have a daemon ship the data to a remote tape, but I
haven't had time to play with anything like that yet).
2. Lack of support for cartridge tapes.
I can't seem to find any way to get sybase to exercise any kind
of tape control on a scsi cartridge tape device. In fact, to
get sybase to write to the device at all, you have to tell it
that it's a disk! That means I can't have a database any
larger than my largest tape device. This also strikes me as
silly! Do I really have to buy a 1/2" mag tape drive to dump
my database, when my exabyte would be so much more efficient?
3. More lack of support for cartridge tapes
This is related to #2. I'm running on a Sun-4/470 with
all SCSI disks, under SunOS 4.1.1. I have my exabyte set up
as a disk byte stream device. On about 1/2 of the dumps I do,
I get a "st?: tape synchronisation lost" message from the OS
(where ? is replaced by the particular tape device). I assume
that sybase is doing (or not doing) something to the tape
device to cause this, but I haven't got a clue what. The tape
drive works fine for normal dumps and tars. Has anyone else
seen this? Barring a solution for #2, does anyone have any
ideas that I could try?
Any input will be appreciated. Thanks,
Mark
--
cheeks@edsr.eds.com or ...uunet!edsr!cheeksdanq@jetson.UUCP (Daniel Quinlan) (01/16/91)
> 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