On Thu, 30 Nov 2000, Fredrik Persson P (QRA) wrote:
> > > Now, the solution to copy the db files to a temp storage and then have
> > > amanda back up from there was good - it works! There is a problem however,
> >
> > Ouch. You'll need a lot of space which will be wasted while not holding
> > the copied data files. I haven't seen part 1 but why not simply
> > put all of the tablespaces into hot backup mode. Backup the data files
> > and archivelogs normally and then backup the control files last or
> > alternatively back the control files to trace?
>[Fredrik Persson P (QRA)] Well, at first I tried to do that. However, I
>ran into difficulties. First, I'd like to put only the tablespace beeing
>backed up into backup mode. It's the "oracle" users that does that. Sure,
>I could set the "backup" user up with those previliges too. As you surely
>understand, having two users involved would call for a sync function
>between those two users; the amount of work stopped me from choosing this
>scheme.
Switching all of the tablespaces into and out of hot backup mode once at
the start and end of the backup is definitely simpler. The backup user has
to be running essentially as root for a backup anyway so it should be
possible to do a 'su oracle -c command' at the start and end of the
backup.
>Also, I wanted to tell amanda, in a smooth way, in what order to back up
>individual files; the control file must be backed up after the tablespace
>files are backed up. I still don't know if amanda lets me do that. John?
The structure of a database doesn't change very often (datafiles added,
tablespaces modified etc) so you could do a backup control file to trace
and on recovery of the database you tell it that it's an old control file
and run up to the end of the archivelogs that you have. Definitely a
problem though. I've never found a satisfactory solution to this and on
recovery almost always had to recover data files from different backups
and archivelogs for the whole period.
>I hope I make some kind of sense...?
Sure. Oracle's a pain. I admin 4 servers with 5 production Oracle
databases and 6 servers with approx 30 production Informix databases.
Around 60% of my time is spent on Oracle and 10% of my time is spent on
Informix.
> > In addition you should do a database export; You're more likely to have a
> > developer drop a table by mistake than have a disk fail and it's much
> > easier to get data back from an export.
>[Fredrik Persson P (QRA)] I'm not quite sure what database export is...
>I'm not the db guy, I'm the backup guy. (Well, I'm more then that
>actually but I do backups...)
With Oracle a database export essentially dumps the contents of the
database to a single file. The imp and exp utilities can import and export
individual tables so if a developer drops/messes up a table you can
restore just the table rather than having to do the entire database.
> > Now, if you want some redundancy *and* faster backups then you could put
> > the database on a raid 1 mirror. When it comes to do the backup, break the
> > mirror and mount the broken mirror somewhere. Backup the broken mirror
> > rather than the live database. Once the backup is done, unmount and resync
> > the mirror. Make use of all the wasted temp space. I don't think the linux
> > md driver is up to this but some of the newer stuff might be.
> >
> > [Fredrik Persson P (QRA)] Nice trick. Not an option though, we're already RAIDed
>in RAID3...
regards,
Colin.
