tim@ohday.sybase.com (Tim Wood) (01/24/91)
In article <116@jetson.UUCP>, danq@jetson.UUCP (Daniel Quinlan) writes: > 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? Yes, I'll take a crack at some. I am the lead development engineer for the rearchitecture of the DUMP/LOAD facility in our upcoming Release 5.0. I'll attempt a response, with the observation that more effective help can be obtained from our Customer Support department than from the net, even from a Sybase respondent. Please excuse the delay, our mail/news server has been undergoing a painful upgrade, but is now ambulatory. > > 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. We plan to offer full support for multi-file multi-volume dumps to tape devices as such in Release 5.0. All dump devices will be seen as removable-volume devices and treated uniformly. In addition to proper device support, this will allow, for example, dumps to disk to be image-copied to tape once they're done, then reloaded from the tape at LOAD time. The DUMP and LOAD syntaxes will be extended to allow either Sybase logical device or physical device names to be specified. Reaching the "end", or filling up, a fixed disk will allow the user to copy the disk to another disk or tape with the operating system, then resume dumping to the same disk. The requirement to list dump devices in the database may be dropped. > 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. We plan to support dumping/loading over the network to/from a DBLIB program in Release 5.0. (The DBLIB program would control the physical device.) Note that a network dump drastically limits I/O throughput, because packet size is limited and the channel is serial. The ideal arrangement for sharing is to have the tape device connected to several machines via a switchbox, if available. > 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. In Release 5.0, the dump/load facility will periodically return messages to the user with just this information. > Backup tapes are not > labeled, so there is no way to discover what is on a backup > tape without reloading it. The user can physically label the dump media with the server name, database name, date/time, etc. Since the unit of recovery is currently the database, additional labeling is not necessarily meaningful. We may store the database name and whether the archive is a database or transaction log in non-reserved string fields of the ANSI header labels. The date fields in those labels allow time sequencing. > 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. A utility (not part of DUMP) called "movedb", that supports this operation among others, is in QA now. It operates on on-line databases, not on backup volumes. Call your sales or support rep for availability dates. > 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. I believe you may be confused about the distinction between a Sybase "database" vs. the disks that the database uses. A server manages several databases which may share disks, but since databases don't share objects, dump and load operate on the unit of a database, because that is currently the smallest unit of recovery. We see it as at most a minor inconvenience to run a handful of commands rather than one; also dumping databases independently allows scheduling based on usage patterns. The "movedb" utility allows copy-out of all the databases on a server. > 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. We plan to support multi-database/multi-volume dumps in 5.0. > 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! Recourse exists for such problems. We have special recovery mechanisms intended for use under supervision of our Customer Support dept. You should call them for information on accessing them. We plan to make major improvements in DUMP/LOAD performance in Release 5.0. > 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. I will note this as a feature request. You can also submit such requests to your Customer Support representative, again with greater reliability than submitting to the net. > 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. ... > [ conspiracy theory deleted :-] This is an existing feature request. I remember submitting it myself! Though I've been referring here to Release 5.0 as the target for backup enhancements, we are evaluating whether to put some of them, such as performance improvement and 8MM support, into a maintenance release before 5.0. HTH, -TW Sybase, Inc. / 6475 Christie Ave. / Emeryville, CA / 94608 415-596-3500 WORK:tim@sybase.com {pacbell,pyramid,sun,{uunet,ucbvax}!mtxinu}!sybase!tim PLAY:axolotl!tim@toad.com {sun,uunet}!hoptoad!axolotl!tim Dis claim er dat claim, what's da difference? I'm da one doin da talkin' hea.
tim@ohday.sybase.com (Tim Wood) (01/24/91)
In article <12261@sybase.sybase.com> tim@ohday.sybase.com (Tim Wood) writes: > >In article <116@jetson.UUCP>, danq@jetson.UUCP (Daniel Quinlan) writes: >> Backup tapes are not >> labeled, so there is no way to discover what is on a backup >> tape without reloading it. > >The user can physically label the dump media with the server name, >database name, date/time, etc. ... >We may store the database name and whether the archive is a database >or transaction log in non-reserved string fields of the ANSI header labels. >The date fields in those labels allow time sequencing. Late update: it's looking like we will write a label block with interesting information at the front of each dump file. Sybase, Inc. / 6475 Christie Ave. / Emeryville, CA / 94608 415-596-3500 WORK:tim@sybase.com {pacbell,pyramid,sun,{uunet,ucbvax}!mtxinu}!sybase!tim PLAY:axolotl!tim@toad.com {sun,uunet}!hoptoad!axolotl!tim Dis claim er dat claim, what's da difference? I'm da one doin da talkin' hea.
rpburry@ncs.dnd.ca (Paul Burry) (01/25/91)
In article <12261@sybase.sybase.com> tim@ohday.sybase.com (Tim Wood) writes: | |In article <116@jetson.UUCP>, danq@jetson.UUCP (Daniel Quinlan) writes: | |> 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? | |Yes, I'll take a crack at some. I am the lead development engineer for |the rearchitecture of the DUMP/LOAD facility in our upcoming Release 5.0. |I'll attempt a response, with the observation that more effective |help can be obtained from our Customer Support department than from the |net, even from a Sybase respondent. Please excuse the delay, our mail/news |server has been undergoing a painful upgrade, but is now ambulatory. | |> |> 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. While on the subject of backups and 8mm tape drives, can you either now or in the future (version 5?) direct SYBASE to perform a backup and use multiple tape drives in parallel? While 8mm is attractive because of the obvious capacity of the tapes, backing up a large multi-gigabyte database would take many hours at ~250 kb/s. I would gladly pay for the extra 8mm drives if they could be used in parallel. How do others back up their large SYBASE databases? What types of devices do they use? ---------------------------------------------------------------------- Paul Burry Voice: (613)-991-7325 Internet: rpburry@ncs.dnd.ca Fax: (613)-991-7323 UUCP: ..!{uunet,cunews}!ncs.dnd.ca!rpburry -- ---------------------------------------------------------------------- Paul Burry Voice: (613)-991-7325 Internet: rpburry@ncs.dnd.ca Fax: (613)-991-7323 UUCP: ..!{uunet,cunews}!ncs.dnd.ca!rpburry
tim@ohday.sybase.com (Tim Wood) (02/11/91)
In article <1991Jan25.012332.13363@ncs.dnd.ca> rpburry@ncs.dnd.ca (Paul Burry) writes: > >While on the subject of backups and 8mm tape drives, can you either >now or in the future (version 5?) direct SYBASE to perform a backup >and use multiple tape drives in parallel? ... >I would gladly pay for the extra 8mm drives if they could be used in parallel. We plan to support the feature you describe, called dump striping, in Release 5.0. -TW Sybase, Inc. / 6475 Christie Ave. / Emeryville, CA / 94608 415-596-3500 WORK:tim@sybase.com {pacbell,pyramid,sun,{uunet,ucbvax}!mtxinu}!sybase!tim PLAY:axolotl!tim@toad.com {sun,uunet}!hoptoad!axolotl!tim Dis claim er dat claim, what's da difference? I'm da one doin da talkin' hea.