cindy@dprmpt.UUCP (Cynthia Mumford) (03/21/90)
In article <28403@sequent.UUCP> you write: > > >................................................................................. > >I have taken upon a project which entails finding out various Backup/Recovery >methods people are using with some (very) large databases. I will currently be >looking into databases on UNIX but would encourage any response in this regard > >Some of the obvious questions of interest are: > > Do they depend upon (OS) UNIX utilities/tools? > Do they use off-the-shelf vendor supplied tools? > Time and efforts required to do all this? > How large a database can these tools backup? > Whether backup could be done Online? > Is there any Operator interface required? > Do they allow incremental backups? recovery? > >It would be very interesting if people from some of the databases' company >would like to participate and clarify their positions in this regard. The >results of this study will be posted on this net sometime next month, if I >can collect enough information. > >Thank you, one and all, for your help. > > >Kamal K Maheshwari. > >e-mail: ...!{ogicse,uunet}!sequent!kamal >................................................................................. We are running Oracle Versions 6.0.26 and 6.0.27 on an Amdahl 5860 under UTS 1.2.3. (soon to be UTS 2.0.1). Currently we have 5 databases: 1 for development, 1 for conversion, 1 for QA, and 2 for production. The conversion and production databases are each about 2.5 gigabytes. Growth of the production databases is estimated conservatively at 9 gigabytes per year. Our worst problems currently have been with the backup of the conversion database. Our backup utilities will not allow a single file to span multiple tape volumes, but in order not to exceed the UTS 1.2.3 limit of 20 open files per process we have had to make the data files very large. Oracles's export utility is deficient in its handling of exports which span multiple tape volumes. Therefore, we had a couple of alternatives: split the export into small enough files (doing it table by table) so that could back up the files, or use a very operator- intensive and error-prone method based on the volcopy command. Since the conversion data was not updated daily, it was agreed that we would back up on demand and use volcopy. This solution would not be feasible in a production environment requiring daily backups. On the topic of incremental backups, Oracle's version 6.0.26 supposedly provides that capability. However, their definition of incremental leaves something to be desired. If the table has been modified since the last backup, the entire table will be part of this "incremental" backup. There is no capability to back up only changed records. On a table containing millions of records -- an accounting journal, for example -- this does not do much good. As a matter of fact, we could have written this ourselves. For this we're paying all this money?? We would also be very interested in any information on backups of large databases -- actually, any information at all on management and administration of large databases. Cindy Mumford DBA Data-Prompt, Inc. cindy@ uunet!dprmpt