Hi,

I did a hot backup with RMAN.
To recover to the time of the end of the backup
how can I specify to take the archive
only generated during the backup ?

Thanks in advance
Oracle 10.2.0.4

On Aug 26, 2:02*am, "bob123" <bob... (AT) gmail (DOT) com> wrote:
Additional infromation is necessary to properly answer your question.

Are you using a backup set or file copies?
Did you include the archive logs as part of the backup set or not?
Are you restoring to the same or a different machine?
Do you use a recovery catalog?

Options would include Point in Time Recovery (PITR) to a predetermined
SCN or timestamp or potentially you could perform a recover until
cancel operation.

HTH -- Mark D Powell --

bob:

# I did a hot backup with RMAN. To recover to the time of the end of
the backup how can I specify to take the archive only generated
*during the backup ?

You cannot do this directly all in RMAN but you can do this indirectly
in a couple of different ways.

You can recover to a point in time fairly easily ... just a question
of how you might want to architect ( script it ) to get the time that
you want.

On Aug 25, 11:02*pm, "bob123" <bob... (AT) gmail (DOT) com> wrote:
In addition to what Mark said, what exactly are you trying to
accomplish? It is possible to need archived logs from before the
start of the backup. It is possible to get ORA-1152 too, if your
specification winds up creating a gap in the logs applied. Remember,
hot backups are fuzzy, and you need to apply redo to make transactions
consistent. Transactions may not care when your backup started. It
is very easy to think nothing is happening when you do your backup,
but something is always happening. Then there's read-only
tablespaces...

jg
--
@home.com is bogus.
http://www.signonsandiego.com/news/2...ven-in-sweden/

OK Mark thanks
the goal is duplicate a production database
to a test database
my answers below

<Additional infromation is necessary to properly answer your question.
<
<Are you using a backup set or file copies?
backup

<Did you include the archive logs as part of the backup set or not?
Yes but this is my problem.
To have the smallest backupset
I would like to have only the archives
necessary to open the copy of the database.
I don't do delete input on the source database
so no problem for my source database.

<Are you restoring to the same or a different machine?
to another machine

<Do you use a recovery catalog?
nocatalog

<Options would include Point in Time Recovery (PITR) to a predetermined
<SCN or timestamp or potentially you could perform a recover until
<cancel operation.
OK but to have the smallest backup set
how can I only include the archives needed to
recover the test database.
Taking all the archives is to big for my
working window.

Thanks again

On Aug 28, 7:28*am, "bob123" <bob... (AT) gmail (DOT) com> wrote:
Using RMAN the most practical and safest approach to me would be to
backup all the archives that have not been backed up, then backup the
database plus the archives logs and then you would just copy the files
from the time of the second backup which you could get from the
listing the backups to know which files to copy and you still have
your archives backed up from before.


Something like:

SQL 'ALTER SYSTEM CHECKPOINT'';
SQL 'ALTER SYSTEM SWITCH LOGFILE'';
backup archivelog all;
SQL 'ALTER SYSTEM CHECKPOINT'';
backup database plus archivelog;

On Aug 28, 5:40*pm, "hea... (AT) googlemail (DOT) com" <hea... (AT) gmail (DOT) com> wrote:
I've just thought, you could just do the duplicate database using rman
using the auxillary, look up duplicate database. Ive used it before
to create standby databases but can use it just to clone a database
too which will also give you the desired effect you are wanting. If
the other system does not have the same paths (same directory layout)
then you would have to rename files to the new paths as you duplicate
so will have to tell us if it has the same directory structure as the
current system.

On Aug 28, 9:40*am, "hea... (AT) googlemail (DOT) com" <hea... (AT) gmail (DOT) com> wrote:
That's true, but personally I like to have some redundancy in my log
backups, so I would do something completely different when propagating
than when doing normal backups, given that I had a reason to minimize
archived logs. I haven't done that for a long time though, because I
want the testing environment to be quite a bit different from my
production environment, most especially about schema names - too many
users of varying technical expertise to trust knowing the difference,
and I still see times when they don't realize they are in one or the
other, even though it says it right on the screen - and of course,
even I make the mistake, with potentially catastrophic results. My
obscure app also has additional reasons to do it with exp/imp anyways,
even though transportable tablespaces would be one or two orders of
magnitude quicker. The reality is, there are so many work in progress
type things - including code, data and metadata changes - that need to
be managed that refreshing test winds up being a major project, not
done often. It all depends, of course. Since I'm using compression
and moving things to semi-online storage, I don't much care about
minimizing archived logs in backups, I care more about not running
into a situation of not having a log available during a restore.

So bob123: is this a one-time thing, weekly, daily, what are you
trying to accomplish? What is your test environment going to do? Do
you have severe storage limitations?

jg
--
@home.com is bogus.
"techy" is in the OED: http://www.signonsandiego.com/news/2...rd-dictionary/

heald:

If you go down this path you probably want to do the backup database
then switch archivelogs then backup the archivelogs.

You want to make sure you have an archivelog after the backup in other
words.

On Aug 29, 11:51*pm, John Hurley <hurleyjo... (AT) yahoo (DOT) com> wrote:
RMAN automatically switches them out making sure you have all the logs
used during the backup(well its supposed to), however i've been using
this particular backup script below for years, tested it countless
times and had to depend on backups taken with it on several occasions
and I put the archive log backup separately for some reason which may
be the same reason your talking about, despite oracle saying the plus
archivelog option should work.

:

connect target /
run
{
crosscheck archivelog all;
crosscheck backup;
crosscheck copy;
backup database;
backup archivelog all not backed up 2 times;
restore database validate;
delete noprompt archivelog all completed before 'SYSDATE -7';
delete noprompt obsolete;
sql "create pfile from spfile";
sql "alter database backup controlfile to trace";
}

If that's the case i'de change the original script to I posted to this
to make sure im using stuff i've tested myself for time:


SQL 'ALTER SYSTEM CHECKPOINT'';
SQL 'ALTER SYSTEM SWITCH LOGFILE'';
backup archivelog all;
SQL 'ALTER SYSTEM CHECKPOINT'';
backup database;
backup archivelog all not backed up 2 times;