Hello,
I have XE 10.
2 on linux, 3-4 times a day data gets written into this database,
which actually overwrites what was there before..
What I want to do is to backup this data, transfer the backup to
another server which I have not yet installed, and restore it so I can
run some applications against the data and test that it all works OK.
Or if it does not fix it.

Right now the database is not running in archivelog mode, cos it does
not need to be cos the data is transient. So probably I cannot use the
$ORACLE_HOME/config/scripts/backup.sh, cos that uses RMAN.


Any suggestions?

-Syd

syd_p wrote:

IIRC that script performs a cold backup if it detects that archivelog
mode is off.

Y.

On Mar 4, 4:42*am, syd_p <sydneypue... (AT) yahoo (DOT) com> wrote:
Yosarian is correct about the cold backup, it explicitly (and kind of
scarily, which is a good thing for production uses) tells you it will
shut down the db for the backup (at least on winblows, you can look at
the script on linux and see). Note that there are also other options
for transferring data. You can use the regular export/import
utilities, which is very handy if you aren't using an identical XE
elsewhere. XE also has unload to text and unload to XML under the
utilities menu. Unfortunately you can't use the handy transportable
tablespaces option. http://download.oracle.com/docs/cd/B...c.htm#BABDFDAI

jg
--
@home.com is bogus.
http://www.aolnews.com/2011/02/25/fo...-ufo-cover-up/

On 4 Mar, 18:18, joel garry <joel-ga... (AT) home (DOT) com> wrote:
http://download.oracle.com/docs/cd/B...107/impexp.htm
I realise now what I really want to do is to back up a schema on one
box and then restore on another box which has a out of the box
install of XE.
Seems like Data Pump Export and Data Pump Import is the way to go.
Am I right?

-Syd

On Mar 9, 1:34*pm, syd_p <sydneypue... (AT) yahoo (DOT) com> wrote:
Yes, expdp the required schema(s) from the source database, copy the
dumpfiles across to the server of the target database and use impdp to
import them. The impdp utility will create the required schema(s) and
import into them.

HTH
-g

On Mar 9, 5:34*am, syd_p <sydneypue... (AT) yahoo (DOT) com> wrote:
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
backup a backup, and everything else not a backup, which in a
practical sense these days means archivelog mode and RMAN hot
backups. One big exception is if you are recreating the data every
time from somewhere else that is backed up. Since that sounds like
your situation, maybe you can clone that process? Just another
thought.

Data Pump does have a network option, if you have proper connectivity.

jg
--
@home.com is bogus.
http://www.bloomberg.com/news/2011-0...disclosed.html

On Mar 10, 11:59*am, joel garry <joel-ga... (AT) home (DOT) com> wrote:
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.

On Mar 10, 10:41*am, Steve Howard <stevedhow... (AT) gmail (DOT) com> wrote:
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.

jg
--
@home.com is bogus.
cnet gets old news. http://news.cnet.com/2300-1001_3-10004926-4.html