Re: backup differences between SE and OL - question.

In <1993Jan14.155534.9281@elsouth.uucp> john@elsouth.uucp (John White) writes: > In trying to decide the relative merits of each DB engine, >I've come to a stumbling block in the backup section. OnLine is >supposed to have a much better backup strategy in that we the system >pukes, you can restore back to the very moment of the puke - and quick. > That's cute, but I can't remember when I last ran into this >situation - because I never have. What I have had happen is some idiot >asking me to restore a row of a table which he updated accidentally. >Or worse yet, in training a new programmer, having him do an unconstrained >update which sets all of the rows instead of 1 row. > In these cases I need to get the table back off yesterday's backup >and get the data for that row or column out and merge it back into the >table. I generally do this by getting the table.idx and table.dat files, >creating a database, creating a table, point the tabname to the restored >table name, get my data, do my updates, toast the database. > Question: Can I do a similar thing if I cut over to Online? If so, >how? Will I have to create an entirely new mirror database and restore from >my archive into it? If so, that would require me to have twice the disk space >and would be pretty time consuming. Is there a simpler way? > - john (john%elsouth@concert.net) It sounds like you don't NEED OnLine, in which case SE may well be the better choice. SE can also recover to the point of the last completed transaction, provided you use Transaction Logs. There are differences however: SE does not rollforward automatically, you have to invoke it. OnLine is automatic. SE logs are for individual databases, OnLine rolls forward all (logged) databases. SE is not likely to be as fast. I get the impression that none of these are real issues for you. If you do go with OnLine then you could use the tbunload utility to take a "snapshot" of each table that you wanted to be able to carry out "reversal activity" on. You would need twice as much disk space if you unload to disk and then do UNIX backups to tape, or you would have to do a hell of a lot of tape swapping, if you unload direct to tape. You can tbunload an entire database, but in order to tbload it back in again you would have to "DROP DATABASE", which would make me extremely nervous ( and in a "normal" OnLine environment the disruption would be unacceptable). If you're talking about a development environment, then there may be something practical down this route. If you're talking about a runtime/production environment then the very idea gives me the heeby-jeebies! In either case, any "snapshot" strategy should be in ADDITION to normal archiving, not, NOT, _NOT_ instead of an archiving strategy. graeme -- -m------- Graeme Sargent Voice: +44 (0)252 373035 ---mmm----- Senior Database Consultant Fax : +44 (0)252 373135 -----mmmmm--- Pyramid Technology Ltd. Telex: Tell who??? -------mmmmmmm- Farnborough, Hants GU14 7PL Email: graeme@pyra.co.uk