Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Backup Script

Re: Backup Script

From: Sean M <smckeownNO_at_BACKSIESadelphia.net>
Date: Fri, 26 Jul 2002 10:14:37 -0600
Message-ID: <3D41756D.94C9D71C@BACKSIESadelphia.net>


"Charles J. Fisher" wrote:
>
> Disadvantages:
>
> 1. I do take the tablespace in and out of backup mode for each datafile.
> Since I'm compressing, this seems like a good idea.
> 2. Most Linux systems don't come with the Korn shell; download it at
> http://kornshell.com.
> 3. I do make hot copies of online redo, which is *very* useful for
> cloning, but causes the heads of Oracle purists to spin (I hate the
> sound of snapping vertebra in the morning). Using hot-copied redo will
> prevent you from rolling forward through logs (assuming that recovery
> works at all).
> 4. I don't skip anything.

Re: your #4... you probably already know this, but your script will bomb unnecessarily for any offline or read-only tablespaces.

Re: your #3... regardless of whether or not you manage to get a non-corrupt copy of a current online redo log (possible maybe, but never guaranteed), why bother? You say it's very useful for cloning, but I don't see how. Just archive log current when you're done, copy over the archives to the clone, and use them for recovery. Anything less is not guaranteed (though if you get lucky, it may be possible) and not necessary. If you're opening your clone without a resetlogs, you're playing with fire - you'll end up generating 2 threads of redo with the same sequence numbers and have no idea which archives belong to which database (did they come from the clone or from the real McCoy?). My point is although you may be mostly successful with this practice of copying over the online redos, you're only getting lucky for the most part, and there are perfectly good, guaranteed ways of accomplishing the same tasks, so why do it?

Re: your #1... again, I don't see the point. I know you need to compress on the fly, but why not put the tablespace into hot mode, copy/compress all datafiles that belong to it at the same time (either serially or in parallel, depending on your CPU and i/o bandwidth), then take it out of hot mode, and move on to the next tablespace? The total (cumulative) length of time that you leave the tablespace in hot mode wouldn't be any longer than your method, and you avoid all the extra checkpoints of having to take the same tablespace into and out of hot mode multiple times.

Regards,
Sean Received on Fri Jul 26 2002 - 11:14:37 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US