RE: Backing up Oracle database

2000-11-22 Thread Joi Ellis

On Tue, 21 Nov 2000, Tuthill, Ed wrote:

So if you'd like to look at a perl version of this, let me know
and I can ship a copy your way.

I'd love to have a copy of your perl script when you're finished with
it. I have MySql on my box supporting my own private website search
engine and our internal bugzilla.  Not a real high-traffic server but
I'd still like to get the bugzilla backed up better than it is now.
-- 
Joi Ellis
[EMAIL PROTECTED], http://www.visi.com/~gyles19/




RE: Backing up Oracle database

2000-11-21 Thread Tuthill, Ed

I'm putting the finishing touches this week on a perl script
that handles Oracle database hot backups (to keep the database
up and running 24/7).  It's very much like the tcl script John
Jackson wrote, but uses the Expect perl module to interact with
the database.

The script essentially backs up all of the tablespaces, control
files, and config files to a spare partition set up specifically
for this purpose.  This partition is then set to be backed up
with Amanda, along with all the regular partitions on the
system  (e.g., /usr, /var, etc.).

So if you'd like to look at a perl version of this, let me know
and I can ship a copy your way.


 -Original Message-
 From: Fredrik Persson P (QRA) 
 [mailto:[EMAIL PROTECTED]]
 Sent: Monday, November 20, 2000 8:46 AM
 To: '[EMAIL PROTECTED]'
 Subject: RE: Backing up Oracle database
 
 
 
   [Fredrik Persson P (QRA)]  Please read the entire mail! 
 In the end, I'm coming to a conclusion that
   probably obsoletes a lot of the previous junk that I 
 wrote. I've been writing this email all day and 
   I've become wiser along the day too...
 
  I've been assigned the task to back up an Oracle database 
 w/ amanda. I'm
  also told (by the db administrator) that a have to read 
 the files under /u02
  (a directory in the root of the file hierarchy) in a 
 certain order. 
  
  Ummm, that's very odd.  I've talked with my Oracle admin 
 and we're not
  sure what it is you're trying to do here.  Could you elaborate?
  
   [Fredrik Persson P (QRA)]  Absolutely! Our main concern 
 seems to be that the
   database must operate 24/7. The scheme that we thought 
 up was to run the "begin
   backup" command on all tablespaces before amanda starts 
 her work. When she's
   finished, the "end backup" command is run on all 
 tablespaces. When all the tablespaces
   are brought "back into action", the command ALTER 
 SYSTEM SWITCH LOGFILE is issued,
   to create a new ARCHIVELOG file, even thought the old 
 one might not be "full". 
 
   To restore the contents of the db, we first bring the 
 tablespaces back, and then apply
   the archivelog file to them. Now, there seems to be a 
 file called the "control file". If this
   file is backed up before the tablespaces, and the 
 tablespaces are altered during backup,
   we cannot restore the system. The control file is out 
 of date and we get an error message
   similar to "control file older than tablespace". Can't 
 recall the exact words, but that's what 
   it means.
 
   So, what I want to do is to backup the tablespaces 
 first, and the control file after that. That's
   why I need to tell amanda to do things in a certain order.
 
  Also, the way we back up our Oracle system is to dump it to 
 a scratch disk
  area and then let Amanda back that up.  And yes, we've done 
 restores :-).
  And they even worked :-).
  
   [Fredrik Persson P (QRA)]  Are you running 24/7? If so, 
 how do you deal with the issue
   of changes in the db during file transfer? Do you use 
 raw partitions or does Oracle run on top
   of a file system?
 
  The scripts we use are at:
  
ftp://gandalf.cc.purdue.edu/dbbackup.*
  
   [Fredrik Persson P (QRA)]  That link didn't work. Did 
 you mean ftp://gandalf.cc.purdue.edu/pub/amanda/dbbackup.*
 
  Is there a way to tell Amanda this?
  
  If this really ends up being the way you need to do this, I 
 have some
  hacks that I think would work.  But let's make sure you're 
 headed down
  the right path first.
  
   [Fredrik Persson P (QRA)]  After spending the day 
 pondering this issue, I think we've come to the conclusion that 
   we'll copy the db files to a temp storage, and then 
 backup them from there as if they were regular files.
 
   This is your approach too. I'd say it's a good one. 
 Minimizes db backup time and gives us control 
   over the order when storing db files. 
 
   I've browsed your scripts. Are those GPL'ed or 
 something similar? Right now, we're using our own scripts
   that can be said to be stripped versions of yours. 
 However, I might be interested in your stuff later.
 
   Thanks for your help! Using a temp storage was pretty smart.
 
   /Fredrik Persson
 



Re: Backing up Oracle database

2000-11-21 Thread John R. Jackson

   Are you running 24/7? If so, how do you deal  with the issue
   of changes in the db during file transfer?  ...

Yes, we're running 24/7.  And it's my understand the technique the script
we use employs deals with that.

 The scripts we use are at:
 
   ftp://gandalf.cc.purdue.edu/dbbackup.*
 
   [Fredrik Persson P (QRA)]  That link didn't work. Did you mean ftp://ga
ndalf.cc.purdue.edu/pub/amanda/dbbackup.*

Hey!  At least I got the host name right.  The rest is **supposed** to
be an adventure.  :-)

Yes, what you found was what I meant to point you at.

   I've browsed your scripts. Are those GPL'ed or something
similar?  ...

They say pretty clearly they are copyright Purdue University but freely
redistributable.

And don't anybody bother starting a war with me about free software,
copyrights, copylefts, GPL's or anything else.  I'm not interested.

   /Fredrik Persson

John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]



RE: Backing up Oracle database

2000-11-20 Thread Fredrik Persson P (QRA)


[Fredrik Persson P (QRA)]  Please read the entire mail! In the end, I'm coming 
to a conclusion that
probably obsoletes a lot of the previous junk that I wrote. I've been writing 
this email all day and 
I've become wiser along the day too...

 I've been assigned the task to back up an Oracle database w/ amanda. I'm
 also told (by the db administrator) that a have to read the files under /u02
 (a directory in the root of the file hierarchy) in a certain order. 
 
 Ummm, that's very odd.  I've talked with my Oracle admin and we're not
 sure what it is you're trying to do here.  Could you elaborate?
 
[Fredrik Persson P (QRA)]  Absolutely! Our main concern seems to be that the
database must operate 24/7. The scheme that we thought up was to run the "begin
backup" command on all tablespaces before amanda starts her work. When she's
finished, the "end backup" command is run on all tablespaces. When all the 
tablespaces
are brought "back into action", the command ALTER SYSTEM SWITCH LOGFILE is 
issued,
to create a new ARCHIVELOG file, even thought the old one might not be "full". 

To restore the contents of the db, we first bring the tablespaces back, and 
then apply
the archivelog file to them. Now, there seems to be a file called the "control 
file". If this
file is backed up before the tablespaces, and the tablespaces are altered 
during backup,
we cannot restore the system. The control file is out of date and we get an 
error message
similar to "control file older than tablespace". Can't recall the exact words, 
but that's what 
it means.

So, what I want to do is to backup the tablespaces first, and the control file 
after that. That's
why I need to tell amanda to do things in a certain order.

 Also, the way we back up our Oracle system is to dump it to a scratch disk
 area and then let Amanda back that up.  And yes, we've done restores :-).
 And they even worked :-).
 
[Fredrik Persson P (QRA)]  Are you running 24/7? If so, how do you deal with 
the issue
of changes in the db during file transfer? Do you use raw partitions or does 
Oracle run on top
of a file system?

 The scripts we use are at:
 
   ftp://gandalf.cc.purdue.edu/dbbackup.*
 
[Fredrik Persson P (QRA)]  That link didn't work. Did you mean 
ftp://gandalf.cc.purdue.edu/pub/amanda/dbbackup.*

 Is there a way to tell Amanda this?
 
 If this really ends up being the way you need to do this, I have some
 hacks that I think would work.  But let's make sure you're headed down
 the right path first.
 
[Fredrik Persson P (QRA)]  After spending the day pondering this issue, I 
think we've come to the conclusion that 
we'll copy the db files to a temp storage, and then backup them from there as 
if they were regular files.

This is your approach too. I'd say it's a good one. Minimizes db backup time 
and gives us control 
over the order when storing db files. 

I've browsed your scripts. Are those GPL'ed or something similar? Right now, 
we're using our own scripts
that can be said to be stripped versions of yours. However, I might be 
interested in your stuff later.

Thanks for your help! Using a temp storage was pretty smart.

/Fredrik Persson