Re: Take the archives during the backup
Date: Sun, 29 Aug 2010 11:01:45 -0700 (PDT)
Message-ID: <bf9ac56a-ae59-46a2-a65d-8edebd41555a_at_h17g2000pri.googlegroups.com>
On Aug 28, 9:40 am, "hea..._at_googlemail.com" <hea..._at_gmail.com> wrote:
> On Aug 28, 7:28 am, "bob123" <bob..._at_gmail.com> wrote:
>
>
>
> > 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
>
> 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;
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
-- _at_home.com is bogus. "techy" is in the OED: http://www.signonsandiego.com/news/2010/aug/29/internet-phasing-out-printed-oxford-dictionary/Received on Sun Aug 29 2010 - 13:01:45 CDT