RE: Need some infos for large backups
The application in question only runs for 12 hours a day, so we have the added advantage that we can guarantee referential integrity across all the databases/instances as far as the backups are concerned. However we do realize that there is still a problem with the referential integrity of the logical logs. Any comments from you netters. --------------------------------------------- All opinions are my own Neil Stevenson nmsteven@eukcumbpo1.unitedkingdom.attgis.com Voice: +44 1236 851218 Fax: +44 1236 457459 --------------------------------------------- ---------- From: rafal To: informix-list Subject: RE: Need some infos for large backups Date: 19 September 1995 01:11 Just remeber that you cannot define referential integrity accross databases. Regards, Rafal Czerniawski DATASPACE CONSULTING Pty. Ltd. nmsteven@eukcumb1po.unitedkingdom.ATTGIS.COM (Neil M Stevenson) wrote: > >Large database backup can mean large bucks :-) > >I am currently involved with a large database (~80 - 100Gb) and we have come >up with the following solution. > >The database will be split into about 10 instances. The primary instance >will then have synonyms created in it to point to the tables in the other 9 >instances. This means that as far as the application/client is concerned, >there is only one database and one instance. >With the 10 instances, we can run 10 x 10Gb backups in parallel. Obviously >with 10 backups running at the same time, this will be a big hit on your >server. A general rule would be to have no more than two tape devices on >each SCSI bus however this may change according to your hardware. i.e. you >need a further 5 SCSI controllers in your machine.($$$) The tape devices >which we will be installing are DLT drives which can store 10Gb or 20Gb >compressed on one tape. So no need for tape changers or tape array over >multiple drives. One problem you now have is logical logging. Do you now >add a further 10 exabyte drives or do you utilize the 10 DLT's??? >A big benefit from this would be the amount of time required for a recovery. > You have also opened the opportunity to move some of your instances onto >another machine.($$$) >The disadvantage for this solution is the fact that administration becomes a >bit more difficult. :-( > >The solution has to fit your circumstances. How long does your database >have to stay on-line? What are the requirements for recovery? Is there >going to be a mirror system? If there is, is it a hot mirror? >I'm sure that there are plenty of DBA's out there that will have comments on >the above but my skin is thick, I can handle it. > >HTH > --------------------------------------------- >All opinions are my own >Neil Stevenson >nmsteven@eukcumbpo1.unitedkingdom.attgis.com >Voice: +44 1236 851218 >Fax: +44 1236 457459 > --------------------------------------------- Rafal Czernaiwaski - rafal@magna.com.au Dataspace Consulting Pty Ltd