Re: Should I wait for IDS 11?

On 13 Jun, 12:18, Martin Fuerderer <MARTI...@de.ibm.com> wrote: > Hi, > > maybe you want to look into external backup (and restore). > This can easily be done to a file system and you can add > as much parallelism as you want (or are capable of). > If you do it right, you can accomplish the critical part of the > external backup in less than a minute even for some terrabytes > of data (e.g. by splitting a mirror). After this you can let the > database users continue with their work while the actual backup to > tape, files or whatever destination is done ... 1. If you resync mirror the wrong way you break the database. 2. If you add a device you have to a) add a mirror) b) add the mirror to the backup script. > > > Why can't Informix without the complexity of a Storage Manager? > > ontape can do backup to files, but also (if not chiefly) it is > intended as a tool to backup to tape. And for doing backup > to tapes in parallel, a storage manager (SM) is enormously helpful. In what way it is helpful? It just means I need to piss about - parsing /nsr/logs/daemon.log for messages - creating volumes, - labeling volumes, - find a free device - mounting volumes on devices - not mounting the same volume on >1 device. - unmounting volumes - wondering why it all went tits up and i unmounted something that was in use and having to waiting until ISM issues a media critical event and the volume required for a restore gets mounted a second time. WHAT BENEFIT DO I GET HAVING TO DO ALL THIS CRAP? NOTE: Does anyone know how to configure the timeout in ISM during a restore between "media waiting for volume X" and "media critical waiting for volume X" messages? At the moment we unmount when a message appears in /nsr/logs/daemon.log that the dbspace restore is complete (" ...done reading") but if a volume contains >1 dbspace we unmount the volume between one dbspace finishing and the restore for the next one starting. We have to wait for the "media critical" message before ISM prompts for the volume to be remounted. > > BTW: as already mentioned by someone, onarchive was an attempt > to do parallel backup without an SM. It became so complex to use > that in the end people didn't use it anymore. > I DON'T HAVE TO DO ALL THIS CRAP WITH DB2 OR SYBASE. How come they can do it without getting as complex as onarchive? David.