Re: NT hot backup

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.

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.

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. I compress all of my export files too and have never had a problem. 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. Why should I use if 10g of space for backups when 1g will do? 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.