RE: Restoring individual databases

For the curious... This company uses a legacy hierarchical structure where the applications use several databases per user. Through the applications the users have the ability to add and drop databases at will. These applications are used to produce the bread and butter and there is no interest in risking a major change at this time. So, as a DBA, I live with it. My wish for a solution to restoring individual databases is more for convenience then necessity. Currently we back up the databases by both ontape and nightly unloads to ASCII files. Using the ASCII unloads is our solution to restoring individual databases when someone "accidentally" deletes one. We are currently porting to a new platform and the latest Informix versions and the question came up, "Do we need to port the ASCII backup utilities or can Informix restore individual databases now?". I did think of putting each database in its own dbspace but that would be very difficult to maintain and keep it flexible for the applications. Thanks everyone for your responses. It looks like the only real answer to restoring individual databases is to put them in their own dbspace. Unfortunately, having to deal with so many databases, it's not a solution for us. We'll just have to port our ASCII backup utilities, not a big deal. Don. -----Original Message----- From: June Tong [mailto:june_t@hotmail.com] Sent: Thursday, November 05, 1998 5:29 PM To: informix-list@iiug.org Subject: Re: Restoring individual databases Art S. Kagel wrote: > Simpson, Don wrote: > > I've thought about that. But I have an instance with over 1400 databases in > > it. I'm thinking maintenance on that many dbspaces would be a nightmare. > > I'm not even sure Informix can handle that many. Anyone know? Not to > > mention what onbar would do on level 0 backups, fork 1400 processes for each > > dbspace? There might even be a system limitation there! > > Max 1024 dbspaces in a 2K page system (2048 on 4K page) also 1024 > chunks (or 2048). Why 1400 databases? Couldn't that have been > condensed into a relatively few databases? Anyway that's the answer. Max 2047 dbspaces no matter what pagesize. Otherwise, I agree, 1400 sounds like an awful lot of databases. They can't ALL be so large that you need to back them all up separately. Maybe the question we should be asking is, WHY do you need to be able to restore each database individually? Please keep in mind that the ability to restore a dbspace does NOT mean you can undo stupid behavior like someone accidentally dropping a table, as you must go through logical recovery, which would replay the drop table. The only reason I can think of for backing them all up separately is to avoid bringing the others down while you restore one, but when they are small, this is not such a big issue. June -- june_t@hotmail.com Grounded in Palo Alto, living on Cafe Mocha