Re: Oracle XE backup and restore to transfer data to another server

From: joel garry <>
Date: Thu, 10 Mar 2011 11:50:43 -0800 (PST)
Message-ID: <>

On Mar 10, 10:41 am, Steve Howard <> wrote:
> On Mar 10, 11:59 am, joel garry <> wrote:
> > > -Syd
> > Yes, though I must caution you, while technically it is a logical
> > backup, using export utilities and calling it a backup will get you
> > flamed in some places.  Oracle DBA's usually call a transactional
> I have heard the same thing, and to this day I don't understand this.
> If I change a script and before doing so make a simple copy, that is a
> backup.  When I do that with a database, it isn't.
> RMAN and archived redo logs is obviously the most robust since you can
> do point in time recovery with just internal database tools, but to
> say an export of a small schema that is never changed (or even
> infrequently and can be easily rebuilt from source data) is not a
> "backup" will draw more than a puzzled glance from a reasonable
> person.  Call it a copy, a backup, whatever you want.  Backup works
> for me.

It perhaps comes from all the times we've seen people ask how to apply redo after an import, or copy in a data file not copied in backup mode, or a less articulate equivalent. People think it is just like copying a text file (which is what your script is, right?), but it isn't. And what happens if your script gets CR/LF confusion? After all these years, I still don't know what will happen when I download some arbitrary script and open it to look at it.

Another view is that you will lose data without a proper recovery mechanism, which violates the Prime Directive of DBA.

I agree with you, by the way, but we are in a minority in the Oracle DBA community. What is most important is defining recovery (or in this case, propagation) requirements. But Onomasiology is also important, and it is important because newbies get the concepts wrong.


-- is bogus.
cnet gets old news.
Received on Thu Mar 10 2011 - 13:50:43 CST

Original text of this message