Re: NT hot backup

"Chuck" <chuckh_at_softhome.net> wrote in message news:<ajjd8o$1chsqa$1_at_ID-85580.news.dfncis.de>...
> If you do a search on Metalink for OCOPY you will come across documents
> explicitly stating that copy and xcopy are not safe for copying open files.
> That is why they provided the OCOPY utility. Perhaps copy and xcopy work
> just fine all or most of the time. I personally would not take the chance of
> corrupting a backup when Oracle has stated not to use them for hot backups.
>

You might note that document 139327.1 is referring to NT backups, and not Windows 2000, which is a different kettle of fish altogether, and the O/S I rather thought you were using. But whatever makes you feel safe.

> The compress utility I was talking about is the one that ships with the
> winnt, win2k, and presumable winxp (though I have never seen XP) resource
> kit. It's called compress.exe. It ships with a counterpart called
> expand.exe.
>
> I was not aware of the "compress contents" directory attribute on Win2k as
> we only recently started using it. I don't think I'd chance using it on
> directories that hold datafiles but can you tell me if it's safe for
> archived logs? I can't see why it wouldn't be. I will look into setting that
> attribute for directories that hold only archived logs, export files, and
> backup copies of datafiles. Thanks for the tip.
>

You said you wouldn't risk the chance of corrupting a backup by using anything other than OCOPY, yet you are prepared to do precisely that by compressing things! I wouldn't compress an archive if my life depended on it.  

> As to the "death wish" comment regarding compressed backups, pretty much
> every Oracle DBA I know that works in UNIX uses compression utilities like
> gzip or compress to compress both archived logs and tar'ed backups of
> databases.

That doesn't make it wise, or good practice. Have you ever removed one bit from (say) a winzip file and seen what happens when you try and uncompress?

>I compress all of my export files too and have never had a
> problem.

Export isn't a backup, so that's less of a concern.

>There's no reason not to. They compress the files to anywhere from
> 1/4th to 1/10th of there original size and are completely reliable.

"Completely"?? I don't think so. Put it this way: they are as reliable as NOT using OCOPY. :-)

>Why
> should I use if 10g of space for backups when 1g will do?

Because you (presumably) don't want to risk your data.

Regards
HJR
(Who apologises for posting via Google, but my news server seems not to be working of late).

>Just don't
> compress archived logs if you are using RMAN for backups. It doesn't
> recognize the .Z or .gz extensions added to the files.
> --
> Chuck
>
> "Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote in message
> news:3d583ca7_at_dnews.tpgi.com.au...
> >
> > "Chuck" <chuckh_at_softhome.net> wrote in message
> > news:aj8v3q$19ufd6$1_at_ID-85580.news.dfncis.de...
> > > I'm quite aware of the need to put tablespaces into backup mode before
> > > backing them up.
> >
> > Read your post again. It's not evident in what you actually wrote at all
> > that you are 'quite aware' of this.
> >
> > >What I was asking about was that once I've placed a
> > > tablespace into backup mode,
> >
> > Curiously, this crucial nugget of information was *not* included in your
> > post. So it wasn't what you were asking at all.
> >
> > > I need to backup the open datafiles of that
> > > tablespace. Oracle provides an OCOPY.EXE program to do that because
> > > Microsoft's copy and xcopy commands will not copy open files properly.
> >
> > Nonsense. You do not need OCOPY to backup open files in Windows NT or
> 2000.
> > I use Explorer and right-mouse clicks all the time. Unless you are using a
> > RAC with raw logical partitions... *then* it gets useful. I used OCOPY for
> > the first time last week to backup some (raw) datafiles in my new RAC. I'd
> > never used it before then.
> >
> > >I
> > > wanted to know if I had to OCOPY the files first, then compress them, or
> can
> > > I use the compress utility directly to copy and compress the open
> datafiles
> > > without ocopy?
> >
> > I wish I knew what compress utility you were talking about. You use
> Windows
> > 2000, right? So what 'microsoft utility' are we talking about? In XP, we
> > have the 'send to compressed folder' option, but that doesn't exist in
> > Windows 2000. So are we talking about the ability to right-click a folder
> or
> > file, click Properties and Advanced, and check the 'compress contents to
> > save disk space' option?
> >
> > The reason I ask is because as best I can make out from your last
> paragraph,
> > you are positing two options. One, copy the datafiles, compress the
> copies.
> > Two, 'copy and compress' the datafiles in one go.
> >
> > Yet, the right-click, Properties, Advanced, check 'compress contents'
> > technique doesn't *take* copies. It's an in-place compression of the live
> > datafiles only. So where the 'copy and compress in one operation' comes
> > from, I can't work out.
> >
> > Perhaps you have something like Winzip or winrar, which install themselves
> > in such a way that you can right-click a file and select to 'add to
> > archive...' or 'add to zip'? If this is the case, then yes, the creation
> of
> > the compressed archive creates a new file with a compressed copy of the
> > datafile within it, and leaves the original datafile uncompressed and
> > unaffected -so, in a sense, it is doing a copy and compress in one
> > operation. If this is what you are talking about, then that is fine... the
> > zipped file is useable in backup scenarios, because of the 'begin backup'
> > command you issued earlier.
> >
> > (Provided the compression utility, whatever it may be, doesn't 'move' the
> > original file into the compressed archive, of course... 'cos then, you'll
> > have lost your original file).
> >
> > If that's still not the answer you want, then write back one more time
> > explaining precisely which 'microsoft utility' we are talking about.
> >
> > In any event, anyone who compresses their backups must have a death-wish
> of
> > some kind. The backups are the only thing standing between you and data
> > loss, so you start 'processing' them at your peril. If disk space is
> tight,
> > I would at least suggest not compressing your most recent backup.
Received on Sat Aug 17 2002 - 11:17:15 CDT